> It could be done. It would have the undesirable effect of logically > disconnecting all the devices attached to the controller and then > reconnecting them, forcing them to go through their entire initialization > sequence over again. This could cause an endless loop, if some device > sends an overlong packet during its startup procedure (it's been known to > happen). > A better compromise would be to change the way the driver works so that > requests that are "stuck" can still be cancelled. That way processes > would be able to continue and the driver could be removed and reinstalled. > As it stands now, when a controller stops with outstanding transfers in > progress you can't even rmmod the uhci-hcd driver. This is one of the > next changes I'm planning to make.
This doesn't work, rmmod uchi_hcd doesn't work, the first rmmod process locks up, the next fails with EBUSY. I'll try to compile a kernel that supports rmmod -f but I'm not too optimistic ATM. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
