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
