Duncan Sands wrote: > > Hi Dave, I'm still confused about how leaking memory can help.
The way you were phrasing your questions, the driver synchronized on unlink success to determine when it was safe to free urb (and maybe buffer). The error indicates synchronization failed ... so the safest assumption is that the error was not in your favor. An alternate driver structure synchronizes instead on the urbs completing. Async unlink requests would only accelerate the callback delivery ... so if an unlink fails, big deal. > The problem from the beginning was: making sure all urbs have > completed in the disconnect handler (though perhaps I didn't make > it clear that I was talking about the disconnect routine). Suppose > usb_unlink_urb fails for some urb and you decide not to free > memory (and print a message - I have nothing against that!). You > then return from the disconnect handler with an urb in flight. This is ... maybe fatal, depending on how/when the memory that the hardware may still be writing into gets recycled. Ooopses happen that way. In that other driver structure, synchronizing on urb completions after an (async) unlink failure would either (a) have succeeded, because the "failure" was like the EBUSY case, "warp crystals would explode if we unlinked any faster", or (b) failed because of some HCD problem. Success means all is fine; failure (b) would be khubd hanging. Annoying (reboot to recover, no more modprobes) but 100% safe. - Dave ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
