BUG: soft lockup - CPU#0 stuck for 10s on CentOS 6 guest

[SyRenity]

Hi.

I have a strange problem which appeared after I upgraded either the VBox / CentOS 6 distribution. The guest VM hangs sporadically, and also takes 100% of one of CPU's.

The only way to recover is to restart the guest, which then has in logs:

BUG: soft lockup - CPU#0 stuck for 10s


Any idea why this happening, and how to avoid it?

Thanks.

[Perryg]

Normally I see this with RT kernels in a virtual machine.
You can set the timer frequency to 100Hz (optimal for virtual Linux machines) just by adding divider=10 as the kernel option and fix this.

[SyRenity]

Thanks.

VMWare and ServerFault say (can't post links yet) that it works only on 5 and not 6.
Also, the syntax is notsc divider=10, rather then just divider=10.

So what is the correct form?

[Perryg]

Well if this is a tickless kernel then no the divider=10 will not help in which case you should try try adding noapic to the end of the kernel line.
In any case the entry is as written.

[SyRenity]

Seems RHEL/CentOS 6 feature tickless kernel indeed.

I've added noapic, and will update how it works.

Thanks for the help!

[SyRenity]

After several hours of running, it still hanged.

Any other suggestions?

[Perryg]

Post the guests log file just after the hang (as an attachment)

[SyRenity]

Attached is the log file, thanks for your help again.

[Perryg]

It looks like you have power manager running on the guest/host. Do you?

[SyRenity]

Seems indeed that I had running "gnome-power-manager" since the installation.

I removed it, but not the "devkit-power-daemon", as it pulled a whole bunch of dependencies after it.

Will test and update here.

[SyRenity]

Still happens, even with the power managed removed.

Any additional thoughts?

[Perryg]

Nope.
All the resets in the last log showed that something was/is resetting the guest and power management was my last thought as to why.

Additionally I would ask the Centos guys what might be the issue. I don't use cent for more than a few hours at a time while testing builds and of course don't see this issue as it appears to take longer for you.

[Thomas Baeckeroot]

Hi all,

It happened to me recently. As far as I saw, it is pretty always an "hardware" issue.
In my case it happened on a Ubuntu VM after changing USB configuration of the VM (moving to 'USB 3.0 xHCI'). I resolved just by moving back to controller 2.0. Easy.
While I had "USB 3.0 xHCI" selected (and not working), VBox.log was stuck, ending with:
00:00:09.824435 xHCI: Hardware reset
00:00:09.824528 VUSB: HidMouse: reset request is ignored, the device is already resetting!
00:00:09.826530 xHCI: USB Operational
00:00:09.841794 xHCI: root hub-attached device reset completed with VINF_SUCCESS

As I did not absolutely needed it, I did not insisted in making 'USB 3.0 xHCI' working there…

Some other users had this "CPU#0 stuck for xx s" caused by sound HW changes (virtual or physical), or kernel updates.

My advice: check in VBox.log which hardware is causing the issue and try changing this component.

[Vicky0709]

Hola, mi notebook tiene el mismo error, trato de importar un archivo .ova para practicar unas config de mi carrera y al iniciar la maquina en virtualbox (5.8.2) me arroja el error de la imagen adjunta.

Mi notebook tiene:
Windows 10 de 64 bits
8GB de RAM
Procesador AMD A-8 6410 APU (AMD Radeon R5 graphics) 2.00 GHz
Con 2 tarjetas de video

[mpack]

That is a guest error, so I think you'll have to ask about that on a CentOS support site, if Perry's comments above don't help.