> Yes, that's why I asked about EHCI. My speculation would be that > OHCI starts the reset, and EHCI claims the port before it completes; > or contrariwise OHCI starts the reset right after EHCI claims it. > > And there's some point in that process where a hardware race makes > the trouble you've observed. I believe there are plenty of other > places where it's perfectly fine if EHCI grabs the port, or this > little race would have shown up many times before.
Since we can't know which O/UHCI is paired with which EHCI, we can't really have generic code to deal with that race, but maybe we can be smart and basically mutex khubd activity such as port reset vs. registration of any new HCD ? I'm not even sure module load order is 100% fault proof here since khubd spawns as a thread... Ben. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
