On Tue, Feb 18, 2003 at 12:24:49PM -0500, Johannes Erdfelt wrote: > On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 18, 2003 at 08:59:15AM -0800, David Brownell wrote: > > > Greg KH wrote: > > > > > > > >Yes, this is a problem, the module can be unloaded and then the > > > >completion fuction can be called. > > > > > > How? I don't see it. Unless the driver completely violates > > > basic rules like implementing disconnect() correctly, which > > > will break more than just module unloading. > > > > Hm, let me think about this some more before responding... > > > > > > I'm trying to fix up the usb device reference counting > > > >logic right now and running into issues where host controllers try to > > > >access urbs after their devices have been removed from the system :( > > > > > > Not supposed to happen ... when they call giveback(), that's supposed to > > > mean they've forgotten about that URB. Is it buggy disconnect() logic, > > > or some HCD calling giveback too early? > > > > I'm seeing uhci_irq() get called for an urb that belongs to a usb device > > that has already been disconnected. Things go wrong when > > uhci_transfer_result() is called, which calls usb_release_bandwidth() > > which expects dev->bus to be a valid pointer. I thought that after > > deallocate() is called on the bus for the device, everything would be > > cleaned up. > > This is a reference counting problem. > > In 2.4, uhci.c holds a reference to the device until after it's done > calling the completion handler. > > Now in 2.5, the hcd layer doesn't hold that reference anymore it seems. > > That should be fixed.
Hm, well in my patch, I'm making the assumption that after deallocate() the device is really gone, is that true? The hcd can still hold a reference to the device, if it needs it, that's a valid thing to do. What does the hcd use to tell if the dev is really present or not? That's what I'm after. > > I have a patch to the usb serial code that tests this logic out by > > holding a reference to the usb device structure while a port is opened > > by a user. That way, if the device disappears, then all writes and > > reads get a -ENODEV, and when the last consumer leaves the driver, the > > device is finally deleted from memory properly. This seems to solve the > > nasty race conditions that people have been having with the usb-serial > > drivers lately. > > > > Time to test this out on ohci to see how well it works... > > I think you're solving the symptom, not the problem. Yes, the symptom is the oops. The real problem is not handling the reference count of the tty device and the usbserial device properly. I'm trying to fix that up. Right now if I hold a reference to the usb dev in the driver, after the device has been disconnected, some usb drivers try to talk to the device on close(). The hcd doesn't seem to realize that the dev is no longer present, and tries to submit the urb and ends up just sitting and spinning forever. That's why I tried to mark the dev as "gone" by disconnecting the link from it to the bus with the patch I provided. Any better suggestions to accomplish this would be welcome (I did try a "present" flag which worked, but seemed contrived, but might be the best option in the end...) thanks, greg k-h > > JE ------------------------------------------------------- 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
