Bug 254412
| Summary: | emulators/virtualbox-ose-additions - Boot time crash - Sleeping thread owns a non-sleepable lock | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | David R. Bergstein <david.r.bergstein> |
| Component: | Individual Port(s) | Assignee: | Virtualbox Team (Nobody) <vbox> |
| Status: | Closed DUPLICATE | ||
| Severity: | Affects Some People | CC: | bdrewery, freebsd, grahamperrin, jethro, markj, rene |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(vbox) |
| Version: | Latest | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| See Also: | https://github.com/freebsd/freebsd-ports/pull/115 | ||
| Attachments: | |||
|
Description
David R. Bergstein
2021-03-19 23:46:19 UTC
Also seeing this on a 14-CURRENT guest, using virtualbox-ose-additions 6.1.18 from pkg. Host is Windows 10 with VirtualBox Version 6.1.18 r142142 with both the VMSVGA and VBoxSVGA display adaptors if that matters. Disabling vboxguest_load="YES" (and vboxservice_load) in rc.conf, if I boot fully and wait a bit, it seems to work okay about 50% of the time if I manually start it with: $ sudo service vboxguest onestart I can then onestart vboxservice and everything seems to work OK as expected. The other 50% it goes straight to ddb with the same "Sleeping thread (tid ######, pid ###) owns a non-sleepable lock" error and stack trace as comment #1. So intermittent not just at boot-time. Just had anther crash with the error above at boot time, this time on FreeBSD 13.0-RC3. I can confirm that this happens in 12-STABLE (n232872-af0cea80104) too. Sometimes on reboot; other times from a cold boot. On every (re)boot FreeBSD was seeing panic with (Windows host & VirtualBOx 6.1.18) vbox-ose-additions 6.1.18; then restarting by itself normally. Got tiring fast. I have reverted to VirutalBox 5.2.44 on Windows; and to -additions-legacy on FreeBSD. Let me know please if something I could try with 6.1.18 version components. Windows 10 21H1 host, 6.1.22. 13.0-RELEASE-p1 guest, UFS, 6.1.22 additions: * first boot after updating the system and pkg upgrade, panic-free * restarted, a panic, I didn't note the details * a few subsequent restarts, panic-free * I edited /etc/rc.conf to enable crash dumps but then dumps did not occur because my edition was lost (this, presumably, would not happen with ZFS) * after repeat edition of /etc/rc.conf and installation of devel/gdb I got a crash dump but still, can't get what's required from the dump :-( Created attachment 225420 [details]
panic with guest additions 6.2.2 in a 13.0-RELEASE-p1 guest
Created attachment 225426 [details] Screenshot: panic-free with the guest limited to a single processor (In reply to Graham Perrin from comment #5) Tested with a different 13.0-RELEASE-p1 guest (booting from ZFS instead of UFS) on the same Windows host. As far as I can tell, kernel panics are: a) _highly_ reproducible when the guest uses all available processors, with /etc/rc.conf set to vboxguest_enable="NO" vboxservice_enable="NO" – at ttyv1, login as root then kldload vboxguest kldunload vboxguest kldload vboxguest kldunload vboxguest kldload vboxguest kldunload vboxguest … et cetera, until a panic occurs b) _never_ reproducible when the guest is limited to one (1) processor, or booted in safe mode – with one processor, I was able to repeatedly run the one-line command below. kldload vboxguest && kldunload vboxguest && kldload vboxguest && kldunload vboxguest && kldload vboxguest && kldunload vboxguest This bug 254412 is probably a duplicate of bug 236917, > emulators/virtualbox-ose: Sleeping thread owns a non-sleepable lock kernel panic – I'll continue there. (In reply to parv from comment #4) > … reverted to VirutalBox 5.2.44 on Windows; … Consider the panic with 5.2.44_4 at bug 236917 comment 3 … (In reply to Graham Perrin from comment #8) I want to note that PR #236917 is about emulators/virtualbox-ose 5.2.44. I am concerned with use of emulators/virtualbox-ose-additions 6.1 when VirutalBox 6.1 virtual machine runs on Windows. Both could have the same/similar reason for the bug. Sincere apologies from me (at bug 236917 comment 9) for confusing the two bugs. It took _way_ too long for me to realise my mistake. Shouting this at myself: there, 236917 = panics of FreeBSD HOSTS here, 254412 = panics of FreeBSD GUESTS (In reply to Graham Perrin from comment #6) Quoting John Baldwin: > … the breakage is somewhere in this code: > > Sleeping thread (tid 100099, pid 155) owns a non-sleepable lock > KDB: stack backtrace of thread 100099: > #0 0xffffffff80c166f1 at mi_switch+0xc1 > #1 0xffffffff8233cf37 at rtR0SemEventMultiBsdWait+0x297 > #2 0xffffffff8231d36a at vgdrvHgcmAsyncWaitCallbackWorker+0x14a > #3 0xffffffff8231e49b at VbglR0HGCMInternalConnect+0x11b > #4 0xffffffff8231ad33 at VGDrvCommonIoCtl+0xb53 > #5 0xffffffff82319af6 at VGDrvCommonProcessOptionsFromHost+0x146 > #6 0xffffffff8231d9f8 at vgdrvFreeBSDAttach+0x1d8 > #7 0xffffffff80c4670d at device_attach+0x3dd Created attachment 226041 [details] panic with guest additions 5.2.44_3 in a 13.0-RELEASE-p2 guest (In reply to parv from comment #4) > I have reverted to VirutalBox 5.2.44 on Windows; and to > -additions-legacy on FreeBSD. … Maybe (far) less likely to occur with legacy but still, with virtualbox-ose-additions-legacy-5-2.44_3, it's possible to produce this panic. <https://github.com/freebsd/freebsd-ports/pull/115> > Update package descriptions and messages for some VirtualBox ports > … Draft; comments and corrections are invited. Thank you. (If my use of GitHub for a pull request raises an eyebrow, please see bug 254266 comment 14.) (In reply to Graham Perrin from comment #13) > (If my use of GitHub for a pull request raises an eyebrow [...]) No, eyebrows raising on my part. --- pedantic mode ON The only practical implication of using a pull request is that, at present, the ports tree has no tooling for that, so it does require some extra manual work on the part of committers to review and apply the patch. Objectively, for people who anyway use git and github often and are used to those tools, the extra work is very small and definitely not an obstacle for me in this case, due to the patch itself being simple. As an added note a more complex patch involving many files could create an harder "conversion" step, but nothing gigantic anyway. --- pedantic mode OFF Anyway, I need time to properly read your patch and correctly form and state some comments and suggestions I have thought about in a very quick and superficial read. I'll happily followup, but allow me to take some time. (In reply to Guido Falsi from comment #14) Thanks for your understanding and explanation. Much appreciated. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=352af02b389202ac426ecf026ac65bff7c61bd41 commit 352af02b389202ac426ecf026ac65bff7c61bd41 Author: Graham Perrin <grahamperrin@gmail.com> AuthorDate: 2021-10-21 22:31:36 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2021-10-21 22:32:36 +0000 emulators/virtualbox-ose: Update description and message files - Add updated information about supported versions, installation commands and mitigation for a known issue. - Removed reference to the wiki page. Reviewed on github: https://github.com/freebsd/freebsd-ports/pull/115 PR: 254412 .../virtualbox-ose-additions-legacy/pkg-descr | 18 ++++++++---- .../virtualbox-ose-additions-legacy/pkg-message | 23 +++++++-------- emulators/virtualbox-ose-additions/pkg-descr | 11 ++++---- emulators/virtualbox-ose-additions/pkg-message | 33 +++++++++++++++------- emulators/virtualbox-ose-legacy/pkg-descr | 22 +++++++++++---- emulators/virtualbox-ose/pkg-descr | 13 +++++---- 6 files changed, 77 insertions(+), 43 deletions(-) (In reply to Graham Perrin from comment #13) I committed the changes we agreed in the review. I made a pair of minor changes on the fly before committing. I noticed your patch contained trailing whitespace on a lot of lines. While it may look unimportant you should really avoid that, we try to keep files in the tree as tidy as possible. Cleaning these things adds manual work to committing things. Big thanks 👍 I have been running FreeBSD 13 in VirtualBox 6.1.22 (currently .26) since around Oct 17. Today I got the first crash on a reboot.
At the time of saving of the crash dump, I did not have gdb installed (now I have). core.* registered the complaint about missing "kernel debugger". I would be happy to upload the {core,vmcore,info}* files if that could be helpful nonetheless.
I saw the note (at above mentioned pull request in comment 16) about reducing number of availble CPUs to 1. I may do that if the problem would persist, or just go back to VirtualBox 5.2.
(In reply to Graham Perrin from comment #7) > b) _never_ reproducible when the guest is limited to > one (1) processor, or booted in safe mode Hint: kern.smp.disabled=1 𡀓– in /etc/sysctl.conf then restart the guest. (More streamlined than stopping the guest, setting the equivalent limitation in the VirtualBox GUI then starting the guest.) (In reply to Graham Perrin from comment #20) > – in /etc/sysctl.conf then … Correction: > – in /boot/loader.conf then … ---- Sorry! (I previously had a misleading test result with use of /etc/sysctl.conf – I'll not bore people with the details.) I get a very similar panic on a Tuxedo Linux running VirtualBox 7.0.8 as host and FreeBSD 14-20230525-amd64 having VirtualBox guest extensions 6.1.44 I have one CPU selected in VirtualBox and added kern.smp.disabled=1 to /boot/loader.conf in the guest. One thing I can think of is to downgrade VirtualBox on the host but only version 7.0.8 is available there, or perhaps try their guest additions ISO? The supplied guest ISO has extensions/installers for Windows, Linux, Solaris, Darwin, even OS/2 but not for *BSD. The guest FreeBSD runs fine without the guest modules loaded. *** This bug has been marked as a duplicate of bug 264833 *** |
