On Sun, Sep 27, 2009 at 09:52:54PM +0100, Alan Cox wrote: > > > What backtrace do you get from the WARN_ON when that occurs. I'm trying > > > to work out how it happens in the first place because really it would be > > > better if it simply didn't happen at all. > > > > drivers/usb/serial/usb-serial.c: serial_close - port 0 > > drivers/usb/serial/usb-serial.c: serial_chars_in_buffer = port 0 > > drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 > > drivers/usb/serial/ftdi_sio.c: ftdi_close > > drivers/usb/serial/usb-serial.c: serial_unthrottle - port 0 > > So its during the close not after it - that's not unreasonable. The test > itself should either go or use ASYNCB_INITIALISED. Not unreasonable, but new. :) The generic driver, for instance, always resubmits (in the irq handler unless throttled and on unthrottle) until the urb is killed on close. This new possibility of an unthrottle call after the driver specific close breaks the assumptions under which this makes sense. So, as I see it, either we go through all drivers and make sure that they never resubmit unless ASYNCB_INITIALIZED is set (note that this implies setting the flag prior to driver specific open), or we use the generic driver's scheme of always resubmitting and deal with the late call to unthrottle somehow. The latter seems cleaner to me, were it not for the late unthrottle... Some of the unthrottle implementations I've skimmed, check if they're actually unthrottled before resubmitting/rescheduling, so we could easily add an extra test for ASYNCB_CLOSING here (or clear the unthrottle flags in close). But note that several drivers resubmit unconditionally (and only a few check port count). Or we retain the old semantics for unthrottle, where it simply does not get called at all on close, by blocking it in usb serial_unthrottle. But essentially, either all drivers always check ASYNCB_INITIALIZED everywhere, or ASYNCB_CLOSING is checked (somewhere) on unthrottle? /Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
