Red Hat Bugzilla – Bug 165453
Panic after ENXIO with usb-uhci
Last modified: 2007-11-30 17:07:08 EST
While using a Multitech MT5634ZBA V92 modem, and after some ENXIO errors in the
Panics attached below.
Created attachment 117576 [details]
Created attachment 117577 [details]
Hmm. This is something that my fixes in 2.4.21-31.EL.usbserial.4 are not
likely to fix.
The ENXIO is a good clue. It happens upon disconnect, before the disconnect
method had a chance to run (either real disconnect, or just the device
giving up the ghost).
What did you actually do before getting the oops? I need to recreate this
I happen to have a Multitech, and it actually does have endpoint 0x86,
believe it or not:
T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2
P: Vendor=06e0 ProdID=f107 Rev= 1.00
S: Manufacturer=Multi-Tech Systems, Inc.
C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=400mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E: Ad=02(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms
E: Ad=84(I) Atr=03(Int.) MxPS= 63 Ivl=2ms
C:* #Ifs= 2 Cfg#= 2 Atr=a0 MxPwr=400mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E: Ad=84(I) Atr=03(Int.) MxPS= 32 Ivl=128ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I was wrong about ENXIO, by the way. The printout is misleading.
It is trying to tell us that a URB was submitted for an endpoint
which already has a URB submitted.
I think I know what is happening here. We have open and close racing,
and as a result, open attempts to submit acm->ctrlurb and acm->readurb
which were not unlinked yet. The double submission of a bulk URB is
checked by usb-uhci and is refused with the "ENXIO" message. The double
submission of the control-interrupt URB "succeeds" quietly, and corrupts
something. Double termination results in oops (with urb->dev == NULL).
Unfortunately, lock_kernel is not enough to have opens and closes separated,
because some of operations the close path does are blocking. I expect we'll
need a semaphore here somewhere.
Created attachment 117636 [details]
Candidate #1 - backport from 2.6
As it happens, Oliver already implemented the semaphore in 2.6.
Great minds think alike. Also, RHEL 4 is not affected.
I am using same code conventions for similarity.
I'm de-needinfoing this bug, but I still need a precise scenario for surety.
The fix is only based on analysis of oops captures.
From what I know the current usage is "normal" usage as a fax server, using
Hylafax. I'll see whether I can get something more precise.
When a fax can't be sent, the send is retried at a later time. Every now and
then, the retry will trigger the panic. When the panic occurs, the lock file
from Hylafax usually contains "LOCKWAIT".
Would you be able to provide a test kernel for testing purposes?
Plese find the kernel to test in ftp://people.redhat.com/zaitcev/165453/
Let me know how it went, and assuming success I'll post for acks.
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.2.EL).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.