> Date: Mon, 18 Mar 2002 02:26:05 +0000
> From: Robert McQueen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [Linux-usb-users] repeated similar OHCI crashes
>
> My home LAN gateway machine keeps getting kernel panics with very
> similar errors in the same place in the OHCI driver. I use a Speedtouch
> USB ADSL adapter, with the GPL drivers from:
> http://speedtouch.sourceforge.net/
I distinctly recall that last time this came up I described the problem
as somebody screwing up the device refcounts. I think it even came
up with that same driver. That's the BUG() OHCI is reporting.
Basically, it's illegal for anyone except "khubd" to get rid of devices
in normal operations. "rmmod usb-ohci" is another thread which can
remove devices (not a normal operation), and "apmd" will too in some
cases. It's _never_ OK to do so in an interrupt context ... which is one
reason why you got a BUG() when trying to do that illegal thing.
Which kernel version were you using -- recent? Whose OHCI
implementation? (I've never quite trusted OPTI.) Not that I have
any reason to suspect OHCI in this case ... EVERY (**!!**) time
I've seen these oopses, the problem has been in other kernel
code that's screwed up the device refcounting
Looking at your first crash:
> usbdevfs: USBDEVFS_BULK failed dev 2 ep 0x7 len 1696 ret -110
> usbdevfs: USBDEVFS_BULK failed dev 2 ep 0x7 len 106 ret -110
I could believe bugs in "usbfs", particularly matched with other
failure modes, though for straight bulk I/O I wouldn't start suspecting
that at first. Interesting that the second crash started in the same way.
> hub.c: already running port 2 disabled by hub (EMI?), re-enabling...
> usb.c: USB disconnect on device 2
And it's curious that you were getting this failure mode (both times).
Do you know why your ADSL modem fails then disconnects?
> usbdevfs: process 253 (pppoa3) did not claim interface 1 before use
Well, there's one bug in the user mode driver right there. Leads
me to believe others may exist, though it's not supposed to be
possible to crash things that way. (And while that's a minor bug,
where there's one bug others are often lurking... :)
Interesting that in your second crash, another process ("modem_run")
was trying to access a different interface on the same device. Tight
coordination between two processes isn't as easy as doing it between
two threads, so I always suspect code using processes that way...
Hmm, I just thought of this ... perhaps this is a design bug in usbfs,
in that it shouldn't do implicit claiming. Disconnect processing will
get rid of interface claims, but if usermode doesn't know the device
is going away (and usbfs doesn't remember it's shutting down),
interfaces could get automagically re-claimed ... AFTER the kernel
thinks the driver has already shut down! I'm not sure that's something
usermode drivers could even defend against.
> usbdevfs: USBDEVFS_BULK failed dev 2 ep 0x7 len 106 ret -110
> usb-ohci.c: bus 00:0d.0 devnum 2 deletion in interrupt
> kernel BUG at usb-ohci.c:898!
This pair is odd. Perhaps there are some device disconnect races
in the usbfs code ... since device 2 is getting disconnected (or had
it finished?) nobody should have been submitting any more URBs,
it shouldn't have been possible.
I can very easily imagine buggy disconnect() code breaking device
refcounting guarantees. In fact I think I remember finding and fixing
more than a few of that kind of bug ... :) For example, I suspect if the
disconnect() routine returned with URBs still pending, you'd see this
kind of crash (and likely other kinds later, if you missed this one).
OR if, as I just imagined above, if usbfs let processes reconnect
and issue new requests after khubd invoked disconnect()...
>From the second crash log:
> Received interrupts, len = 0
> Received interrupts, len = 0
> Received interrupts, len = 0
Where is that "Received interrupts, len = 0" message coming from?
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
