On Mon, 26 Apr 2010, Sarah Sharp wrote: > > Yes indeed. Can you track it down? > > I figured out what triggers this behavior. It's related to the roothub failing > to suspend because the xHCI driver doesn't implement it. If I unplug my > express card, and then immediately cat the roothub file, it succeeds. If I > wait a bit until the roothub fails to suspend, cat fails. The same is true of > the external hub: if I cat the file before the core attempts to suspend it, the > cat succeeds, and it fails after the core tries to suspend the hub. Aha. > > Also check out usbdev_read() in the same file. If cat's read call > > reaches that routine then it must trigger the -EINVAL return code > > somehow (I can't imagine how). > > I added debugging (patch is attached). An strace of the cat and the debugging > shows that the call fails when the file is opened, in usbdev_open(), due to the > auto-resume of the device failing: > > Apr 26 20:14:18 xanatos kernel: [42053.643810] Attempting to create file for usb bus 1 dev 1,minor = 189, major = 0 > Apr 26 20:14:18 xanatos kernel: [42053.649729] Created file for usb bus 1 dev 1,minor = 189, major = 0 > Apr 26 20:14:18 xanatos kernel: [42053.740532] hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0000 > Apr 26 20:14:19 xanatos kernel: [42053.931780] Called usbdev_read - pos = 0 > Apr 26 20:14:19 xanatos kernel: [42053.931804] Called usbdev_read - pos = 18 > Apr 26 20:14:19 xanatos kernel: [42053.931828] Called usbdev_read - pos = 26 > Apr 26 20:14:19 xanatos kernel: [42053.932449] Called usbdev_read - pos = 0 > Apr 26 20:14:19 xanatos kernel: [42053.932464] Called usbdev_read - pos = 18 > Apr 26 20:14:19 xanatos kernel: [42053.932486] Called usbdev_read - pos = 26 > Apr 26 20:14:21 xanatos kernel: [42056.157017] Called usbdev_read - pos = 0 > Apr 26 20:14:21 xanatos kernel: [42056.157387] Called usbdev_read - pos = 43 > Apr 26 20:14:23 xanatos kernel: [42058.816150] hub 1-0:1.0: hub_suspend > Apr 26 20:14:23 xanatos kernel: [42058.816363] usb usb1: bus auto-suspend > Apr 26 20:14:23 xanatos kernel: [42058.816370] usb usb1: bus suspend fail, err -2 > Apr 26 20:14:23 xanatos kernel: [42058.816376] hub 1-0:1.0: hub_resume > Apr 26 20:14:23 xanatos kernel: [42058.816703] hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0000 > Apr 26 20:14:27 xanatos kernel: [42062.468948] usbdev_open: Auto-resume failed. That's clear enough. > It seems to me that if the hub suspend failed, due to it not being > implemented, it should have been marked as being active or not > suspended, and a call to usb_autoresume_device() ought to succeed > because the device is not suspended. This depends on the error code for the failed suspend call. Prior to 2.6.34-rc1, or if the error code is -EBUSY or -EAGAIN, then things will work as you say. But in 2.6.34, if the code is anything else then the device is marked as being in an error state, neither active nor suspended. I guess the simplest answer is to change the -ENOENT error code in hcd.c:bus_suspend() to -EBUSY. Does that fix your problem? > So the question becomes, can/should we fix this in usbdev_open()? Even > if the AMD power managment patches get merged for 2.6.35, we should > probably have a fix for older kernels. Or can the power management > patches be backported, since they don't add any new APIs? It seems like > a big change to backport for a small nuisance. I'm not sure what you're talking about here, but the fix described above seems simple enough and it doesn't need to be backported. You might want to review the proposed suspend patches for xhci-hcd to make sure they never return any errors other than -EAGAIN or -EBUSY. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
