Re: autosuspend IRQ trouble

Hi,

On Tue, Jan 30, 2007 at 03:31:24PM -0500, Alan Stern wrote:
> > next test:
> > http://userweb.kernel.org/~brodo/pre-insert
> > => added device 2
> > http://userweb.kernel.org/~brodo/post-insert
> 
> These were all done with the controller supposedly suspended, right?

Yes.

> But 
> they all show that it is actually running!  (Which isn't too surprising 
> when you think about it, because the FLR bit can't get set unless the 
> controller is running.)

Ouch.

> > The one thing which strikes me as odd is that all these tests are ONLY
> > reproducible if there is an usb device plugged in during boot. If it wasn't
> > plugged in there during boot, I can do whatever I want, everything works
> > perfectly fine.
> 
> This combined with everything else suggests very strongly a bug in the 
> BIOS.  Have you checked for any BIOS updates?

Hmmm, not lately -- I'll check it out (but only later this week, I can't
risk breaking my notebook at the moment ;) )

> > > Turn on CONFIG_PM_SYSFS_DEPRECATED in your kernel build of 2.6.19.  After 
> > > booting and plugging in the USB HD, rmmod usb-storage.  Then do
> > > 
> > > 	echo -n 2 >/sys/bus/usb/devices/usb1/power/state
> > > 
> > > That will force the root hub to suspend.
> > 
> > Using this trick, I can get IRQ 10 being disabled.
> > 
> > So technically it's not a regression, but... ;)
> 
> There may not be anything we can do about a rogue BIOS, other than to 
> avoid suspending the controller at all.
> 
> Just to make sure, try this:  In ehci-hub.c, near the end of 
> ehci_bus_suspend(), print out the value returned by ehci_halt().  If it is 
> 0 then we will know that the controller does get suspended correctly and 
> something (the BIOS?) starts it up for no good reason.

+       ret = ehci_halt (ehci);
+       printk(KERN_INFO "ehci_halt in ehci_bus_suspend returns %d\n", ret);

Jan 30 18:05:54 [kernel] [   23.918690] ehci_halt in ehci_bus_suspend returns 0
...
Jan 30 18:05:54 [kernel] [   24.570171] cs: IO port probe 0x800-0x8ff:<6>ehci_hcd 0000:00:1d.7: STS_FLR - clearing. status: 0x2008 intr 0x3f (0x37

Well, if we notice it has been awakened by the BIOS could we call the
resume() routines as a workaround?

> The fact that suspend-to-RAM and -to-disk work okay might be explained by
> other things happening during the suspend procedure.  Not only is the USB
> controller suspended, but its interrupt mask is cleared and its upstream
> PCI link gets suspended as well.  That might be enough to prevent the BIOS
> from interfering.

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