On Tue, 12 Dec 2006, Dominik Brodowski wrote: > > 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?[*]
I can't find anything in the driver that would set the bit. Certainly not while the controller is suspended and nothing is happening. It's possible that some other driver is setting it by mistake, but that seems pretty unlikely. However I haven't tried running any new kernels recently; I've been waiting for 2.6.20-rc1 to appear. Perhaps the same thing will show up on my machine... But if some other driver is responsible, why wouldn't it happen without the autosuspend patch? More likely the suspend triggers the hardware into doing something really funky. You could try another test: Let the IRQ be disabled, and then rmmod ehci-hcd and modprobe it back. Perhaps then rmmod usb-storage to force another suspend, perhaps not. Anyway, see what happens to intr_enable. You can always force interrupts to occur by turning the USB HD off or on. It would be possible to patch the ehci_irq() routine to have it turn off the STS_FLR bit whenever necessary. But first I would like to know what causes it to turn on at all. Maybe it really is a hardware problem. Alan Stern ------------------------------------------------------------------------- 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
