Hi, Sorry for not getting back to you earlier -- many things kept me distracted:
On Tue, Dec 12, 2006 at 04:08:39PM -0500, Alan Stern wrote: > 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. Unfortunately, the IRQ line is and stays disabled, and I don't know how I could re-enable it. > 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. I did that (see below), but then the IRQ subsystem continued to be "dead" -- it seemed to me that the USB hub is in a completely broken state when this codepath is entered... To further complicate matters, I now also see IRQ10 being disabled whenever I switch from the console (i810) to a terminal -- but that bug was introduced _later_ than the autosuspend bug. And, 2.6.19 works perfectly fine with regard to both issues... Dominik diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 025d333..d10cf42 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -569,6 +569,7 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd) struct ehci_hcd *ehci = hcd_to_ehci (hcd); u32 status; int bh; + u32 intr_enable; spin_lock (&ehci->lock); @@ -580,6 +581,17 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd) goto dead; } + intr_enable = readl(&ehci->regs->intr_enable); + + if (unlikely(intr_enable != INTR_MASK)) { + ehci_info (ehci, "STS_FLR - clearing. status: 0x%x intr 0x%x (0x%x\n", status, intr_enable, INTR_MASK); + writel(INTR_MASK, &ehci->regs->intr_enable); + if (!(status & INTR_MASK)) { + spin_unlock(&ehci->lock); + return IRQ_HANDLED; + } + } + status &= INTR_MASK; if (!status) { /* irq sharing? */ spin_unlock(&ehci->lock); ------------------------------------------------------------------------- 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
