Hi,
- probe function is called, driver is bound to an interface
- (driver cannot be unloaded now - this is done in sysfs, no?)
Just what does sysfs do here? So far as I am aware, it does nothing to
prevent the driver from being unloaded. And if it does do something, how
does the user tell it when he wants to allow the module to be unloaded?
That was a guess - and it seems wrong (I should have taken the 30 seconds
needed to check...). I can't in fact see anything that stops the module
being unloaded after a successful probe! I assumed that the driver would
be registered with sysfs and sysfs would take a reference, but if so I can't
find it.
Ignoring sysfs for a moment, there _should_ be nothing stopping module
unload then, short of someone having opened the driver so that it's
now in active use. If some component upped the refcount when the
driver wasn't actually in use, it couldn't be unloaded.
Sysfs is another story. I do still see oopses coming from there. I
think some of the handshaking is evidently not achieving its goal.
in disconnect driver calls usb_unlink_urb to kill urbs in flight,
but this fails for some urbs.
I've been working on the usb_unlink_urb() code. So far as I can tell, it
can't really fail unless something is _very_ wrong with the low-level HCD.
"Shouldn't really fail", yes.
The standard error codes that it might return don't actually indicate
failure; they indicate an attempt to unlink an urb that has already been
unlinked, is already finishing up, or has already completed.
That's good to know - since most drivers assume it cannot fail!
But since "unlink" means "completion fires with special UNLINK status"
(ECONNRESET, ENOENT) those nuances can matter. (Alan, I've started to
look at your patch but it needs more thought.)
Driver decides to follow Dave's
advice and leak memory in this error situation, so it doesn't
free its structures, and exits the disconnect method.
The first part of the advice was equally important: log a message,
so that eventually, in the unlikely case something bad happens, it
can be tracked down with less pain.
All we know is that by the statistics, it's likely that leaking is
going to avoid _immediate_ problems. So there's no better option
for such situations. Except maybe adding a short delay if you're
deeply concerned about letting module unload proceed right then.
- Dave
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
