On 7/2/06, David Brownell <[EMAIL PROTECTED]> wrote: > 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
Yes, same time. Because 1) and 2) are being interwoven and I have the logs to prove it. > - 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; ... except that is not quite what's happening. When the hub diappears, the process of 'marking the tree disconnected' is not masked against the interrupts pouring in for the now disappeared hardware, and while this process slowly moves forward, the rest of the USB subsystem is repeatedly trying to bring the devices back up; intr_descedule and qh_schedule are being called in a [potentially tight] loop. > - when usb_disconnect() is first called, first aborting all pending > transfers to the disconnected devices (your #1, I think); This can take over a second; usually not, but it can. In the meantime, I'm getting up to an interrupt per endpoint per millisecond. > - 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. Yes. The problem is, I've moved all the budgeting and scheduling overhead up front, so the liability of not caring is potentially much greater (although the old scheduler was actually probably spending just as many cycles re-budgeting QHs destined to be stillborn). > ... 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. Good tip, thanks. > The usual way: small reviewable patches, ideally each one addressing > one issue ... and against the current kernel (2.6.17-git right now). >[...] > 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. I'll split it as much as I can (and I can somewhat). Unfortunately, the core change was 'the approach of the old scheduler was logically flawed and had to be replaced'. There was no way to avoid the replacement layer being alot of code. 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
