Repeatable lockup on SMP w/usbprocfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
I've enabled spinlock debugging, and generated a nice oops... The USB system is definately doing something wrong somewhere.
Tony
Signature · 3 lines
Don't click on this sig - a cyberwoozle will eat your underwear. [email protected] http://www.nothing-on.tv
ksymoops 2.3.7 on i686 2.4.2-ac26. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-ac26/ (default)
-m /boot/System.map-2.4.2-ac26 (default)
Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options.
eip: d28eb1b5
kernel BUG at /usr/src/linux/include/asm/spinlock.h:90!
invalid operand: 0000 CPU: 1 EIP: 0010:[<d28eb1dc>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 00000038 ebx: cff44710 ecx: c0264ba0 edx: 00004e26
esi: cda794bc edi: cff44680 ebp: ffffffea esp: cd28ded8
ds: 0018 es: 0018 ss: 0018
Process mgmt (pid: 408, stackpage=cd28d000)
Stack: d28edae0 0000005a cda793c8 cda794a0 cda793a0 00000286 cda794c8 cff44710
00000292 cff44680 d28d90e6 cda794bc d28deb1f cda794bc cda793a0 bffffc70
<4>fffffdfd cfb69940 00000002 00000000 00000000 00008103 00000000 00000000
Call Trace: [<d28edae0>] [<d28d90e6>] [<d28deb1f>] [<d28df627>] [<c014d588>] [<c014d588>] [<c010756b>]
Code: 0f 0b 83 c4 08 f0 fe 0e 88 ee 27 00 00 8b 46 20 83 f8 8dQuoted 1 line
Quoted 1 line
EIP;
d28eb1dc<[uhci]uhci_submit_urb+134/3fc> <=====
Trace; d28edae0 <[uhci].rodata.start+20/110c>
Trace; d28d90e6 <[usbcore]usb_submit_urb+1e/30>
Trace; d28deb1f <[usbcore]proc_submiturb+56f/64c>
Trace; d28df627 <[usbcore]usbdev_ioctl+1ef/298>
Trace; c014d588 <file_ioctl+148/15c>
Trace; c014d588 <file_ioctl+148/15c>
Trace; c010756b <system_call+33/38>
Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc>
00000000 <_EIP>:
Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <=====
0: 0f 0b ud2a <=====
Code; d28eb1de <[uhci]uhci_submit_urb+136/3fc>
2: 83 c4 08 add $0x8,%esp
Code; d28eb1e1 <[uhci]uhci_submit_urb+139/3fc>
5: f0 fe 0e lock decb (%esi)
Code; d28eb1e4 <[uhci]uhci_submit_urb+13c/3fc>
8: 88 ee mov %ch,%dh
Code; d28eb1e6 <[uhci]uhci_submit_urb+13e/3fc>
a: 27 daa
Code; d28eb1e7 <[uhci]uhci_submit_urb+13f/3fc>
b: 00 00 add %al,(%eax)
Code; d28eb1e9 <[uhci]uhci_submit_urb+141/3fc>
d: 8b 46 20 mov 0x20(%esi),%eax
Code; d28eb1ec <[uhci]uhci_submit_urb+144/3fc>
10: 83 f8 8d cmp $0xffffff8d,%eax
1 warning issued. Results may not be reliable.
Quoted 7 lines · Tony Hoyle
If an application calls the
USBDEVFS_SUBMITURBioctl to submit a read, when the async completion routine is called, the kernel goes into a hard deadlock (no response to ping, etc.). I've narrowed it down to theasync_completedroutine inusb.c. That's the only place where spinlocks are used. I'm not familiar enough with them to see what the error is, though.
It is async_completed in devio.c btw.
I have looked at this too, but I am not sure whether this happens when the completion is called or when the program does a USBDEVFS_REAPURB(NDELAY).
I have looked at the code, but I do not see anything obviously wrong.
One thing I considered weird is the "wake_up(&ps->wait);" in async_completed(). This will wake up the program that has submitted the urb, whether is expects to be woken or not. I am not sure what the consequences of this are, but it seems harmless enough.
Quoted 3 lines
The system runs fine until the packet is returned, then it just locks solid (On the alcatel USB modem I used for testing it will not respond until it gets sync, which may be several seconds).
I have also noticed this only with the Alcatel SpeedTouch USB driver. I am not aware of any other driver that uses this although I am writing one that will be using this. It is very possible the program does something wrong (For example the code mixes the async and the sync versions of the urb ioctl's...), but even then it is not supposed to be able to lock up the whole machine.
Quoted 2 lines
Others have found that just compiling SMP into the kernel is enough to break it, you don't actually need two processors.
Probably because when you turn SMP off, spinlocks are disabled so deadlocks are avoided.
J.
Quoted 27 lines · johan verrept
Quoted 7 lines · Tony Hoyle
If an application calls the
USBDEVFS_SUBMITURBioctl to submit a read, when the async completion routine is called, the kernel goes into a hard deadlock (no response to ping, etc.). I've narrowed it down to theasync_completedroutine inusb.c. That's the only place where spinlocks are used. I'm not familiar enough with them to see what the error is, though.It is
async_completedindevio.cbtw.
I have looked at this too, but I am not sure whether this happens when the completion is called or when the program does aUSBDEVFS_REAPURB(NDELAY).
I have looked at the code, but I do not see anything obviously wrong.One thing I considered weird is the "
wake_up(&ps->wait);" inasync_completed(). This will wake up the program that has submitted the urb, whether is expects to be woken or not. I am not sure what the consequences of this are, but it seems harmless enough.Quoted 3 lines
The system runs fine until the packet is returned, then it just locks solid (On the alcatel USB modem I used for testing it will not respond until it gets sync, which may be several seconds).
I have also noticed this only with the Alcatel SpeedTouch USB driver. I am not aware of any other driver that uses this although I am writing one that will be using this. It is very possible the program does something wrong (For example the code mixes the async and the sync versions of the urb ioctl's...), but even then it is not supposed to be able to lock up the whole machine.
Quoted 5 lines
Quoted 2 lines
Others have found that just compiling SMP into the kernel is enough to break it, you don't actually need two processors.
Probably because when you turn SMP off, spinlocks are disabled so deadlocks are avoided.
I have the similar problem (also with Alcatel modem).. Besides everything else I, sometimes, get an oops in process 0 (swapper) - looks like some memory corruption going on. I really hate it when the control app is binary only. There are some obvious bugs in it (try running 'mgmt creset') and alcatel supplied it as an object file (which might/is breaking glibc compatibility) instead of a fully linked binary.
Vladimir Dergachev
Quoted 7 lines
J.-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/