On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote: > 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.
Not "the same time" at all. There can be big gaps between - physical disconnect, at which point pending transfers to child devices all start to error out (your #2); - when khubd notices the disconnect as such, and marks the tree of disconnected devices as gone, so new requests won't be queued; - when usb_disconnect() is first called, first aborting all pending transfers to the disconnected devices (your #1, I think); - when the last disconnected device finishes usb_disconnect(); So if you imagine a lot of active device and slow processing, you could imagine your #2 going on for many seconds. > 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 ... yeah, irq handlers are classic Bad Places to put logging, but it's not usually an issue. Should it becomeone, printk_ratelimit() is usually going to be an approved solution. > Also, David: I have an initial new scheduler patch ready to go. Any > guidelines on how to submit? The usual way: small reviewable patches, ideally each one addressing one issue ... and against the current kernel (2.6.17-git right now). > 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. Well, "large" patches tend not to get such vetting purely because they are large. Individual reviewable patches get such attention ... the obvious fixes tend to go through first. - Dave 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
