On Fri, Mar 21, 2003 at 05:29:45PM -0800, Greg KH wrote:
> On Fri, Mar 21, 2003 at 12:51:15PM +0000, Nick Craig-Wood wrote:
> > I first noticed this problem in the 2.4.20 kernel. I checked out the
> > latest bk kernel from bk://linuxusb.bkbits.net/usb-2.4 to test if the
> > problem was still there.
> >
> > In a nutshell the problem seems to be that a panic happens if the
> > keyspan driver is receiving data when the port is closed.
>
> Yeah, a lot of people have this problem right now :(
> It should be fixed in 2.5, can you grab 2.5.65 and let me know if you
> still have the same problem there?
I tried 2.5.66 and yes it no longer Oopses on close! I tried it 100
times on USA-49W and USA-49WLC just to be sure.
Is it easy to break out a patch for this for 2.4? I'd willingly test
it for you.
> Also, sometimes switching host controller drivers seems to fix the
> problem for some people (from uhci.o to usb-uhci.o or the other way
> around), if you have a UHCI controller.
I tried moving from usb-uhci to uchi with no improvement :-(
This testing turned up another problem though...
While testing on 2.5 I tried to use multiple ports at once with
cambert. The problem is that only the first port transfers data
properly - the second and subsequent ports transfer very little data.
mostly. (I did see it once transfer an outrageously large amount like
100MB in a second but I haven't managed to reproduce this!)
Once cambert has got going it just does non-blocking reads and writes
into all the sockets it has open. Eg from strace...
read(4, 0x8053c90, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
write(4, "\366\212\201\252\341(\353\356,\17\362\n\361\207G\2Paz\201"..., 866) = -1
EAGAIN (Resource temporarily unavailable)
gettimeofday({1049240217, 642859}, {4294967236, 0}) = 0
read(3, 0x80533a4, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
write(3, "\306\36\223.RG \373\322\27r\336\240\242\v\204T\v\331\272"..., 541) = -1
EAGAIN (Resource temporarily unavailable)
read(4, 0x8053c90, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
write(4, "\366\212\201\252\341(\353\356,\17\362\n\361\207G\2Paz\201"..., 866) = -1
EAGAIN (Resource temporarily unavailable)
gettimeofday({1049240217, 643139}, {4294967236, 0}) = 0
read(3, "\275\334fn\247P\315;\252i\25\341\331\372\302\304", 1024) = 16
gettimeofday({1049240217, 643260}, {4294967236, 0}) = 0
write(3, "\306\36\223.RG \373\322\27r\336\240\242\v\204T\v\331\272"..., 541) = -1
EAGAIN (Resource temporarily unavailable)
read(4, 0x8053c90, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
write(4, "\366\212\201\252\341(\353\356,\17\362\n\361\207G\2Paz\201"..., 866) = -1
EAGAIN (Resource temporarily unavailable)
gettimeofday({1049240217, 643879}, {4294967236, 0}) = 0
read(3, 0x80533a4, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
gettimeofday({1049240217, 643988}, {4294967236, 0}) = 0
write(3, "\306\36\223.RG \373\322\27r\336\240\242\v\204T\v\331\272"..., 541) = -1
EAGAIN (Resource temporarily unavailable)
read(4, 0x8053c90, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
write(4, "\366\212\201\252\341(\353\356,\17\362\n\361\207G\2Paz\201"..., 866) = -1
EAGAIN (Resource temporarily unavailable)
gettimeofday({1049240217, 644239}, {4294967236, 0}) = 0
read(3, 0x80533a4, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
gettimeofday({1049240217, 644332}, {4294967236, 0}) = 0
write(3, "\306\36\223.RG \373\322\27r\336\240\242\v\204T\v\331\272"..., 541) = -1
EAGAIN (Resource temporarily unavailable)
read(4, 0x8053c90, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
write(4, "\366\212\201\252\341(\353\356,\17\362\n\361\207G\2Paz\201"..., 866) = -1
EAGAIN (Resource temporarily unavailable)
gettimeofday({1049240217, 644583}, {4294967236, 0}) = 0
read(3, 0x80533a4, 1024) = -1 EAGAIN (Resource temporarily
unavailable)
gettimeofday({1049240217, 644676}, {4294967236, 0}) = 0
So nothing unusual by cambert there... However any port after the
first opened by cambert fails to write data. Each of the 4 ports work
individually.
So to replicate with cambert...
Place a loopback connectory on ports 1 and ports 2 of the Keyspan
USA-49W.
./cambert /dev/ttyUSB0 115200 8N1 N
* test running 24.63 seconds
* /dev/ttyUSB0: synced to /dev/ttyUSB0
|-tx chars: 284501, baud: 115509.95
|-rx chars: 284210, baud: 115391.80
`-rx sync losses: 0, unsynced chars: 155, synced chars: 284055
Works fine
./cambert /dev/ttyUSB1 115200 8N1 N
* test running 29.67 seconds
* /dev/ttyUSB1: synced to /dev/ttyUSB1
|-tx chars: 342609, baud: 115473.21
|-rx chars: 342243, baud: 115349.85
`-rx sync losses: 0, unsynced chars: 155, synced chars: 342088
Works fine
./cambert /dev/ttyUSB0 /dev/ttyUSB1 115200 8N1 N
* test running 15.67 seconds
* /dev/ttyUSB0: synced to /dev/ttyUSB0
|-tx chars: 181195, baud: 115631.78
|-rx chars: 180802, baud: 115380.98
`-rx sync losses: 0, unsynced chars: 155, synced chars: 180647
* /dev/ttyUSB1: NOT synced
|-tx chars: 3648, baud: 2328.02
|-rx chars: 0, baud: 0.00
`-rx sync losses: 0, unsynced chars: 0, synced chars: 0
Only ttyUSB0 transfers data properly
./cambert /dev/ttyUSB1 /dev/ttyUSB0 115200 8N1 N
* /dev/ttyUSB1: synced to /dev/ttyUSB1
|-tx chars: 69823, baud: 115792.70
|-rx chars: 69456, baud: 115184.08
`-rx sync losses: 0, unsynced chars: 155, synced chars: 69301
* /dev/ttyUSB0: NOT synced
|-tx chars: 126, baud: 208.96
|-rx chars: 0, baud: 0.00
`-rx sync losses: 0, unsynced chars: 0, synced chars: 0
Only ttyUSB1 transfers data properly - ie only the first port opened
works.
..
usb-2.4: 2.4.20-pre6 appears to have the same problem but dies with
the oops (at the end of the email) after about 20 secons run time. I
suspect this is related to the fix needed for 2.5 anyway but the oops
looked different so I thought I'd send it in.
What the cause of this I'm not sure but I'm willing to help debug!
To recap: cambert works perfectly with 2.4.19 and the USA-49W. 2.4.20
to 21-pre6 all oops on close. 2.5.66 exhibits not working on the
multiple ports problem and I'm pretty sure 2.4.21-pre6 does too (in
the 20 seconds before it Oopses!)
A cambert binary can be found here...
http://www.craig-wood.com/nick/cambert.gz
------------------------------------------------------------
Different Oops caused by
./cambert /dev/ttyUSB0 /dev/ttyUSB1 115200 8N1 N
ksymoops 2.4.5 on i686 2.4.21-pre6-usb2. Options used
-V (default)
-k ksyms-pre6-2 (specified)
-l modules-pre6-2 (specified)
-o /lib/modules/2.4.21-pre6-usb2/ (default)
-m /boot/System.map-2.4.21-pre6-usb2 (default)
Unable to handle kernel NULL pointer dereference at virtual address 0000003c
f8948f8f
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<f8948f8f>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000038 ebx: f74f7428 ecx: 00000002 edx: 00000001
esi: f7512420 edi: f74f7428 ebp: f7cf4660 esp: c029bec4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c029b000)
Stack: f7512420 f74cc320 00000003 f7cf4660 00000016 c02b33e0 f74f7400 c02f40a0
f74f7420 f74f7400 f74cc320 00000000 f8947a74 f7cf4660 f7512420 00000002
f7cf467c f7cf4660 00000001 00000000 00000388 f7cf4660 00000000 f89498e8
Call Trace: [<f8947a74>] [<f89498e8>] [<c0110001>] [<c01099ed>] [<c0109b56>]
[<c0106d00>] [<c0106d00>] [<c0106d00>] [<c0106d00>] [<c0106d23>] [<c0106d89>]
[<c0105000>] [<c0105027>]
Code: 8b 34 90 8b 44 24 28 d3 ee 83 e6 01 c7 44 24 14 00 00 00 00
>>EIP; f8948f8f <[usb-uhci]process_transfer+57/2d8> <=====
>>ebx; f74f7428 <_end+37206028/3851fc00>
>>esi; f7512420 <_end+37221020/3851fc00>
>>edi; f74f7428 <_end+37206028/3851fc00>
>>ebp; f7cf4660 <_end+37a03260/3851fc00>
>>esp; c029bec4 <init_task_union+1ec4/2000>
Trace; f8947a74 <[usb-uhci]uhci_cleanup_unlink+78/168>
Trace; f89498e8 <[usb-uhci]uhci_interrupt+10c/12c>
Trace; c0110001 <set_mtrr_prepare_save+11/64>
Trace; c01099ed <handle_IRQ_event+31/5c>
Trace; c0109b56 <do_IRQ+6a/a8>
Trace; c0106d00 <default_idle+0/28>
Trace; c0106d00 <default_idle+0/28>
Trace; c0106d00 <default_idle+0/28>
Trace; c0106d00 <default_idle+0/28>
Trace; c0106d23 <default_idle+23/28>
Trace; c0106d89 <cpu_idle+41/54>
Trace; c0105000 <_stext+0/0>
Trace; c0105027 <rest_init+27/28>
Code; f8948f8f <[usb-uhci]process_transfer+57/2d8>
00000000 <_EIP>:
Code; f8948f8f <[usb-uhci]process_transfer+57/2d8> <=====
0: 8b 34 90 mov (%eax,%edx,4),%esi <=====
Code; f8948f92 <[usb-uhci]process_transfer+5a/2d8>
3: 8b 44 24 28 mov 0x28(%esp,1),%eax
Code; f8948f96 <[usb-uhci]process_transfer+5e/2d8>
7: d3 ee shr %cl,%esi
Code; f8948f98 <[usb-uhci]process_transfer+60/2d8>
9: 83 e6 01 and $0x1,%esi
Code; f8948f9b <[usb-uhci]process_transfer+63/2d8>
c: c7 44 24 14 00 00 00 movl $0x0,0x14(%esp,1)
Code; f8948fa2 <[usb-uhci]process_transfer+6a/2d8>
13: 00
<0>Kernel panic: Aiee, killing interrupt handler!
--
Nick Craig-Wood
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
