Kernel reports BUG: using smp_processor_id when VM shuts down. -> fixed in SVN

[Paul Kronenwetter]

Upon shutdown of a guest VM I see this block in /var/log/messages:

Dec 22 22:58:44 ex8185 BUG: using smp_processor_id() in preemptible [00000001] code: VirtualBox/8571
Dec 22 22:58:44 ex8185 caller is RTMpCpuId+0x8/0x3f [vboxdrv]
Dec 22 22:58:44 ex8185 Pid: 8571, comm: VirtualBox Tainted: P        2.6.24-tuxonice-r9 #1
Dec 22 22:58:44 ex8185 [<c0104fd5>] show_trace_log_lvl+0x1a/0x2f
Dec 22 22:58:44 ex8185 [<c0105948>] show_trace+0x12/0x14
Dec 22 22:58:44 ex8185 [<c01060fe>] dump_stack+0x6c/0x72
Dec 22 22:58:44 ex8185 [<c01f0500>] debug_smp_processor_id+0xa0/0xb4
Dec 22 22:58:44 ex8185 [<f9607d05>] RTMpCpuId+0x8/0x3f [vboxdrv]
Dec 22 22:58:44 ex8185 [<f93ab4b1>] 0xf93ab4b1
Dec 22 22:58:44 ex8185 [<f93b4a29>] 0xf93b4a29
Dec 22 22:58:44 ex8185 [<f93b548f>] 0xf93b548f
Dec 22 22:58:44 ex8185 [<f93b575c>] 0xf93b575c
Dec 22 22:58:44 ex8185 [<f9604af5>] supdrvIOCtl+0xdfe/0x1565 [vboxdrv]
Dec 22 22:58:44 ex8185 [<f9601161>] supdrvOSGetForcedAsyncTscMode+0x149/0x1fa [vboxdrv]
Dec 22 22:58:44 ex8185 [<c0180aee>] do_ioctl+0x22/0x67
Dec 22 22:58:44 ex8185 [<c0180d5b>] vfs_ioctl+0x228/0x23b
Dec 22 22:58:44 ex8185 [<c0180db0>] sys_ioctl+0x42/0x5a
Dec 22 22:58:44 ex8185 [<c0103fd6>] sysenter_past_esp+0x5f/0x85
Dec 22 22:58:44 ex8185 =======================

It doesn't appear to affect operation of the host or subsequent operation of the virtualization system.

[Paul Kronenwetter]

And, now that I've thought more about this... I'm running Gentoo Linux and a TuxOnIce kernel v2.6.24 (-r9). I don't think the TuxOnIce modifications are affecting this but I'm willing and able to try a stock Vanilla kernel or any other that I can obtain sources for, if it helps.

[Romano Giannetti]

It happens to me every time I boot a virtual machine in 2.1.0, at least with kernel 2.6.28. It seem simple to solve:

​http://lkml.indiana.edu/hypermail/linux/kernel/0812.3/00521.html

Quoting Rik van Riel:

Looks like the virtualbox code forgot to switch off preemption before calling smp_processor_id().

This is broken, because the thread could get de-scheduled and re-scheduled onto another CPU, which means the code could end up using the wrong smp processor ID.

[Sander van Leeuwen]

Thanks for the report.