Re: autosuspend IRQ trouble

Hi,

On Mon, Jan 29, 2007 at 10:41:58AM -0500, Alan Stern wrote:
> On Sun, 28 Jan 2007, Dominik Brodowski wrote:
> 
> > > 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.
> 
> Loading a driver that uses the IRQ should re-enable it.

Ah, okay, need to remember that. Thanks.

> > > 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...
> 
> What exactly do you mean?

Allright, done some more debugging:
- using my patch with your fix, devices which are already plugged in when
  the STS_FLR exception occurs continue to work
- however, new devices which are plugged in, or devices which are removed,
  (unless the hub driver is awakened by other means) do not get noticed
- the STS_FLR exception is easily reproducible for me:
  - plug in USB HD
  - rmmod usb_storage
  - wait between one and seven seconds

> Can you provide a dmesg log with CONFIG_USB_DEBUG turned on?

http://userweb.kernel.org/~brodo/dmesg-2.6.19.2 - 2.6.19.2 which really
	seems to work fine (even when doing suspend to RAM and suspend
	to disk)
http://userweb.kernel.org/~brodo/dmesg-2.6.20-rc6 - the first part with
	all the intialization, and the first STS_FLR exception occuring
http://userweb.kernel.org/~brodo/dmesg-2.6.20-rc6-part2 - second part where
	the USB devices are partly in use, partly suspending is forced,
	and STS_FLR exceptions occur

> > 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...
> 
> Are you entirely certain that 2.6.19 works perfectly?  It does a lot less 
> autosuspending than 2.6.20, true...  But if you force a suspend in 2.6.19 
> do you then see the same sort of IRQ trouble?

How do I force a suspend? Is suspend to RAM / suspend to disk enough to
force it, or from what you can else see in the dmesg?

Hope this helps,
	Dominik

-------------------------------------------------------------------------
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