Try forcing it to use a period other than 1 usec.
Change the pl2303 driver? Or do you mean the ehci driver?
Workaround: change pl2303.
To do what? Submit an interrupt urb with a _different_ timevalue from what the endpoint describes it should be? Any guidelines here?
The URB specifies a 1 msec period, so yes change it to something less demanding. 2 msec should make it work, but then no more requests of 1 msec or 2 msec would succeed. I'd try 4 or 8 msec, leaving exponentially more options to the (dumb) scheduler, or even more ... unless there's some reason it's got to poll at a high rate?
The bigger value is just reducing the likelihood of a schedule collision, not eliminating it. Many devices that specify a fast poll rate (1msec) don't actually need it, and it just wastes bandwidth.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
