On Monday 11 November 2002 03:04, David Brownell wrote: > > (c) submits an interrupt urb. This urb will not complete > > for a long time. The urb is in the async pending list. > > (d) releases the interface (as a side effect, this means > > that driver_disconnect will NOT be called on hub removal). > > > > Note that the urb is still in the async pending list. > > Which would be the problem. If usbfs had unlinked it, the > oops would vanish -- yes? Good find! > > I think it's a driver bug (usbfs) that it released any > interface with an urb still pending.
Hi Dave, thanks for reading my emails! There seem to be multiple bugs: (1) releasing an interface but not cancelling pending urbs. (2) devio.c has no way of knowing that a device has been removed (unless it got lucky and somebody claimed an interface on the device), so will still submit urbs etc to it [I didn't test this but I plan to]. > I agree that it'd be better if usbcore guarded against the > inevitable driver bugs, but that seems like 2.5 material > due to the kind of changes needed.- Dave I think this is a bug in the core: (3) urbs are not being cancelled on hub (device?) removal. After all, suppose I do the following: (a) I submit an interrupt urb to my modem. This urb completes when the state of the telephone line changes (= usually never). (b) I remove the hub driver. The urb has not been unlinked. (c) I unplug the telephone line from my modem. The urb completes. But the hub driver has gone! At this point something nasty happens, right? Hmmm, I should test this too. Fixing either (1) or (3) would stop the current oops, but it looks like (1), (2) and (3) need to be fixed. Ciao, Duncan. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
