On Mon, 29 Nov 2004, Stefan Rompf wrote: > Hi, > > Am Dienstag 23 November 2004 20:46 schrieb Alan Stern: > > > My guess is that this is an interrupt-routing problem. > > My notebook is one of those nearly-all-irqs-shared systems. Ehci and all > three > uhci controllers use interrupt 11. I've added some printk()s to > kernel/irq/handle.c to see when this interrupt is generated and where it is > handled.
After reading this message, it looks like the problem is something else. > > You may be able to > > get more useful information by loading the UHCI driver with > > > > modprobe uhci-hcd debug=3 > > > > and then copying the contents of /proc/driver/uhci/0000:00:1d.0 (or > > whichever file matches the controller you plugged the Sigmatel IrDA/USB > > Bridge into), both before and after the suspend. > > Here we go. After plugging, the entry shows > > HC status > usbcmd = 00c1 Maxp64 CF RS > usbstat = 0000 > usbint = 000f > usbfrnum = (1)f08 > flbaseadd = 13e3cf08 > sof = 40 > stat1 = 0095 Enabled Connected > stat2 = 0080 > Frame List > Skeleton QH's > - skel_int128_qh > [d2a86000] link (12a86152) element (00000001) > urbp == NULL > . > . > . > Main list URBs: Empty > Remove list URBs: Empty > Complete list URBs: Empty > > After the suspend/resume cycle, I get > > HC status > usbcmd = 00c1 Maxp64 CF RS > usbstat = 0000 > usbint = 000f > usbfrnum = (1)948 > flbaseadd = 13e3c948 > sof = 40 > stat1 = 0093 ConnectChange Connected > stat2 = 0080 > Frame List > . > (no changes from here on) > > I've also tested what happens when I disconnect and reconnect the dongle now. > Both stat1 and stat2 go to 0082 (ConnectChange). After reconnecting, stat1 > changes to 0093 (ConnectChange Connected), stat2 keeps 0082 (ConnectChange). > > While the dongle is disconnected, the uhci controller in question generates > about one interrupt per second, spitting wakeup_hc/suspend_hc messages into > syslog. That's the key piece of information. It indicates that there's a problem with khubd, the kernel's hub driver daemon. The fact that those wakeup_hc/suspend_hc messages keep appearing shows that interrupts actually are working okay. 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. > When I force the controller to reinit instead of resuming by returning 0 in > suspend_allowed(), the same state transitions happen but no interrupts are > generated. > > To revive the controller, I have to unload/reload uhci-hcd.ko > > > Likewise, if you unplug > > the bridge after the resume and plug it back into another controller, copy > > the file for that controller both before and after plugging in the bridge. > > Well, it just works when no device is connected during the suspend/resume > cycle. ehci hands off, I see that uhci handles some interrupts and stat1 goes > from 0080 to 0095 (Enabled Connected) > > Hope this helps. > > Stefan Let's see what your next test shows. For the moment, bear in mind that USB support for suspend/resume is still fairly primitive. The most reliable way to do it is to rmmod all the host controller drivers before suspending and modprobe them back after resuming. Nevertheless, the problem you encountered needs to be fixed. 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
