4-CPU debian 5.0 guest gives: "BUG: soft lockup - CPU#[n] stuck for 61s - [procname:procid]"

[Nick J]

Host is 64 bit Ubuntu 10.04, running VirtualBox 3.2.8. Guest is Debian 5.0, 64 bit.

Guest was set up with 1 CPU, but since my host has a Quad Intel processor, I decided to try increasing it to 4 CPUs on the guest. Running with 4 CPUs gave errors like "BUG: soft lockup - CPU#[n] stuck for 61s - [procname:procid]" on the guest's console (will attach screenshot of this shortly), which doesn't sound like it can be a good thing. I then ran unixbench on the guest, and whilst this was running, the guest hung, and had to be forcibly shutdown.

I then brought the number of CPUs down from 4 to 2, and re-ran unixbench. The "BUG: soft lockup" messages were gone, and the VirtualBox did not hang.

So, there seems to be a problem with 4 CPUs, at least for me, that causes "BUG: soft lockup - CPU#[n] stuck for 61s - [procname:procid]" errors, and that _possibly_ also causes freezing under some situations.

[Nick J]

screenshot of soft lockup messages

[Nick J]

virtualbox log

[Sander van Leeuwen]

Well, it's hard to say what's the problem. One thing must be said though: you are asking for problems if you assign 4 CPUs to a guest when you only have 4 on your host.

[Nick J]

Replying to sandervl73:

One thing must be said though: you are asking for problems if you assign 4 CPUs to a guest when you only have 4 on your host.

That's not at all obvious from the current UI. The GUI currently gives a warning if you try and exceed the number of real CPUs, but it gives no warning if you try and use the number of CPUs that you actually have.

Perhaps it would be best to give the warning if ( number of assigned CPUs > 1 && number of assigned CPUs >= physical CPUs ). Currently it only seems to warn on ( number of assigned CPUs > physical CPUs ).

[Nick J]

screenshot of soft lockup messages, with 2 CPUs.

[Nick J]

virtualbox log, with 2 CPUs.

[Nick J]

Same error just encountered with 2 CPUs in the guest, in a 4-CPU host machine. This happened after rebooting the guest, during bootup. Screenshot & log are attached above.

[marco]

Are you by chance running a Java Virtual machine process?

[Nick J]

Screenshot of 3-CPU 64-bit Debian 5.0 Running in VirtualBox v3.2.8

[Nick J]

Replying to bulletxt:

Are you by chance running a Java Virtual machine process?

I do have a JVM process that runs in the guest sometimes, but it is strictly on-demand (it gets invoked by a web app when needed in response to a user action), and I don't _think_ it would have been happening at the time of these errors (although I can't be 100% certain for 4-CPU log). Certainly it does not run on bootup, so the 2 CPU error on bootup would not be caused by this. Additionally, I have just powered off the guest, set it to 3 CPUs, powered it back on, running virtualbox 3.2.8, and got the same soft lockup error (screenshot attached above) whilst booting up. So it can definitely happen without a JVM running on the guest. To date it happens with the guest set to have 2 CPUs, 3 CPUs and 4 CPUs. The only configuration where I have not seen it happen so far is 1 CPU.

[marco]

What kind of ubuntu kernel are you running? If you are on kernel generic, try the server one or vice versa and let's see what happens..

[Nick J]

That helped!

The host was using kernel generic, and changed to server:

$ uname -a
Linux redux 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux
$ sudo aptitude install linux-image-server linux-headers-2.6.32-25-server
$ reboot
$ uname -a
Linux redux 2.6.32-25-server #44-Ubuntu SMP Fri Sep 17 21:13:39 UTC 2010 x86_64 GNU/Linux
$ sudo /etc/init.d/vboxdrv setup

The guest virtual machine then ran okay with 2, 3 and 4 CPUs, without any soft-lockups. I have not seen any soft lockups so far with the host running the server kernel.

So, what does this mean? I'm presuming it implies that either VirtualBox needs to be updated to run okay on the generic kernel, or that the generic kernel needs to be updated to run VirtualBox.

[Sander van Leeuwen]

Hard to say. Looks like some host scheduling weirdness or a timing related problem.

[Frank Mehnert]

Please reopen if still relevant with VBox 4.1.4.