Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs

Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs

[johan verrept]

Tony Hoyle wrote:
> 
> If an application calls the USBDEVFS_SUBMITURB ioctl 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 the
> async_completed routine in usb.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.

> 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.

> 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.

Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs

[volodya]

On Thu, 29 Mar 2001, johan verrept wrote:

> Tony Hoyle wrote:
> > 
> > If an application calls the USBDEVFS_SUBMITURB ioctl 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 the
> > async_completed routine in usb.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.
> 
> > 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.
> 
> > 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


> 	J.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Repeatable lockup on SMP w/usbprocfs

[Tony Hoyle]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

I've enabled spinlock debugging, and generated a nice oops...  The USB 
system is definately doing something wrong somewhere.

Tony

-- 
Don't click on this sig - a cyberwoozle will eat your underwear.

tmh@magenta-netlogic.com        http://www.nothing-on.tv

[-- Attachment #2: oops-decoded.txt --]
[-- Type: text/plain, Size: 2735 bytes --]

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 8d

>>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.