VirtualBox v3.0.X system lock up issue

[eblaine]

Absolutely no change for me. We have an update 7 jumpstart we've been using so these machines are fresh installs of Solaris with 3.0.4 running on quad core Ultra 24s. I am actually getting lockups more often than when we were running 3.0.2. Same as before (posted on this page), I've had complete system lockups when the WindowsXP loading screen comes up and every single time I've started Google Earth running in OpenGL mode. I have 3D support enabled in VirtualBox with 128MB RAM allocated and the latest 3.0.4 guest additions installed (I tried one machine with the Direct3D (Experimental) installed and one without).

Hopefully someone else has better luck or perhaps finds a workaround for this issue.

[Ramshankar]

It might take awhile to get results but you could do step by step disable of VM features, smp, vt-x, apic, 3d, etc... until it stops crashing.

Is that supposed to mean that this behavior hasn't been observed by any of the VBox developers?

I'm all for helping out with the troubleshooting process, but turning off a single feature, waiting days or weeks to see if the box still locks up, and then turning off another feature and doing the same is rather pathetic advice. Perhaps it's a combination of two or more specific features. Perhaps it has nothing to do with features at all, and is a bug in the VBox kernel module and the way it interacts with the (Open)Solaris kernel.

A suggestion that is a bit more targeted would be appreciated instead of what appears to be just random strawman troubleshooting suggestion that is of no better caliber than: why not start taking pieces of hardware out of your system one by one and wait to see if VBox causes the system to hard lock again.

We _are_ aware of this bug and we are working on fix it. It's related to VT-x/AMD-V and differences between Solaris 10's and Nevada's dispatcher which isn't being handled correctly in VirtualBox. The fix isn't trivial and will not go away with disabling IO-APIC/Nested Paging/3d.

[randshuntzinger]

It might take awhile to get results but you could do step by step disable of VM features, smp, vt-x, apic, 3d, etc... until it stops crashing.

Is that supposed to mean that this behavior hasn't been observed by any of the VBox developers?

I'm all for helping out with the troubleshooting process, but turning off a single feature, waiting days or weeks to see if the box still locks up, and then turning off another feature and doing the same is rather pathetic advice. Perhaps it's a combination of two or more specific features. Perhaps it has nothing to do with features at all, and is a bug in the VBox kernel module and the way it interacts with the (Open)Solaris kernel.

A suggestion that is a bit more targeted would be appreciated instead of what appears to be just random strawman troubleshooting suggestion that is of no better caliber than: why not start taking pieces of hardware out of your system one by one and wait to see if VBox causes the system to hard lock again.

We _are_ aware of this bug and we are working on fix it. It's related to VT-x/AMD-V and differences between Solaris 10's and Nevada's dispatcher which isn't being handled correctly in VirtualBox. The fix isn't trivial and will not go away with disabling IO-APIC/Nested Paging/3d.

Thanks for your reply. This is a very serious problem because it takes out the enitire host - not just the virtual machine. It is good to hear that it is at least partially understood and being worked upon.

[tjobbins]

We _are_ aware of this bug and we are working on fix it. It's related to VT-x/AMD-V and differences between Solaris 10's and Nevada's dispatcher which isn't being handled correctly in VirtualBox. The fix isn't trivial and will not go away with disabling IO-APIC/Nested Paging/3d.

Does that mean it can be worked around by disabling VT-x?

Thanks

[ljw1]

Is there any bug no. that we can check so that it will be obvious when it is fixed?

Also is there anything that can be turned off or on that can help mitigate the crashes?

[half12]

Why was v3.0.2 and v3.0.4 released if it was known there was such a serious bug which could cause a system lock up?
Would it not have been better to announce that v3.0.x was being released on other platforms but due to critical bug the Solaris/OpenSolaris release was being skipped?

[dri]

Why was v3.0.2 and v3.0.4 released if it was known there was such a serious bug which could cause a system lock up?
Would it not have been better to announce that v3.0.x was being released on other platforms but due to critical bug the Solaris/OpenSolaris release was being skipped?

This is a mystery to me aswell. It's not usable to any extent other then toying with.

[mwilson]

Does that mean it can be worked around by disabling VT-x?

I don't think so. I have a dual Xeon server without VT extensions, and I still started experiencing these freezes as soon as I upgraded vbox.

[Ramshankar]

We currently narrowed down the issue and even have a workaround for this, but it's not yet addressing the main bug (which happens to be with VirtualBox & Solaris 10 playing with interrupt disabling that at some point causes a spectacular blow up). The fix if possible or at least the workaround should be part of the next release.

[Ramshankar]

Is there any bug no. that we can check so that it will be obvious when it is fixed?

Yes. http://www.virtualbox.org/ticket/4486

[ljw1]

The code from Solaris 10 must be similar to that in OpenSolaris 2009.06 as the crashes are occurring in that version for me. Is this common for other opensolaris users or is it my installation specific as previous versions did not have this problem? Thanks for pointing out the bug.

[Ramshankar]

The code from Solaris 10 must be similar to that in OpenSolaris 2009.06 as the crashes are occurring in that version for me. Is this common for other opensolaris users or is it my installation specific as previous versions did not have this problem? Thanks for pointing out the bug.

OpenSolaris and Solaris 10 are different in various parts of the kernel starting with the VM subsystem, changes to CPU structures and what not. For all practical purposes for a program like VirtualBox that does a lot of things most programs don't do, Solaris 10 is significantly different to OpenSolaris despite sharing common kernel code.

Please provide info on what do you mean by "crashes are occurring". Is it a crash or a hang? The ticket I pointed to tracks a host hang on Solaris 10 which as far as we know doesn't occur on Nevada/OpenSolaris. It might be worth opening a separate defect if the issue found is different or valuable info. if it really is the same issue.

[ljw1]

It is a hard hang of the machine, totally non-responsive, no keyboard or mouse or acpi buttons. When it crashes it requires a power cycle.

I haven't done any further testing as it is running on my nas box which is a major pain when it hangs. What sort of things do you need me to collect for a bug report?

[rpro]

Hmmm. It seems most people here have had hard lockups in OpenSolaris. I'm surprised that the devs would think it is Solaris 10 only.

Oh well.

[antoonh]

I'm seeing panics (so not hangs). As the panic suggests the VBoxNetDHCP module is the culprit, which I haven't seen in any of the other incidents or postings here, I filed a specific ticket for this.

See http://www.virtualbox.org/ticket/4775 for the details.

Antoon