From: Sarah Sharp on
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