Re: autosuspend IRQ trouble

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel