On Mon, 29 Nov 2004, Stefan Rompf wrote:

> Hi,
> 
> > For your next test, get the system into this resume-stuck state and press
> > Alt-SysRq-T to get a stack trace in the system log.  The entry for the
> > khubd process should be very enlightening.
> 
> 23:14:16 khubd         S C0356548     0  1866      1          1977   899 
> (L-TLB)
> 23:14:16 dcb7ff8c 00000046 dbf10ae0 c0356548 0000000a 00000001 00000006 
> 0000ffc0
> 23:14:16        93b7ab2a 0000000a dbf10ae0 0000390a 93b7b08d 0000000a 
> dcb0f17c 
> dcb7ffc0
> 23:14:16        ffffe000 dcb7e000 dcb7ffcc e0064a9d 00004000 00000000 
> dcb7e000 
> 00000000
> 23:14:16 Call Trace:
> 23:14:16  [<e0064a9d>] hub_thread+0x9d/0x130 [usbcore]
> 23:14:16  [<c0128e10>] autoremove_wake_function+0x0/0x60
> 23:14:16  [<c0102f72>] ret_from_fork+0x6/0x14
> 23:14:16  [<c0128e10>] autoremove_wake_function+0x0/0x60
> 23:14:16  [<e0064a00>] hub_thread+0x0/0x130 [usbcore]
> 23:14:16  [<c01012ad>] kernel_thread_helper+0x5/0x18
> 
> This didn't look very special to me. I should have made more clear that the 
> suspend_hc()/resume_hc() messages appear only once per interrupt.

It doesn't look special to me either.  It means that the messages from the 
uhci-hcd driver aren't reaching khubd.

At this point, your best bet is to add lots of debugging messages to
drivers/usb/core/hcd.c, in these four routines: rh_status_urb,
rh_report_status, rh_urb_enqueue, and usb_rh_urb_dequeue.  The second one,
rh_report_status, should be called 4 times per second for each USB host
controller.

If you like, you can also add a debugging message to
drivers/usb/host/uhci-hub.c in the uhci_hub_status_data routine, which is
what rh_report_status is supposed to call.  In fact, maybe it would be
best to start with debugging here, then add the other places if it turns
out that uhci_hub_status_data isn't getting called after the resume.

> Anyway I've added a dump_stack() to suspend_hc() and to resume_hc(), may be 
> this reveals more information. "hi11 uhci_hcd" is printed after the uhci 
> interrupt handler returns with IRQ_HANDLED:

No, this doesn't help since those routines are called in interrupt 
context.

Alan Stern




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to