Strangely, I didn't see this on the list, looked poorly? Anyway,
here's the deal:
kernel BUG at sched.c:999!
EIP is at schedule [kernel] 0x2aa (2.4.20-13.9)
eax: 00000001 ebx: c3ad8c74 ecx: c0349d64 edx: c0349d5c
esi: c0348000 edi: c3ad8c7c ebp: c0349d54 esp: c0349d44
ds: 0068 es: 0068 ss: 0068
Process swapper (pid: 0, stackpage=c0349000)
Stack: 3201a8c0 c3ad8c74 c0348000 c3ad8c7c c0349d5c c01081ff 00000001 c0348000
c3ad8c7c c3ad8c7c c3ad8c1c c3ad8c74 c3ad8c00 ffffffea c0108354 c3ad8c74
c3ad8c00 ffffffed f88f69bf c3ad8c1c f88f6b5b 00000000 f7320000 f73d7000
Call Trace: [<c01081ff>] __down [kernel] 0x5f (0xc0349d58))
[<c0108354>] __down_failed [kernel] 0x8 (0xc0349d7c))
[<f88f69bf>] .text.lock.usbserial [usbserial] 0x2d (0xc0349d8c))
[<f88f6b5b>] .rodata.str1.1 [usbserial] 0xed (0xc0349d94))
[<c0182aed>] tty_default_put_char [kernel] 0x2d (0xc0349db0))
[<c0183718>] echo_char [kernel] 0x48 (0xc0349dc8))
[<c0184f79>] n_tty_receive_char [kernel] 0x159 (0xc0349ddc))
[<c0183e37>] n_tty_receive_buf [kernel] 0x237 (0xc0349e04))
[<c01827ae>] flush_to_ldisc [kernel] 0xbe (0xc0349eac))
[<f88fb9a5>] visor_read_bulk_callback [visor] 0x125 (0xc0349ec8))
[<f88fd30a>] .rodata.str1.1 [visor] 0xb9 (0xc0349ed0))
[<f88433b2>] sohci_return_urb [usb-ohci] 0x52 (0xc0349ef4))
[<f88456ae>] dl_done_list [usb-ohci] 0xce (0xc0349f08))
[<f88463bb>] hc_interrupt [usb-ohci] 0x12b (0xc0349f2c))
[<c010a8c5>] handle_IRQ_event [kernel] 0x45 (0xc0349f48))
[<c010aa55>] do_IRQ [kernel] 0x75 (0xc0349f68))
[<c01155b0>] apm_cpu_idle [kernel] 0x0 (0xc0349f78))
[<c0106ec3>] default_idle [kernel] 0x23 (0xc0349fb4))
[<c0106f35>] cpu_idle [kernel] 0x35 (0xc0349fd4))
It looks pretty clear.
1. The usbserial sets tty->low_latency by default.
Thus, tty_flip_buffer_push falls through to flush_to_ldisc.
2. Likely, he PDA continuously sends crap, so when app opens a port (kudzu?),
a cooked port gets connected to PDA; then the line discipline echoes.
3. The usbserial assumes that its ->serial_write method is only called
from actual writes from a process, and so downs a semaphore.
In this case, line discipline echo routine writes and not a process.
Removing any single condition will fix the problem, but which one?
Killing kudzu from a boot sequence is an option, of course...
But would like a more robust solution. The best would be to
redo locking in the usbserial and use spinlocks as appropriate.
This seems too involved, however.
Apparently, it wasn't a problem in 2.4.18. We shipped a 2.4.20
based errata and it started complaints. I think when we moved semaphores
from usbserial subcomponents into usbserial.c, a semaphore in
write method was added, even though it was not present in
component drivers in 2.4.18. Greg, why was it added? A real
oops, or just for any case?
-- Pete
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
