Re: autosuspend IRQ trouble

On Mon, 29 Jan 2007, Dominik Brodowski wrote:

> 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

This means that the port-change events don't generate interrupt requests.

Try running this test again, with CONFIG_USB_DEBUG turned on.  After 
plugging in a new device, make a copy of

	/sys/class/usb_host/usb_host1/registers

and post it.  Ditto for unplugging an existing device.

> - the STS_FLR exception is easily reproducible for me:
>   - plug in USB HD
>   - rmmod usb_storage
>   - wait between one and seven seconds

Yep, it seems to happen every time the root hub is suspended.  Does it 
happen also if you simply unplug the USB HD?


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

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.

Alan Stern


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