In an attempt to get another angle on the problem I've been trying the Keyspan rev2003jan31 linux driver release in a vanilla 2.4.19 (which is the last kernel for which I've been able to get reliable Keyspans on). The driver is from :-
http://www.keyspan.com/support/linux/files/currentversion/rev2003jan31/ (I had to wget this directory there didn't seem to be a tar available). This applied to 2.4.19 fails in almost exactly the same way as 2.4.21-pre6 and 2.5.66 which is very interesting. Ie 1) It only transfers data on the first port opened (2.4.21-pre6 and 2.5.66 both do this) 2) It Oopses after about 20 seconds run time (2.4.21-pre6 does this but 2.5.66 doesn't) Since according to the changelog at http://linuxusb.bkbits.net:8080/usb-2.4/[EMAIL PROTECTED] http://linuxusb.bkbits.net:8080/usb-2.5/[EMAIL PROTECTED] 2.4.21-pre6 and 2.5.66 are based on the rev2003jan31 driver from keyspan this would seem to solidly point the finger at the Keyspan rev2003jan31 changes. Does anyone know how to get in touch with the mysterious LPM at Keyspan to ask about this? ------------------------------------------------------------ Details Apply the Keyspan rev2003jan31 firmware to a vanilla 2.4.19 kernel source tree. Attach a USA49W (haven't even tried the 49WLC yet!) with loopbacks on all 4 ports. ./cambert /dev/ttyUSB[0123] 115200 8N1 N Runs for about 20 seconds - but only the first port transfers data properly... * test running 6.06 seconds * /dev/ttyUSB0: synced to /dev/ttyUSB0 |-tx chars: 68873, baud: 113651.82 |-rx chars: 68735, baud: 113424.09 `-rx sync losses: 0, unsynced chars: 154, synced chars: 68581 * /dev/ttyUSB1: NOT synced |-tx chars: 63, baud: 103.96 |-rx chars: 0, baud: 0.00 `-rx sync losses: 0, unsynced chars: 0, synced chars: 0 * /dev/ttyUSB2: NOT synced |-tx chars: 63, baud: 103.96 |-rx chars: 0, baud: 0.00 `-rx sync losses: 0, unsynced chars: 0, synced chars: 0 * /dev/ttyUSB3: NOT synced |-tx chars: 63, baud: 103.96 |-rx chars: 0, baud: 0.00 `-rx sync losses: 0, unsynced chars: 0, synced chars: 0 Before Oopsing like this - which is pretty much identical to the 2.4.21-pre6 Oops I produced. ksymoops 2.4.5 on i686 2.4.19. Options used -V (default) -k ksyms-rev2003jan31 (specified) -l modules-rev2003jan31 (specified) -o /lib/modules/2.4.19/ (default) -m /boot/System.map-2.4.19 (default) Unable to handle kernel NULL pointer dereference at virtual address 0000002c f8948ee9 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<f8948ee9>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00000028 ebx: f614f528 ecx: 01800204 edx: 00000001 esi: f614f528 edi: f5fe2160 ebp: f7ccf660 esp: c0287ec4 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0287000) Stack: f5fe2160 f61353a0 00000003 f7ccf660 00000014 c029d3e0 f614f500 c029e0a0 f614f520 f614f500 f61353a0 00000000 f89479f4 f7ccf660 f5fe2160 00000002 f7ccf67c f7ccf660 00000000 00000000 00000696 f7ccf660 f630c6c8 f8949828 Call Trace: [<f89479f4>] [<f8949828>] [<c0110001>] [<c010998d>] [<c0109af6>] [<c0106d00>] [<c0106d00>] [<c010bc38>] [<c0106d00>] [<c0106d00>] [<c0106d23>] [<c0106d89>] [<c0105000>] [<c0105027>] Code: 8b 2c 90 8b 44 24 28 c1 e9 08 83 e1 0f d3 ed 83 e5 01 c7 44 >>EIP; f8948ee9 <[usb-uhci]process_transfer+51/2e4> <===== >>ebx; f614f528 <_end+35e77108/38538be0> >>ecx; 01800204 Before first symbol >>esi; f614f528 <_end+35e77108/38538be0> >>edi; f5fe2160 <_end+35d09d40/38538be0> >>ebp; f7ccf660 <_end+379f7240/38538be0> >>esp; c0287ec4 <init_task_union+1ec4/2000> Trace; f89479f4 <[usb-uhci]uhci_cleanup_unlink+78/158> Trace; f8949828 <[usb-uhci]uhci_interrupt+10c/12c> Trace; c0110001 <read_config_nybble+1d/40> Trace; c010998d <handle_IRQ_event+31/5c> Trace; c0109af6 <do_IRQ+6a/a8> Trace; c0106d00 <default_idle+0/28> Trace; c0106d00 <default_idle+0/28> Trace; c010bc38 <call_do_IRQ+5/d> 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; f8948ee9 <[usb-uhci]process_transfer+51/2e4> 00000000 <_EIP>: Code; f8948ee9 <[usb-uhci]process_transfer+51/2e4> <===== 0: 8b 2c 90 mov (%eax,%edx,4),%ebp <===== Code; f8948eec <[usb-uhci]process_transfer+54/2e4> 3: 8b 44 24 28 mov 0x28(%esp,1),%eax Code; f8948ef0 <[usb-uhci]process_transfer+58/2e4> 7: c1 e9 08 shr $0x8,%ecx Code; f8948ef3 <[usb-uhci]process_transfer+5b/2e4> a: 83 e1 0f and $0xf,%ecx Code; f8948ef6 <[usb-uhci]process_transfer+5e/2e4> d: d3 ed shr %cl,%ebp Code; f8948ef8 <[usb-uhci]process_transfer+60/2e4> f: 83 e5 01 and $0x1,%ebp Code; f8948efb <[usb-uhci]process_transfer+63/2e4> 12: c7 44 00 00 00 00 00 movl $0x0,0x0(%eax,%eax,1) Code; f8948f02 <[usb-uhci]process_transfer+6a/2e4> 19: 00 <0>Kernel panic: Aiee, killing interrupt handler! The above test works perfectly with a vanilla 2.4.19. A cambert binary can be found here... http://www.craig-wood.com/nick/cambert.gz -- 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
