On Tue, Apr 27, 2010 at 02:49:24PM -0400, Alan Stern wrote: > 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? usbdev_open() will fail if usb_autoresume_device() returns any error code. But if the return code in hcd.c:bus_suspend() was changed to -EBUSY and usbdev_open() was made to look for that, then the problem should be solved. > > 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. I think they might, if something happens like a memory allocation failure. I'll go look at them again. Sarah Sharp -- 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
