2.4.19-pre7-ac2 USBnet with iPaq freezes host

2.4.19-pre7-ac2 USBnet with iPaq freezes host

Post by Xavier Beste » Fri, 31 May 2002 07:40:06



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>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.4.19-pre7-ac2 USBnet with iPaq freezes host

Post by Xavier Beste » Fri, 31 May 2002 07:50:04


Le jeu 30/05/2002 00:29, Xavier Bestel a crit :

Quote:> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Process hangs in 2.4.19, RH7.latest, and 2.4.20-pre7-ac2

I (and other people) have seen process hangs on stock 2.4.19, 2.4.20-pre7-ac2,
and (iirc) the latest RH 7.x kernel.  Any process that does the moral
equivalent of ps hangs.  The machine quickly becomes unusable, and needs to
be crashed.

It's been seen most often under heavy UML load.  I've seen it most often
doing UML development inside UML (stock 2.4.19).  It's been seen on
2.4.20-pre7-ac2 on a UML server.  However, I have had it happen with no
UMLs in sight.

We finally got sysrq information on this.  The hung processes all look like
this:
        Proc;  ps
        >>EIP; e352bef4 <_end+2307b320/386c042c>   <=====
        Trace; c032a955 <rwsem_down_read_failed+195/1c0>
        Trace; c016e3c0 <.text.lock.array+73/123>
        Trace; c016b340 <proc_info_read+50/110>
        Trace; c0148736 <sys_read+96/190>
        Trace; c0147fb3 <sys_open+53/b0>
        Trace; c01092cb <system_call+33/38>

The lock in question is the mmap_sem being acquired in proc_pid_stat.  There
should be a sleeping process which is holding the semaphore, but I haven't
spotted it among the multitudes that were running at the time.

The full ksymoops-ed sysrq-t output is available at
        http://www.stearns.org/slartibartfast/sym_stacks

I'm not including it here because it's too large.

There should be one process which started this by grabbing a mm_sem and
sleeping forever and I would think its stack would be different from all
the others.  There are a few processes whose deepest IP are unique:

Proc;  grep
Trace; c0118120 <do_page_fault+0/438>

Proc;  killall
Trace; c0130b72 <__vma_link+62/c0>
Trace; c032a955 <rwsem_down_read_failed+195/1c0>
Trace; c016e3c0 <.text.lock.array+73/123>
Trace; c016b340 <proc_info_read+50/110>

Proc;  init
Trace; c013f5e3 <__get_free_pages+13/30>

None of these look like to culprits.  init is probably innocent, the grep
was processing the output of a hung ps, so it was too late, and the killall
is itself hung.

I'd appreciate any clues about what's going on here.  If anyone needs more
info than what's in the sysrq output at the URL above, contact me or Bill
Stearns (wstearns at pobox dot com).

                                Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Dell WS designer wants to know...

3. Fix swsusp in 2.4.19-pre7-ac2 (fwd)

4. Disksuite

5. CONFIG_RAMFS in 2.4.19-pre7-ac2 ???

6. Trouble with Star Office install

7. kernel BUG in "page_alloc.c" with 2.4.19-pre7-ac2

8. FreeBSD 2.2.1, PAO 970331, and New Media Toast'n'Jam (SCSI portion): possible?

9. 2.4.19-pre7-ac2: Promise Ultra100TX2 broken

10. zisofs data corruption in 2.4.19-pre7-ac2

11. 2.4.19-pre7-ac2 ACPI compile failure

12. RAMFS broken in 2.4.19-pre7(-ac2)?

13. Memory leak in 2.4.19-pre7(-ac2)?\?