I've thought that OHCI could detect this "IRQs are broken" problem earlier. I suspect UHCI could use the same kind of fix that came to mind: as the HCD starts, enable an IRQ for SOF, and wait a couple milliseconds to make sure it had a chance to arrive. If it came -- continue. Else, report IRQs not working (because of ACPI or whatever) and refuse to initialize that controller.
I've thought of doing something similar, but I decided against implementing it. Mostly because it would slow down the initialization of the controller and it will be obvious that something is broken when a device is plugged in later.
Right, but "deadlock" is a rather unfriendly kind of obvious. Which is why a better fix was on my mind...
Thinking about it now, I guess a clearer error message, for a problem as frequest as this, would be a good thing.
I'd expect that Herbert was getting the "Unlink after no-IRQ? ..." message from hcd_unlink_urb() ... I added that a while back, and I like to think it's somewhat reduced the number of failure reports we get which we'd just need to blame on IRQ setup problems. (I sure don't remember seeing any such reports recently, which seems like a significant change.)
Getting such a message before a deadlock is way better than getting none at all. But not deadlocking would be even better ... ;)
- Dave
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
