I'm putting the finishing touches on the new EHCI scheduler and noticed an interesting 'problem' in shutdown. In practice it usually doesn't work out to being a bug, but it appears to be unintentional and potentially problematic on slow CPUs when a hub with lots of devices is detached.
In summary: Disconnecting a hub/device causes two things to happen at the same time: 1) usb_disconnect is called on the root device. 2) each active transfer descriptor throws an interrupt/error each time it comes up in the periodic schedule. Usually the CPU is fast enough to win the race as the interrupts pour in and get everything shut down before the magic number of ten interrupt retries cause the kernel to kill off the host controller and the interrupt its on. However, any syslogging in the irq handler slows things down enough that the interrupts usually win the race and the only way to get usb back is to reboot (Is there a way to force-reenable an interrupt line?). If this doesn't sound familiar, I'll paste the syslogs. Also, David: I have an initial new scheduler patch ready to go. Any guidelines on how to submit? I have to admit, it's a monster; there are only a few tiny pieces that could be seperated out into smaller patches as it's a fairly complete rewrite of ehci-shed.c. Obviously, this is a RFC/please test submission, no patch that large should be considered for production without thorough vetting. Monty Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
