Hi Alan, I've been testing my split hub and USB 3.0 hub support patches, and I've run into an interesting issue with the USB runtime PM support and lsusub/libusb. The background is that device suspend has changed slightly for USB 3.0 devices. Now that there are more "link states" (U0, U1, U2, and U3), the way to suspend a device is through a new control transfer, not the SetPortFeature PORT_SUSPEND. Remote wake has also changed for USB 3.0 devices. Instead of a "device" waking up, there are "functions" on the device that wake up. The old SetFeature DEVICE_REMOTE_WAKEUP isn't valid anymore, and instead the USB core needs to set remote wakeup for each function on the device. The problem starts when I plug in a USB 3.0 hub into my system and the USB core tries to suspend the device. First it tries to enable remote wakeup. But it uses the old remote wakeup control transfer, which causes the device to stall the endpoint. The core then says "won't remote wakeup, status -32" and resumes the hub. I think that's valid fallback behavior, but there's something odd happening with the USB runtime PM system when this happens. When I try to use `lsusb -v` for the device (either with the -s or -d option), lsusb prints "Couldn't open device, some information will be missing" (even with sudo to fix any permission problems). Then it falls back to only printing some of the device descriptors, and stops when it prints bNumConfigurations. It exits fine if I run it as sudo, but if I run it as a normal user, it segfaults after printing the descriptor, and then starts to hang after printing on subsequent runs. Luckily, it's killable, and the hub works normally except for device suspend, but it's disturbing behavior. I've tracked down the issue with the "Couldn't open device" message into the USB core. After the failed suspend, usbdev_open() returns -EINVAL for the USB 3.0 hub. I've added some debugging to the usbfs driver (patch attached), and it looks like usb_autoresume_device() is returning the error code. The only interesting call in there is to pm_runtime_get_sync(). Could there be something wrong with the USB core PM runtime code? It seems like if a device fails to suspend and is resumed, usb_autoresume_device() ought to succeed... Debugging patch, dmesg with usbfs_snoop set, usbmon output, and strace of various lsusb runs are attached. The sequence is plug in the hub, wait for it to suspend, run lsusb, run sudo lsusb -v twice, and then run lsusb -v as a normal user twice. Once it hung as a normal user, it started hanging as a superuser. I suspect libusb may have some issue with not freeing some resource or locking when lsusb hung and I killed it. Sarah Sharp
Attachment:
usb3-pm-issue-2010-12-29-19-16.tar.gz
Description: Binary data
