On Thu, May 25, 2000 at 03:36:26PM +0000, Georg Acher wrote:
> The hub seems to have a halted/stalled interrupt endpoint, since this
> message appears every 128 frames (hub polling interval). Now the question
> is: Does this start with certain messages sent to the hub? I have a hub
>(with an Atmel chip) that doesn't like to be asked for string descriptors.
> After 'lsusb' (which seems to read string index 0), the hub is also
dead...
It does seem to increment by 128. The output of lsusb without a device
connected is attached to this message. Trying lsusb while the hub is
connected
(errors scrolling by), the kernel panics:
Unable to handle kernel paging request at virtual address 30247c8b
printing eip:
c495321b
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c495321b>]
EFLAGS: 00010206
eax: 30247c8b ebx: 0000000 ecx: 00000000 edx: 20000100
esi: 00000000 edi: 30247c8b ebp: c3f80460 esp: c1fa3e80
ds: 0018 es: 0018 ss: 0018
Process lsusb (pid: 890 stackpage=c1fa3000)
Stack: 00000000 00000000 c0120f20 c3f80460 00000000 c0120f20 c4953296
30247c8b
20000100 00000000 c3f80460 c1fa3fb0 c013f3c8 00000008 00000000
c2e60c60
c3f80460 e6323431 30363833 c4003135 c0120f20 20000100 00000000
c3f80460
Call Trace: [<c0120f20>] [<c0120f20>] [<c4953296>] [<c013f3c8>] [<c0120f20>]
[<c013f3c8>] [<c4953296>] [<c013f3c8>] [<c013f3c8>] [<c495335b>]
[<c013f3c8>] [<c013f10f>] [<c013f3c8>] [<c013f511>] [<c013f3c8>]
[<c010b340>]
Code: 8b 07 50 68 32 77 95 c4 8d 5c 24 18 53 e8 77 9c 8b fb 83 c4
Segmentation fault
>From my System.map, the calls in the trace seem to be:
[<c0120f20>] unlock_kiovec (c0120f20)
[<c013f3c8>] filldir (c013f3c8)
[<c013f511>] sys_getdents (c013f4a4)
[<c010b340>] system_call (c010b30c)
If someone can tell me how to trace back c4953296 and c495335b I'll pass
those
along as well.
Trying to do anything with USB will lock the machine solid. Rebooting the
machine
will work, although "rmmod" segfaults as well (while unloading the usb
modules
by the looks of it).
> Can you try to enable the output for control/setup messages? For usb-uhci
(the
> file I know best...), the place to enable it is in
uhci_submit_control_urb().
> Currently it is disabled with '#if 0'.
Done. Now usb-uhci-debug.h outputs the following magic:
*snip*
TD @ c2eac7e0/02EAC7E0, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD Link Terminate
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
TD @ c2eac960/02EAC960, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac820/02EAC820, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac9e0/02EAC9E0, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac960/02EAC960, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac8e0/02EAC8E0, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac820/02EAC820, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac9e0/02EAC9E0, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD @ c2eac960/02EAC960, MaxLen=07 DT0 EP=0 Dev=2 PID=(SETUP)
buf=02784bc0
Len=00 e3 SPD Active
TD Link Terminate
usb.c: hub driver claimed interface c27844c0
usb-uhci.c: interrupt, status 3, frame #576
hub.c: nonzero status in irq -32
usb-uhci.c: interrupt, status 3, frame #704
hub.c: nonzero status in irq -32
usb-uhci.c: interrupt, status 3, frame #832
hub.c: nonzero status in irq -32
usb-uhci.c: interrupt, status 3, frame #960
hub.c: nonzero status in irq -32
*loop until disconnect*
I'll entertain any ideas.... :)
- Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
