Re: [linux-usb-devel] [PATCH] Ohci-hcd: fix endless loop (second take)

[David Brownell <david-b@pacbell.net>]

On Friday 26 November 2004 09:37, Colin Leroy wrote:
> On 26 Nov 2004 at 09h11, David Brownell wrote:
> > This isn't a good patch either... maybe your best
> > bet would be to find out why the IRQs stopped getting
> > delivered.
> 
> It's probably a linux-wlan-ng issue... 

I suspect PPC resume issues myself.


> What do you think  
> of these logs ?
> 
> #resume logs... 
> #disconnecting the stick:
> usb 4-1: USB disconnect, address 2
> ohci_hcd 0001:10:1b.1: IRQ INTR_SF lossage

That does seem to be the first problem; fixing
it (that is, making sure IRQs arrive again!)
should make the rest go away.


> hfa384x_usbin_callback: Fatal, failed to resubmit rx_urb. error=-19
> hfa384x_dorrid: ctlx failure=REQ_TIMEOUT
> prism2sta_mlmerequest: Failed to read eth1 statistics: error=-5

Those look like plausible ways for that driver to
behave.  "-19" == "-ENODEV" for device-gone (you
unplugged it!), though the rest (timeout, EIO)
suggest that WLAN code fault recovery is wierd.


> #reconnecting the stick:
> usb 4-1: new full speed USB device using address 3
> usb 4-1: control timeout on ep0out

As expected, if IRQs aren't arriving.  Though you
may not be using the latest kernel; it's supposed
to give warnings about IRQ delivery problems after
resume too, not just on initial startup.


> maybe the lwlan driver should catch these and kill the urbs or
> something? 

The only obvious "looks wrong" thing from that WLAN
code is discarding the non-recoverable ENODEV status
in favor of reporting a usually-recoverable (timeout)
then maybe-recoverable (EIO) error.  But that's not
necessarily troublesome here.


> Thanks for your help, I'm not an expert at all in the usb world...

Most people aren't... :)

I'm not expert in PPC IRQ delivery, which is where the
root cause of this problem seems to live.  We all have
places where we need help!

- Dave