On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote: > 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: > > > > 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 don't think setting dev->bus to NULL is the right way, simply because the bandwidth is not available to the rest of the system until all of the URBs have been fully removed. To handle the bandwidth correctly, we need that pointer to the end. Also, deallocate() needs to be called when there are no more URBs for the OHCI driver to work (atleast in 2.4, I'm assuming the 2.5 driver has similar requirements) Are you worried about submitting an URB after the device has been disconnected? In 2.4 atleast, you can still submit URBs while one reference still exists. But it's mitigated by the drivers since they won't submit any more URBs since they received the disconnect() handler, or the usbdevfs node was removed. > > > 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...) We need some sort of way to determine if the device is physically present it sounds. I don't think a way exists to do that yet. Like I mentioned above, I don't think NULLing dev->bus is the way to do this. I guess a flag is the best way? 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
