Failed to access the USB subsystem, version 4.2.6 -> kernel problem

[mocha]

I'm running stock xubuntu 12.10 with vanilla kernel. Installed virtualbox 4.2.6 from their repository and have the 4.2.6 extension pack installed. My user is a member of vboxusers and I've rebooted. I also tried some 4.1.xx versions with the same results. I have a very unique problem on my hands.

After a reboot if I issue the command "VBoxManage list usbhost", I get the expected output of my host's usb devices. After the host has been running for something like 6 to 12 hours sometimes a little longer, if I run the command again I get "none" as the output and USB is no longer working if I startup Virtualbox. If I run the command with VBOX_USB=sysfs I still get "none". If I run the command as a root user I get the expected output, but I'd rather not run Virtualbox as a root user.

Based on the recommendation of an old bug report on the same topic, I ran "strace -o VBoxSVC.out -ff <VirtualBox installation path>/VBoxSVC" and then "VBoxManage list usbhost" in another terminal and I attached the logs here. I also have a discussion thread here, ​https://forums.virtualbox.org/viewtopic.php?f=7&t=53798

I don't think there is a host hardware problem. My mouse, keyboard, and printer are USB devices and work fine. I also ran a test by plugging in a USB stick and ran a command with dd to write out a dummy 4GB file and didn't have any problems. I checked the motherboard for bad capacitors and don't see any. This hardware was in use for the past 3 years with old versions of Ubuntu and Virtualbox and I never had this problem before.

[mocha]

strace logs when Virtualbox is not seeing my hosts USB devices

[mocha]

strace when VirtualBox is able to see my host devices

[mocha]

This is curious... If you do some grepping on the two sets of strace logs I've posted you will see that when VirtualBox is able to see my host USB devices it says this in the log:

access("/dev/vboxusb", R_OK|X_OK)       = 0

When VirtualBox is not able to see my host USB devices it says this instead:

access("/proc/bus/usb", R_OK|X_OK)      = -1 ENOENT (No such file or directory)

Xubuntu 12.10 uses kernel 3.5.0-22 so of course the /proc/bus/usb is no longer there. The real question is therefore why is VirtualBox spontaneously changing the location in which it looks for the host USB devices???

After reboot everything is great, VirtualBox looks in /dev/vboxusb. After some arbitrary time (6 to 12 hours usually) VirtualBox starts looking in /proc/bus/usb instead??

[Perry G]

I too am seeing this after a few days of uptime. Ubuntu 12.04 host. I'll post the svc log after the next failure.

[Perry G]

I see a new process that I have not seen before, called newgrp vboxusers. Could this be what is confusing the fact that I am really in the vboxusers group? Screen shot attached.

[Michael Thayer]

Mocha, from your strace output it looks like VirtualBox is failing to initialise inotify as the available inotify resources for your user have been exhausted, and it depends on inotify to use the "sysfs" access method. That is why it never even tries "access("/dev/vboxusb")". I don't know whether it is VirtualBox or something else which is using up those resources. This page:

​http://unix.stackexchange.com/questions/15509/whos-consuming-my-inotify-resources

has some suggestions about finding that out that you might like to try.

[Michael Thayer]

The irony of it. I decided to investigate alternative ways of doing this which didn't use inotify and wanted to try out some code in a Ubuntu 5.04 VM to see if it worked with an old kernel. And when I tried to attach a USB device to the VM to test the code I found I couldn't - seeminlgy because I had run into the same condition that you are reporting on my host.

So for the record, the tests I asked Mocha to try showed that there aren't that many processes using inotify as my user, but that "/usr/lib/unity-lens-applications/unity-applications-daemon" made over a thousand calls to sys_inotify_add_watch(2) in the space of a few minutes.

[Michael Thayer]

That doesn't seem to be it. For one, those calls are all made on the same small set of files, and for another, looking at the code for inotify_init1(2) in the kernel, that EMFILE really means out of instances, not of watches. When I terminate all VirtualBox-related processes and start "tail -f" it also warns me that "inotify cannot be used", so this doesn't look like our fault, but we should clearly not be depending on inotify for our USB functionality.

[Michael Thayer]

Seems to be a kernel bug as I was beginning to suspect:

​https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101666

[Perry G]

That would explain why I have not been able to send supporting data. I am running 3.2.0-37 now which has the fix.

Thank you Michael.

[mocha]

I was quiet on this for a few days since I updated my kernel to 3.5.0-23 per comment 55 in the above referenced link and wanted to make sure it fixed the problem ​https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101666/comments/55. It does fix the problem, my uptime has been 10 days and everything is working.

[Michael Thayer]

Thanks for the feedback.