Solaris 11.1 VirtualBox USB issues with client Win7

[Guyver]

Did some additional testing today with the latest updates to Solaris 11.1.10.6.0...

Brought VM up with broadcomm device unchecked.

after logging into the Win 7 VM, opened devices, usb, x'd the broadcomm bluetooth 4 device.

VBox.log shows the following...

Code: Select all

02:02:34.314839 VUSB: attached '00000000055c2bf0[proxy 0a5c:21e6]' to port 4
02:02:38.181427 USBProxy:Command 0xc0185694 failed. Req.rc=VERR_PIPE_IO_ERROR
02:02:38.181515 USBProxy:usbProxySolarisUrbQueue Failed!! pProxyDev=00000000055c2bf0[proxy 0a5c:21e6] pUrb=0000000004dadc00 EndPt=0x2 bEndpoint=0x2 enmType=2 enmDir=2 cbData=47 rc=VERR_PIPE_IO_ERROR
02:02:38.858560 EHCI: USB Operational
02:02:46.536406 EHCI: USB Suspended

I then disabled the usb device from within Win 7s Device Manager

Code: Select all

02:03:37.793648 USBProxy:Command 0xc0185699 failed. Req.rc=VERR_GENERAL_FAILURE
02:03:37.793717 USBProxy:usbProxySolarisReset failed. rc=-1
02:03:39.777596 EHCI: USB Operational
02:03:58.606617 EHCI: USB Suspended

I then re-enabled the usb device from within Win 7s Device Manager

Code: Select all

02:04:01.643674 USBProxy:Command 0xc0185699 failed. Req.rc=VERR_GENERAL_FAILURE
02:04:01.643697 USBProxy:usbProxySolarisReset failed. rc=-1
02:04:03.244955 EHCI: USB Operational
02:04:10.636637 EHCI: USB Suspended

I then unchecked (removed the x) from the VBox device/usb list for the broadcomm device...

Code: Select all

02:04:11.700641 EHCI: USB Operational
02:04:23.634084 VUSB: detached '00000000055c2bf0[proxy 0a5c:21e6]' from port 4
02:04:25.373531 USBProxy:Command 0xc0185699 failed. Req.rc=VERR_GENERAL_FAILURE
02:04:25.373572 USBProxy:usbProxySolarisReset failed. rc=-1
02:04:25.373666 
02:04:25.373667 !!Assertion Failed!!
02:04:25.373668 Expression: RT_SUCCESS_NP(rc2)
02:04:25.373669 Location  : /home/vbox/tinderbox/sol-rel/src/VBox/Devices/USB/VUSBDevice.cpp(1318) int vusbDevResetThread(RTTHREADINT*, void*)
02:04:25.376374 VERR_TM_UNKNOWN_STATE (-2202) - The timer was in a unknown state. Corruption or stupid coding error.

The VBox VM froze, then terminated - no errors on screen, just this in the log...

[Guyver]

Tested with VBox 4.3 beta 2 - good news - no longer crashes the VM when I detach the usb device from the VM (devices tab, usb, uncheck broadcomm)...

Bad news - still doesn't attach properly, and the VM doesn't respond to keyboard / mouse commands properly.... (had to power off the vm hard)

Code: Select all

00:47:22.943572 VUSB: attached '0000000000993ee0[proxy 0a5c:21e6]' to port 3
00:47:26.500525 USBProxy:Command 0xc0185694 failed. Req.rc=VERR_PIPE_IO_ERROR
00:47:26.500598 USBProxy:usbProxySolarisUrbQueue Failed!! pProxyDev=0000000000993ee0[proxy 0a5c:21e6] pUrb=00000000052d3700 EndPt=0x2 bEndpoint=0x2 enmType=2 enmDir=2 cbData=47 rc=VERR_PIPE_IO_ERROR
00:47:27.444475 EHCI: USB Operational
00:47:35.356616 EHCI: USB Suspended
00:49:32.955249 USBProxy:Command 0xc0185699 failed. Req.rc=VERR_GENERAL_FAILURE
00:49:32.955324 USBProxy:usbProxySolarisReset failed. rc=-1
00:49:34.930635 EHCI: USB Operational
00:49:50.493519 EHCI: USB Suspended
00:49:51.006959 EHCI: USB Operational
00:49:56.765171 USBProxy:Command 0xc0185699 failed. Req.rc=VERR_GENERAL_FAILURE
00:49:56.765222 USBProxy:usbProxySolarisReset failed. rc=-1
00:50:05.707261 EHCI: USB Suspended
00:50:06.613741 EHCI: USB Operational
00:50:14.776867 EHCI: USB Suspended
00:50:20.455270 USBProxy:Command 0xc0185699 failed. Req.rc=VERR_GENERAL_FAILURE
00:50:20.455318 USBProxy:usbProxySolarisReset failed. rc=-1
00:50:20.455349 VUSB: detached '0000000000993ee0[proxy 0a5c:21e6]' from port 3
00:50:22.601365 EHCI: USB Operational
00:50:30.096895 EHCI: USB Suspended

[Guyver]

VB 4.3 Beta 3 - appears to fix the VM hang after disconnecting the non-functional broadcomm device.

Code: Select all

00:18:22.095329 VUSB: attached '000000000541b6d0[proxy 0a5c:21e6]' to port 3
00:18:25.774352 USBProxy:Command 0xc0185694 failed. Req.rc=VERR_PIPE_IO_ERROR
00:18:25.774448 USBProxy:usbProxySolarisUrbQueue Failed!! pProxyDev=000000000541b6d0[proxy 0a5c:21e6] pUrb=000000000544c070 EndPt=0x2 bEndpoint=0x2 enmType=2 enmDir=2 cbData=47 rc=VERR_PIPE_IO_ERROR
00:18:25.915917 EHCI: USB Operational
00:18:33.062191 EHCI: USB Suspended
00:18:48.057295 VUSB: detached '000000000541b6d0[proxy 0a5c:21e6]' from port 3
00:18:50.206639 EHCI: USB Operational
00:19:00.055046 EHCI: USB Suspended

Errors at OS level make it appear that detaching the device from VBox causes it to *fail* in Solaris....

Code: Select all

Sep 24 08:59:23 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@4 (usb_mid1) removed
Sep 24 08:59:23 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@4 (vboxusb0) online
Sep 24 08:59:52 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@4 (vboxusb0) removed
Sep 24 09:00:26 nurb5088250 usba: [ID 691482 kern.warning] WARNING: /pci@0,0/pci17aa,21f6@1a/hub@1 (hubd0): Connecting device on port 4 failed

Getting closer I think...

[Ramshankar]

If you're willing to try VirtualBox 4.3 RC1 with a custom/locally build vboxusb driver, please read on. I have confirmation from one user that this works with his Solaris 11.1 host.

Download VirtualBox 4.3 RC1: (Usual RC1 warning: Do NOT install on production/high-stability systems)
http://download.virtualbox.org/virtualb ... nOS.tar.gz

Download the locally-build vboxusb driver:
http://www.virtualbox.org/download/test ... sol_64.zip (link expires in 14 days)

1. Install VirtualBox 4.3 RC1.
2. Copy "vboxusb" (the one from the zip file) over the existing vboxusb from RC1

Code: Select all

unzip ./vboxusb_r89795_sol_64.zip
sudo cp ./vboxusb /platform/i86pc/kernel/drv/amd64/

3. Reboot your system (not fast reboot) to load the new driver

Code: Select all

sudo reboot -p

4. Verify new driver is loaded after reboot.

Code: Select all

$ modinfo | grep vbox
... ...  vboxusb (VirtualBox USB 4.3.51r89795)

5. Test if VirtualBox USB now works!

[Guyver]

To use one of my favorite words from my Everquest days...

WOOT!!

The bluetooth device is functioning properly now.

I see the approach taken was to remove the device from direct Solaris control and remap to the vboxusb driver, going with a dedicated/locked access to the USB devices, rather than attempting to share them, but I am perfectly fine with this.

Much appreciated!!!

[Ramshankar]

To use one of my favorite words from my Everquest days...

WOOT!!

The bluetooth device is functioning properly now.

Great!

I see the approach taken was to remove the device from direct Solaris control and remap to the vboxusb driver, going with a dedicated/locked access to the USB devices, rather than attempting to share them, but I am perfectly fine with this.

Much appreciated!!!

No no no!

This does not replace any Solaris USB driver. It merely replaces VirtualBox's own vboxusb driver (from RC1) with a vboxusb driver built on my own system (newer Solaris). VirtualBox on Solaris uses its own USB driver (vboxusb) since a long time now.

You will, unfortunately, need this custom-built driver even when 4.3 released until we switch our official build servers (from snv_161) to a newer Solaris version (like one that's on my local dev. machine) which produces a binary-compatible driver with Solaris 11.1.

[Guyver]

What I meant was that the system was detaching the Solaris native driver, and attaching the vboxusb driver as usb devices transition from OS control to Guest control...

I'm seeing the Solaris driver being removed, and the vbox driver being attached.

When I detach a usb device, the vbox device is being deleted, and the OS device attached.

Oct 14 08:56:24 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@3 (usb_mid0) removed <- os level driver
Oct 14 08:56:24 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@3 (vboxusb2) online <- vbox driver replacement
Oct 14 08:56:25 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/miscellaneous@6/video@0 (usbvc0) removed <- os level driver
Oct 14 08:56:25 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/miscellaneous@6 (usb_mid2) removed <- os level driver
Oct 14 08:56:25 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/miscellaneous@6 (vboxusb1) online <- vbox driver replacement
Oct 14 08:58:40 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@4 (usb_mid1) removed <- os level driver
Oct 14 08:58:40 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@1a/hub@1/device@4 (vboxusb0) online <- vbox driver replacement

[Ramshankar]

Ah, yes "replaced" in that way is correct; It's how the vboxusb driver is supposed to operate when it isn't buggy

What I meant was it wasn't replacing Solaris USB drivers on disk. Anyway, glad this interim solution works, thanks for being so patient and for the testing!

[Guyver]

May have spoken too soon here...

usb devices are attaching, and appear to remain attached, however, still getting odd timeouts (bluetooth devices not linking, usb devices getting kernel level timeouts causing fault manager to log a response)...

Code: Select all

Oct 17 09:08:30 nurb5088250 genunix: [ID 408114 kern.info] /pci@0,0/pci17aa,21f6@14/device@1 (vboxusb3) online
Oct 17 09:26:32 nurb5088250 fmd: [ID 377184 daemon.error] SUNW-MSG-ID: USB-8000-2W, TYPE: Fault, VER: 1, SEVERITY: Major
Oct 17 09:26:32 nurb5088250 EVENT-TIME: Thu Oct 17 09:26:32 CDT 2013
Oct 17 09:26:32 nurb5088250 PLATFORM: 24294Y2, CSN: R9YZLBK, HOSTNAME: xxxxxxxx
Oct 17 09:26:32 nurb5088250 SOURCE: eft, REV: 1.16
Oct 17 09:26:32 nurb5088250 EVENT-ID: 65962bc4-b723-c443-cb62-ad30fa42c1f8
Oct 17 09:26:32 nurb5088250 DESC: A packet timeout was detected in the USB device and the corresponding driver may not be able to recover from the errors automatically.
Oct 17 09:26:32 nurb5088250 AUTO-RESPONSE: Device may have been disabled or may not be fully functional.
Oct 17 09:26:32 nurb5088250 IMPACT: Loss of services provided by the device instances associated with this fault.
Oct 17 09:26:32 nurb5088250 REC-ACTION: Use 'fmadm faulty' to provide a more detailed view of this event. Please refer to the associated reference document at http://support.oracle.com/msg/USB-8000-2W for the latest service procedures and policies regarding this diagnosis.

Then another time, I can get it to function just fine - not entirely stable it appears.... (but progress has been made )

[Ramshankar]

Hmm.. The fault manager usually only kicks in for hardware failures. I'm not yet sure how this gets triggered with the VirtualBox USB driver using the device. Does "fmadm faulty" show anything more when this happens?

[bqbauer]

I've been using since RC1 this USB module Ram (can I call you that?) built, and I've had great success. I've been using it for testing changes to our wireless network at work, giving VMs control over a 802.11n USB adapter. USB storage devices have also been working great--in fact, VMs are able to write to USB flash drives at native OS speeds, even though Solaris can't seem to write to flash drives with decent performance. The guests write much faster.... But that's not why I'm posting this message.

I've discovered a problem I've never been able to test before, and it may not be new to VB. I purchased a portable USB 3.0 drive to use primarily for Time Slider backups. It works great for the Solaris host and to the maximum rated performance of the physical drive inside the USB case (the 5400rpm drive specs at ~85-95 MB/s).

However, before I reformatted the drive to ZFS, I tested it on my Windows 7 laptop. Perfect. Then I plugged it into a USB 3.0 port on my Solaris host, assigned it to Windows 8, XP, and Ubuntu guests. Although all guests saw it, they reported it as an unknown device. I also plugged it into a USB 2.0 port with the same results in the guest.

Solaris is natively loading an "ses" driver as reported by by the DDU. Are some or all USB 3.0 devices problematic for VB? Is there a way around this, even if the guest were to see it only it as a USB 2.0 device? Since plugging it into a 2.0 port didn't change the behavior, not sure if there's anything else to try.

[Ramshankar]

I've been using since RC1 this USB module Ram (can I call you that?) built, and I've had great success.

Yes, you may call me Ram. It's pronounced like "Calm" or "Palm" and not like "Sam", just in case anyone is wondering...

I've been using it for testing changes to our wireless network at work, giving VMs control over a 802.11n USB adapter. USB storage devices have also been working great--in fact, VMs are able to write to USB flash drives at native OS speeds, even though Solaris can't seem to write to flash drives with decent performance. The guests write much faster.... But that's not why I'm posting this message.

I've discovered a problem I've never been able to test before, and it may not be new to VB. I purchased a portable USB 3.0 drive to use primarily for Time Slider backups. It works great for the Solaris host and to the maximum rated performance of the physical drive inside the USB case (the 5400rpm drive specs at ~85-95 MB/s).

However, before I reformatted the drive to ZFS, I tested it on my Windows 7 laptop. Perfect. Then I plugged it into a USB 3.0 port on my Solaris host, assigned it to Windows 8, XP, and Ubuntu guests. Although all guests saw it, they reported it as an unknown device. I also plugged it into a USB 2.0 port with the same results in the guest.

Solaris is natively loading an "ses" driver as reported by by the DDU. Are some or all USB 3.0 devices problematic for VB? Is there a way around this, even if the guest were to see it only it as a USB 2.0 device? Since plugging it into a 2.0 port didn't change the behavior, not sure if there's anything else to try.

Not sure about the "ses" driver but when VirtualBox captures the device it always captures the entire device and it would be held by "vboxusb". AFAICT, If VirtualBox detects the device as USB2.0 it should work as long as the device supports USB 2.0. What does "VBoxManage list usbhost" show?

[Guyver]

I'll attempt to re-test (been on vacation) and post fmadm faulty output.

[Guyver]

Have since upgraded to 4.3.2, should I still be using that special build vboxusb driver?

[Ramshankar]

Have since upgraded to 4.3.2, should I still be using that special build vboxusb driver?

Unfortunately, yes. Keep the custom build driver.