pm_op(): usb_dev_suspend+0x0/0x10 returns -2 on USB device 8087:0020
in [Kernel]
|
From: Sarah Sharp on 1 Mar 2010 19:50 On Sat, Feb 27, 2010 at 09:02:11AM +0100, �kos Mar�y wrote: > Sarah, > > > Actually, I wonder if 2.6.32 stable needs commit bcef3fd from 2.6.33. > > If the xHCI driver wasn't cleaning up the endpoint rings properly after > > a transfer error, I suppose the hardware could get wedged. > > I see. where would I get this commit from? I have to stick with 2.6.32, > as I'm using the binary ATI video driver, which doesn't work with 2.6.33... > > > If the hardware wasn't responding properly to commands, then URBs > > wouldn't have been able to be killed, the USB core would have sat around > > waiting on those URBs, and rmmod could never exit. I need a more > > detailed log to figure out exactly why the hardware is wedged though. > > Let me make the less-verbose debugging patch so you don't get log > > corruption, and then we'll see what's going on. > > let me know how I can use this.. Akos, I've attached two patches that apply against 2.6.32.9. The first limits the amount of debugging from the xHCI driver to prevent log file corruption. The second is a backport of the commit bcef3fd from Linus' 2.6.33 tree. I think this is the fix you need, but I can't be sure until I see the complete log from the first patch. Please apply the first patch, recompile with CONFIG_USB_XHCI_HCD_DEBUGGING=y, and send me the results of `tail -f /var/log/kern.log | tee /tmp/xhci-hp-envy-15.log`. You'll need to load the xHCI driver with the log_level module parameter set to 1095, like so: sudo insmod drivers/usb/host/xhci.ko log_level=1095 That will limit the debugging to output that relates to errors on transfer events, hardware quirks, commands sent to the hardware, and port status reporting. When the driver is running, try an unplug of your USB DVD device and an xHCI driver module remove. Then apply the second patch, recompile, and do the same experiment. Thanks, Sarah Sharp |