Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs
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(>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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - 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/
Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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/
Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs
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(>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. - 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/
Re: Repeatable lockup on SMP w/usbprocfs
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. [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: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0038 ebx: cff44710 ecx: c0264ba0 edx: 4e26 esi: cda794bc edi: cff44680 ebp: ffea esp: cd28ded8 ds: 0018es: 0018 ss: 0018 Process mgmt (pid: 408, stackpage=cd28d000) Stack: d28edae0 005a cda793c8 cda794a0 cda793a0 0286 cda794c8 cff44710 0292 cff44680 d28d90e6 cda794bc d28deb1f cda794bc cda793a0 bc70 <4>fdfd cfb69940 0002 8103 Call Trace: [] [] [] [] [] [] [] 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 Trace; c014d588 Trace; c010756b Code; d28eb1dc <[uhci]uhci_submit_urb+134/3fc> <_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: 27daa 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 mov0x20(%esi),%eax Code; d28eb1ec <[uhci]uhci_submit_urb+144/3fc> 10: 83 f8 8d cmp$0xff8d,%eax 1 warning issued. Results may not be reliable.
Repeatable lockup on SMP w/usbprocfs
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. 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). Others have found that just compiling SMP into the kernel is enough to break it, you don't actually need two processors. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv - 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/
Repeatable lockup on SMP w/usbprocfs
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. 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). Others have found that just compiling SMP into the kernel is enough to break it, you don't actually need two processors. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv - 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/
Re: Repeatable lockup on SMP w/usbprocfs
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. [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: CPU:1 EIP:0010:[d28eb1dc] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0038 ebx: cff44710 ecx: c0264ba0 edx: 4e26 esi: cda794bc edi: cff44680 ebp: ffea esp: cd28ded8 ds: 0018es: 0018 ss: 0018 Process mgmt (pid: 408, stackpage=cd28d000) Stack: d28edae0 005a cda793c8 cda794a0 cda793a0 0286 cda794c8 cff44710 0292 cff44680 d28d90e6 cda794bc d28deb1f cda794bc cda793a0 bc70 4fdfd cfb69940 0002 8103 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 _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: 27daa 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 mov0x20(%esi),%eax Code; d28eb1ec [uhci]uhci_submit_urb+144/3fc 10: 83 f8 8d cmp$0xff8d,%eax 1 warning issued. Results may not be reliable.
Re: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs
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. - 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/
