[Bug 1202851] New: Shutdown or reboot of VirtualBox guest with usb device attached causes guest to abort
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 Bug ID: 1202851 Summary: Shutdown or reboot of VirtualBox guest with usb device attached causes guest to abort Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs@suse.de Reporter: David.Boyd49@twc.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Tumbleweed server with VirtualBox 6.1.36 installed. Testing with many guests: Arch Linux, debian, fedora (stable and rawhide), FreeBSD, Linux Mint, openSUSE LEAP 15.4, openSUSE Tumbleweed. If a USB device (usually a flash drive) is attached when the guest is shutdown or rebooted, the guest ends with an "Aborted" status. This is new with 6.1.36 of VirtualBox from the opensuse Tumbleweed repository. This problem is a nuisance with shutdown but precludes a successful reboot requiring user attention. This issue is not observed when openSUSE LEAP 15.4 is the host. There are no useful messages in the log(s). If the user remembers to detach the USB device before rebooting, the problem can be avoided. Yeah, like that's going to happen. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c2 --- Comment #2 from Larry Rainey <llrainey15@gmail.com> --- I tested Host Tumbleweed - guest Windows 10 and OpenSUSE 15.4 the USB drive connection is returned to host on saving guest. Guest start fine and I can re-attach the USB drive on restart. My guess is the guest additions or extension pack is not currently 6.1.36. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c3 --- Comment #3 from David Boyd <David.Boyd49@twc.com> --- Created attachment 861174 --> http://bugzilla.opensuse.org/attachment.cgi?id=861174&action=edit VirtualBox Log after guest (Leap 15.4) aborted on reboot Tumbleweed software version(s): VirtualBox: 6.1.36-2.1 VirtualBox Extension Pack: 6.1.36r152435 Leap 15.4 software version(s): VirtualBox Guest Additions: 6.1.36-SUSEr152435 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c4 --- Comment #4 from Larry Finger <Larry.Finger@gmail.com> --- Unfortunately, the machine log did not show much. The only thing is that your VM log has 00:05:58.179284 xHCI: USB Suspended 00:05:58.182952 ACPI: Reset initiated by ACPI 00:05:58.183013 Changing the VM state from 'RUNNING' to 'RESETTING' Mine shows 00:01:13.598452 OHCI: Software reset 00:01:13.679583 ACPI: Entering S5 power state (power down) 00:01:13.679638 Changing the VM state from 'RUNNING' to 'POWERING_OFF' I did a normal shutdown from the desktop. My system is failing to mount USB3 sticks on a USB3 port, which is why I have OHCI rather than xHCI. I do not understand why you are getting a reset rather than a power down. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c5 --- Comment #5 from Larry Rainey <llrainey15@gmail.com> --- Mine are xHCI guests My current and last log for state and xHCI grep "VM state" * VBox.log:00:00:01.158257 Changing the VM state from 'CREATING' to 'CREATED' VBox.log:00:00:01.160064 Changing the VM state from 'CREATED' to 'LOADING' VBox.log:00:00:07.446442 Changing the VM state from 'LOADING' to 'SUSPENDED' VBox.log:00:00:07.446539 Changing the VM state from 'SUSPENDED' to 'RESUMING' VBox.log:00:00:07.446779 Changing the VM state from 'RESUMING' to 'RUNNING' VBox.log.1:00:00:01.365632 Changing the VM state from 'CREATING' to 'CREATED' VBox.log.1:00:00:01.369105 Changing the VM state from 'CREATED' to 'LOADING' VBox.log.1:00:00:08.974442 Changing the VM state from 'LOADING' to 'SUSPENDED' VBox.log.1:00:00:08.974591 Changing the VM state from 'SUSPENDED' to 'RESUMING' VBox.log.1:00:00:08.975208 Changing the VM state from 'RESUMING' to 'RUNNING' VBox.log.1:47:57:54.387132 Changing the VM state from 'RUNNING' to 'SUSPENDING' VBox.log.1:47:57:54.477123 Changing the VM state from 'SUSPENDING' to 'SUSPENDED' VBox.log.1:47:57:58.127620 GUI: Request for close-action to save VM state. VBox.log.1:47:57:58.127634 GUI: Passing request to save VM state from machine-logic to UI session. VBox.log.1:47:57:58.128275 Changing the VM state from 'SUSPENDED' to 'SAVING' VBox.log.1:47:58:07.008174 SSM: Successfully saved the VM state to '/vm/suse15/Snapshots/2022-08-29T14-22-56-115974000Z.sav' VBox.log.1:47:58:07.008184 Changing the VM state from 'SAVING' to 'SUSPENDED' VBox.log.1:47:58:07.085815 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF' VBox.log.1:47:58:07.086871 Changing the VM state from 'POWERING_OFF' to 'OFF' VBox.log.1:47:58:07.088171 Changing the VM state from 'OFF' to 'DESTROYING' VBox.log.1:47:58:07.267446 Changing the VM state from 'DESTROYING' to 'TERMINATED' grep xHCI * VBox.log.1:47:58:07.089799 /PDM/CritSects/xHCIIntr#0/ContentionR3 0 times VBox.log.1:47:58:07.089802 /PDM/CritSects/xHCIIntr#0/ContentionRZLock 0 times VBox.log.1:47:58:07.089804 /PDM/CritSects/xHCIIntr#0/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089806 /PDM/CritSects/xHCIIntr#1/ContentionR3 0 times VBox.log.1:47:58:07.089809 /PDM/CritSects/xHCIIntr#1/ContentionRZLock 0 times VBox.log.1:47:58:07.089811 /PDM/CritSects/xHCIIntr#1/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089814 /PDM/CritSects/xHCIIntr#2/ContentionR3 0 times VBox.log.1:47:58:07.089816 /PDM/CritSects/xHCIIntr#2/ContentionRZLock 0 times VBox.log.1:47:58:07.089818 /PDM/CritSects/xHCIIntr#2/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089821 /PDM/CritSects/xHCIIntr#3/ContentionR3 0 times VBox.log.1:47:58:07.089823 /PDM/CritSects/xHCIIntr#3/ContentionRZLock 0 times VBox.log.1:47:58:07.089825 /PDM/CritSects/xHCIIntr#3/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089828 /PDM/CritSects/xHCIIntr#4/ContentionR3 0 times VBox.log.1:47:58:07.089830 /PDM/CritSects/xHCIIntr#4/ContentionRZLock 0 times VBox.log.1:47:58:07.089832 /PDM/CritSects/xHCIIntr#4/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089835 /PDM/CritSects/xHCIIntr#5/ContentionR3 0 times VBox.log.1:47:58:07.089837 /PDM/CritSects/xHCIIntr#5/ContentionRZLock 0 times VBox.log.1:47:58:07.089840 /PDM/CritSects/xHCIIntr#5/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089842 /PDM/CritSects/xHCIIntr#6/ContentionR3 0 times VBox.log.1:47:58:07.089844 /PDM/CritSects/xHCIIntr#6/ContentionRZLock 0 times VBox.log.1:47:58:07.089847 /PDM/CritSects/xHCIIntr#6/ContentionRZUnlock 0 times VBox.log.1:47:58:07.089849 /PDM/CritSects/xHCIIntr#7/ContentionR3 0 times VBox.log.1:47:58:07.089851 /PDM/CritSects/xHCIIntr#7/ContentionRZLock 0 times VBox.log.1:47:58:07.089856 /PDM/CritSects/xHCIIntr#7/ContentionRZUnlock 0 times -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c6 --- Comment #6 from David Boyd <David.Boyd49@twc.com> --- Yesterday (Monday), I visited the systems with the reboot (or shutdown) problem(s). The VirtualBox VM guests have this problem only if the USB device is version 3.0+. The Tumbleweed systems were upgraded with Sandisk USB 3.2gen1 flash drives at the beginning of Summer. They were running VirtualBox 6.1.34 at that time. When the upgrades to 6.1.36 occurred, this problem began. The Leap 15.4 systems were not upgraded with new flash drives. The upgrade from 6.1.34 to 6.1.36 went without issue. These system were/are equipped with Sandisk Cruzer Glide flash drives (USB version 2.0). If Sandisk USB 3.2gen1 flash drives are attached to VirtualBox VM guests on the Leap 15.4 (host) systems, when the VirtualBox VM guests are rebooted, the same "Aborted" status occurs. Just for grins, we tested against a fedora (fc36) host ... the results were identical. All tests were conducted against Leap 15.4 guests. All VirtualBox software versions are 6.1.36 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c7 --- Comment #7 from Larry Finger <Larry.Finger@gmail.com> --- Thanks for testing with Fedora. That demonstrates that the problem is with VirtualBox, not with our implementation. I checked the VB bug tracker, but I didn't find anything directly appropriate; however, one of the defect descriptions I read discussed getting something in /var/log/messages. After one of your crashes, do you see anything logged there? If so, that would give us a place to look. Oracle just released VB 7.0.0-BETA1. That means that their developers are busy with the new release, and that 7.0.0 will be released in about 2 months. The best of all results would be that the problem is fixed in 7.0.0. At least, a new defect at that point would get more attention at Oracle. As neither of the maintainers at openSUSE can duplicate the problem, it will be difficult to see what happens unless some error is logged. The VM logs only show the result, not the cause. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c8 --- Comment #8 from Larry Rainey <llrainey15@gmail.com> --- Is the USB 3.2 drive available in Linux after the shutdown/reboot or is it in limbo. If it is in limbo - you may have found a Kernel flaw - the kernel may not see that as a disk and is not returning it to the available USB pool of devices. If it is still "attached" to the virtual machine instead of the host. Virtualbox is trying to reconnect to a limbo drive and forced to abort the virtual machine. Now that the Virtual Machine has aborted the limbo drive is back to Linux and can be assigned again. This is my guess as to why - I am trying to guess as to why - I know that when USB 3 came out - many issues with devices happened in the kernel. 12 years have passed but USB 3 is still evolving and it is possible that some of the new thunderbolt code has issues knowing the device categories correctly. I suspect that your drive is plugged into a unit that has thunderbolt USB port(s). My 2 cents. - YMMV -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c9 --- Comment #9 from David Boyd <David.Boyd49@twc.com> --- Created attachment 861198 --> http://bugzilla.opensuse.org/attachment.cgi?id=861198&action=edit dmesg output at VirtualBox VM guest reboot Yes, as a matter of fact, there are some "interesting" messages in the system log. Here is what I have. I will make time to test with the BETA software in the next few days. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c10 --- Comment #10 from David Boyd <David.Boyd49@twc.com> --- Larry Rainey, The device is fully available to Linux and ready for use. Starting the VirtualBox VM guest and (re)attaching the USB device is all that is necessary for reuse. I hope this helps. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c11 --- Comment #11 from David Boyd <David.Boyd49@twc.com> --- The user expectation is that when he/she reboots the VirtualBox VM guest, the previously attached USB device is still attached. This "Aborted" condition detaches the USB device and after restarting the VirtualBox VM guest, the user must remember to reattached the USB device. Most of these users never shutdown the VirtualBox VM guest(s). The problem is annoying to me, but I'm not the user who's scheduled backup didn't run because there was no USB device available. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c12 --- Comment #12 from Larry Rainey <llrainey15@gmail.com> --- Interesting as I have not tried to see if a USB drive stays attached to the 15.4 version. The Tumbleweed machines I have the USB drive is disconnected when the shutdown occurs and has to be re-attached on restart. Have you tried mounting the usb drive in Linux and make a permanent shared VB folder to the drive that way? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c13 --- Comment #13 from Larry Finger <Larry.Finger@gmail.com> --- Running the debugger on VBoxDD.so and looking at offset 178000, which is indicated as the segfault address in your messages, I get: finger@localhost:~>gdb /usr/lib/virtualbox/VBoxDD.so (gdb) list *178000 0x2b750 is in PS2MByteToAux(PDMDEVINSR3*, PS2M*, unsigned char) (/usr/src/debug/virtualbox-6.1.36-2.1.x86_64/src/VBox/Devices/Input/DevPS2M.cpp:263). Downloading 0.04 MB source file /usr/src/debug/virtualbox-6.1.36-2.1.x86_64/src/VBox/Devices/Input/DevPS2M.cpp 258 { 259 switch (pThis->enmKnockState) 260 { 261 case PS2M_KNOCK_INITIAL: 262 if (rate == 200) 263 pThis->enmKnockState = PS2M_KNOCK_1ST; 264 break; 265 case PS2M_KNOCK_1ST: 266 if (rate == 100) 267 pThis->enmKnockState = PS2M_KNOCK_IMPS2_2ND; Note: I had to allow the debugger to download the symbols. I have not looked at the source code, but the error location only makes sense if pThis->enmKnockState is read-only. The switch statement show that it can be read. Before I look at the code, could you please verify that you get the same location for the segfault? You will likely need to install the debugger. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c14 --- Comment #14 from David Boyd <David.Boyd49@twc.com> --- Larry, My dump of VBoxDD.so (*178000) looks exactly the same as yours. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c15 --- Comment #15 from Larry Finger <Larry.Finger@gmail.com> --- I realized that the 178000 should have been 0x178000, but your getting the same as I did means that we are running the same code. When I do 'list 0x178000', I get (gdb) list *0x178000 0x178000 is in bootp_input (/usr/src/debug/virtualbox-6.1.36-2.1.x86_64/src/VBox/Devices/Network/slirp/bootp.c:624). Downloading 0.03 MB source file /usr/src/debug/virtualbox-6.1.36-2.1.x86_64/src/VBox/Devices/Network/slirp/bootp.c 619 { 620 LogRel(("NAT: DHCP Inform was ignored no boot client was found\n")); 621 return -1; 622 } 623 624 LogRel(("NAT: DHCP offered IP address %RTnaipv4\n", bc->addr.s_addr)); 625 offReply = dhcp_send_ack(pData, bp, bc, m, /* fDhcpRequest=*/ 0); 626 return offReply; 627 } When the error happens at line 624. It looks as if struct bc->addr is invalid. The code checks bc, but not bc->addr. It will be easy to check the second struct and break out, but it may lead to other problems as this is an effect, not the real cause! At least I have the data for a good bugzilla report at Oracle. Thanks for your help. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c16 --- Comment #16 from Larry Finger <Larry.Finger@gmail.com> --- (In reply to David Boyd from comment #9)
Created attachment 861198 [details] dmesg output at VirtualBox VM guest reboot
Yes, as a matter of fact, there are some "interesting" messages in the system log.
Was this log message generated at shutdown or bootup? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c17 --- Comment #17 from David Boyd <David.Boyd49@twc.com> --- The VirtualBox VM guest "Aborted" during the shutdown and restart attempt. I didn't bother restarting it. I hope that answers your question. David. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c18 --- Comment #18 from Larry Finger <Larry.Finger@gmail.com> --- Yes, that is what I needed. The defect post at Oracle is https://www.virtualbox.org/attachment/ticket/21086/. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c19 --- Comment #19 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1202851) was mentioned in https://build.opensuse.org/request/show/1029814 15.4 / virtualbox https://build.opensuse.org/request/show/1029815 15.3 / virtualbox -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 http://bugzilla.opensuse.org/show_bug.cgi?id=1202851#c21 --- Comment #21 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1202851) was mentioned in https://build.opensuse.org/request/show/1037416 15.4 / virtualbox -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com