Hi Dave,
does this remove your doubts about race conditions in the synchronous API?
It's a lot closer ... I'll try it. Yes, it's odd that there was no pre-existing "wait_event_timeout()", and that's the call we need to make that implementation behave right.
Some further cleanup: abolish "struct usb_api_data", it's exactly the same as "struct completion". Then likely that completion callback can just call complete(). And why are you initializing the waitqueue head twice? Also: if I were doing it, I'd not use the synchronous unlink call; "ought not" to matter, but we can be more sure than that.
Curiously enough, I seem to have found a way to reproduce the previous "raced timeout" message -- which is IMO proof that my doubts were well deserved. (Specifically the ones about the implementation being broken; API is another issue.)
Basically, with the system under heavy USB loads (two EHCI devices putting 20+ MByte/sec loads, plus the device side logic of one of those -- net 70+ MByte/sec!) and interrupt load to match ... system latencies were high enough that I couldn't enumerate a new device. I got the "raced" message, then first khubd and then the rest of the USB stack locked up. There was another wierdness going on too, but clearly the synchronization replaced by your patch was also broken.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
