On Sat, Feb 22, 2003, David Brownell <[EMAIL PROTECTED]> wrote: > >>>Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update > >>>to Greg's CVS tree) and hasn't had the level of testing necessary to > >>>call it good. I also want to recheck that I caught all of the necessary > >>>paths. > >> > >>Seems like the main change there is that after disconnect, EDs > >>get cleaned up in the IRQ handler ... which means that when > >>the IRQ handler doesn't fire, nothing gets cleaned up. That > >>means some power management situations will (unnecessarily) > >>leak a lot, as will clean-up after the host controller dies > >>(maybe because of UE or cardbus eject). > > > > It won't leak EDs on power management. The cleanup will just be deferred > > until power comes back on. Big deal. > > Not on the D3cold resume path -- that can't be deferred.
I haven't looked at the PM paths yet, but if the D3cold path is via normal PCI exit paths, then it'll be fine with the module removal fix I'm testing. Either way, if the device is powered off, it's safe to cleanup the list earlier since the HC isn't gonna use it anymore. > >>>FWIW, we were hitting the BUG() call in sohci_free_dev(). > >> > >>With what device driver? As I've said, EVERY time I've looked > >>at such problems, the device driver has been at fault. Sometimes > >>quite blatantly, sometimes less so. EVERY TIME. > > > > usbnet. > > Curious -- the first such problem report I ever recall. I'd have > expected to have heard more reports ... but that driver's usage > growth has been pretty gradual, I know there have to be problems > that would show up under more serious loads. It's a race condition. It was very difficult to reproduce. One out of every 20 times and I could only reproduce it on some slower machines. My development P4 Xeon systems apparentely narrowed the race to the point where it was next to impossible to duplicate. > > It does already go to great lengths to ensure it's done with all of the > > references it takes to the device, but it's not the only source of > > references to the device. > > You mean, from the network layer? I thought I adopted the policy > where the usbnet disconnect() routine also blocked until the network > layer stopped using the device. Not necessarily an ideal policy on > busier links, but there've been on complaints. The code in usbnet looks fine (atleast I haven't seen anything wrong yet). The problem is with other drivers which take a reference count. Like say usbdevfs and sending a control message. > > Umm, I don't know why you still have this warped view of how the > > reference counting in 2.4 is supposed to work, but it's perfectly legal > > to have references past when disconnect() is called. > > Not from the hardware it isn't, and that's what deallocate() has > always expected to be deallocating. Once again, it's not an issue. Look at the code. Think about it. Reference counting will defer the deallocate() callback until when everyone is done with the device. The only problem with 2.4 I've found so far is the fact that the device id gets freed in disconnect() when it should be usb_free_dev() when the last reference is gone. JE ------------------------------------------------------- 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
