On Fri, Oct 12, 2001 at 01:19:00AM +0200, Henner Eisen wrote: > Hi, > > while trying to get the pl2303 driver running with my ATEN UC-232A serial > converter (*), I'm wondering whether there might be a certain kind > of race condition present in the usb serial code. > > [ (*) For a patch against 2.4.10, which adds yet some additional features, > see http://www.baty.hanse.de/pl2303/pl2303-2.4.10.diff. > The patch has some overlap with current 2.4.11/2.4.12 changes, > thus it unfortunately won't apply cleany against current 2.4.12 yet. ]
I think the 2.4.12 version has almost all of the features that you have in your version. If not, please let me know. > However, on SMP, the situation is worse: If interrupt handler modifies > urb data, and if irq handler and generic_write run on a different CPUs, > scenarios are imaginable where generic_write() modifies and re-submits > the urb before the interrupt handler (inlucuding the urb completion > handler) has finished. Yes, we (or at least I) know that simply checking the urb->status field isn't entirely safe, and this will be fixed in 2.5. Have you seen problems like the one you are talking about? I have run lots of data through usb-serial converters on SMP machines with no ill effects. > With the pl2303 driver, the situation is even worse, because > pl2303_write_bulk_callback() might re-transmit the urb on its own for > error recovery. Thus, with pl2303, races might already cause harm on a > single processor machine. Yes, that could cause a problem. To fix this a urb pool should be implemented, like the visor and empeg drivers have. Have you seen write urbs failing? thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
