2.4.19-pre7-ac2 USBnet with iPaq freezes host

2.4.19-pre7-ac2 USBnet with iPaq freezes host

[Xavier Bestel]

I've compiled-in (i.e. not as a module) usbnet to talk to my ipaq
through usb0. It works well, mostly, except that sometimes it lockups my
desktop completely (not the pda).

I got bored today and copied the console message on a shit a paper and
retyped it through ksymoops:

wait_on_irq, CPU0
irq: 1 [ 0 1 ]
bh: 0 [ 0 0 ]
stack dumps:
cpu 1: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
cpu 0: c19d3f54 c02cb45d 00000000 00000000 00000000 c0109e9d c02cb472 c0349e64
       d5dca000 00000001 c01b854d c0349e64 c19d3fa4 c19d3fe0 c19d2000 d5dca168
       c0120400 d5dca000 c19d2654 ffffffff d5dca130 c0349e64 c01287f7 c0343900
call trace: [<c0109e9d3>] [<c01b854d>] [<c0120400>] [<c01287f7>] [<c0106fd4>]
Warning (Oops_read): Code line not seen, dumping what data is available


Trace; 0000000c0109e9d3 <END_OF_CODE+b106241f4/????>
Trace; c01b854d <flush_to_ldisc+d5/11c>
Trace; c0120400 <__run_task_queue+60/6c>
Trace; c01287f7 <context_thread+137/1d0>
Trace; c0106fd4 <kernel_thread+28/38>

Re: 2.4.19-pre7-ac2 USBnet with iPaq freezes host

[Xavier Bestel]

Le jeu 30/05/2002 à 00:29, Xavier Bestel a écrit :
> I've compiled-in (i.e. not as a module) usbnet to talk to my ipaq
> through usb0. It works well, mostly, except that sometimes it lockups my
> desktop completely (not the pda).
> 
> I got bored today and copied the console message on a shit a paper and
> retyped it through ksymoops:
> 
> wait_on_irq, CPU0
> irq: 1 [ 0 1 ]
> bh: 0 [ 0 0 ]
> stack dumps:
> cpu 1: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> cpu 0: c19d3f54 c02cb45d 00000000 00000000 00000000 c0109e9d c02cb472 c0349e64
>        d5dca000 00000001 c01b854d c0349e64 c19d3fa4 c19d3fe0 c19d2000 d5dca168
>        c0120400 d5dca000 c19d2654 ffffffff d5dca130 c0349e64 c01287f7 c0343900
> call trace: [<c0109e9d3>] [<c01b854d>] [<c0120400>] [<c01287f7>] [<c0106fd4>]
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> 
> Trace; 0000000c0109e9d3 <END_OF_CODE+b106241f4/????>
> Trace; c01b854d <flush_to_ldisc+d5/11c>
> Trace; c0120400 <__run_task_queue+60/6c>
> Trace; c01287f7 <context_thread+137/1d0>
> Trace; c0106fd4 <kernel_thread+28/38>

actually there was a typo:

call trace: [<c0109e9d>] [<c01b854d>] [<c0120400>] [<c01287f7>] [<c0106fd4>]
Warning (Oops_read): Code line not seen, dumping what data is available


Trace; c0109e9d <__global_cli+bd/124>
Trace; c01b854d <flush_to_ldisc+d5/11c>
Trace; c0120400 <__run_task_queue+60/6c>
Trace; c01287f7 <context_thread+137/1d0>
Trace; c0106fd4 <kernel_thread+28/38>

And yes, the call trace for CPU1 was empty ...

	Xav