On Tue, Dec 12, 2006 at 11:27:42AM -0500, Alan Stern wrote: > > from today confirms it, and I also ran the pre-autosuspend kernel ( its head > > is 8c03356a559ced6fa78931f498193f776d67e445 ) to re-check that it is an > > issue > > which appeared with the autosuspend patch. > > Okay, I was fooled by the lack of debugging info. And clearly the suspend > or resume routine is implicated. > > This suggests we check the value of the intr_enable register at the entry > and exit of both ehci_bus_suspend() and ehci_bus_resume() in ehci_hub.c. > You can add the appropriate printk statements easily. > > Hmmm... Perhaps the final writel() at the end of ehci_bus_resume() isn't > getting sent through. The mere act of reading it back might be enough to > change the behavior. > > On the other hand, your latest log suggests that the STS_FLR bit gets set > during the ehci_bus_suspend() routine, not the resume routine. So it will > be best to check at the beginning and end of both routines.
Unfortunately, it doesn't get set anywhere then, but outside: case A: http://userweb.kernel.org/~brodo/dmesg-autosuspend-3-sr.txt [ 26.380849] ehci_bus_resume: intro 37 [ 26.380852] ehci_hcd 0000:00:1d.7: resume root hub [ 26.400866] ehci_bus_resume: exit 37 (mask was 37) [ 26.411590] hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 26.411679] usb 1-1: usb auto-resume [ 26.437439] ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT [ 26.448389] usb 1-1: finish resume [ 26.448681] ehci_hcd 0000:00:1d.7: IRQ status 8009, intr_enable 37 ... [ 26.453427] ehci_hcd 0000:00:1d.7: IRQ status 8028, intr_enable 37 ... [ 28.900407] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [ 28.900419] ACPI: Processor [CPU0] (supports 8 throttling states) [ 17.451000] Time: acpi_pm clocksource has been installed. [ 17.545000] acpi_processor-0740 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination [ 17.546000] ehci_hcd 0000:00:1d.7: IRQ status 2008, intr_enable 3f All of a sudden, it seems... Case B: http://userweb.kernel.org/~brodo/dmesg-autosuspend-2-sr.txt [ 15.582559] ehci_hcd 0000:00:1d.7: IRQ status 4, intr_enable 37 [ 16.327713] libata version 2.00 loaded. [ 17.575888] hub 1-0:1.0: hub_suspend [ 17.575896] ehci_bus_suspend: intro 37 [ 17.576013] ehci_bus_suspend: exit 37 (mask was 37) [ 17.576620] usb usb1: usb auto-suspend ... [ 22.312792] ehci_hcd 0000:00:1d.7: IRQ status 8, intr_enable 3f For Case B, it seems to happen while the hub is suspended; while for Case A, it seems to happen while the hub is resumed. It just gets more and more strange. Broken hardware?[*] Thanks, Dominik [*] ... which otherwise seems to work fine... ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
