On Wed, Feb 19, 2003 at 07:12:58PM -0500, Johannes Erdfelt wrote:
> > Hm, uhci-hcd oopses if this happens :)
> > I could reproduce this very easily without that urb change but with the
> > usb-serial changes.
>
> Ahh, and that brings us back to the original patch.
>
> If so, it could be a bug in uhci-hcd. I'll attempt to duplicate the
> oops.
If you have a usb-serial device you should be able to do the following:
- get the latest -bk tree
- revert the urb.c patch
- load all needed drivers.
- plug in the usb-serial device
- run 'cat /dev/ttyUSB0'
- while that is just sitting there doing nothing, pull out the
device.
- wait a few seconds and then abort the 'cat' command.
A good device to try is the keyspan devices as they try to submit urbs
on their close path (I'm not going to comment on some of the logic in
that close path, it's ugly, and probably not right in places...)
Let me know if you find anything interesting.
> Does the existing serial driver submit URBs after the device is
> physically removed? (Like if an application still has an fd open when
> the device was removed)
Yes, some drivers do this, (the keyspan driver is one, and I think the
visor driver also wants to.)
> > What happens if the driver doesn't unlink the urb on disconnect, but
> > only does so a long time after disconnect happens? I image the existing
> > urb times out, right?
>
> Yeah, the HC will return the request back with an error because there is
> no device to NAK the packet.
Ok, that sounds good.
> > > As long as the rules about who owns the URB when and where are clearly
> > > defined (and implemented), then reference counting may not be necessary.
> >
> > Sure, but even when the HCD "owns" the urb, it can callback into the
> > driver, and the driver better still be in memory while the urb is alive.
>
> Yes, that is a concern, but it's a driver issue. The driver needs to
> make sure this doesn't happen.
But what about drivers that fire off urbs and don't keep a pointer to
them around? They don't know if all of their urbs are completed or not,
nor should they really care. The visor driver is one good example of
this.
> > > Look at struct sk_buff for instance, there is no reference count on it.
> >
> > Not yet :)
>
> Hmm, is there a discussion on linux-kernel that I skipped?
Not that I know of, see Rusty's post on linux-usb-devel yesterday for a
further explaination.
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
