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