The serial sub-drivers (whiteheat.c is one) have to call tty_flip_buffer_push() somehow. Queueing the task means it runs from (timer) interrupt context. Calling it directly means a) low_latency is set; runs from sub-driver rx-side interrupt context or b) low_latency is *not* set and it's queued, see above.
So I don't see a way to not have flush_to_ldisc() eventually run in interrupt context. If there's a way, please let me know, because that would fix this issue right up. So, flush_to_ldisc() is running in interrupt context. It can call back into usbserial.c in a number of ways, specifically serial_throttle. Which tries to acquire a semaphore, which sometimes sleeps, resulting in a "scheduling in interrupt" crash. (In 2.6 the semaphore has been replaced with a work queue it looks like.) So it seems to me that usbserial is fundamentally broken. Am I correct? Is there any way to clean this up? Yes I'm volunteering. ..Stu ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
