Hi Alan:
What does exactly this error mean? When is it generated? Is there any
known reason that could make the kernel enter an infinite loop that
would generate this error continously, even in the absence of the
original condition?
-110 is -ETIMEDOUT. In this case it means that the device is not
responding to data sent by the computer.
I don't know what you mean by "the absence of the original condition".
Presumably that condition (device not responding) is still present. The
driver is probably written so that it keeps on trying to communicate with
the device -- and getting these errors -- until the device is
disconnected.
Alan Stern
Thank you for your answer.
What I meant by "the absence of the original condition" is whether the
kernel code would get in an infinite loop triggered by an error in a USB
device or once this error is solved, the error messages stop.
Errors in a device aren't supposed to put the kernel in an infinite loop.
Once the device stops misbehaving, the kernel should stop looping. But
there might be bugs in some drivers which cause them to stay in the loop.
So basically you're asking "Are there bugs in the Linux kernel?"
Certainly there are bugs -- it's impossible to avoid them in any program
as large and complex as the kernel -- but we don't know what they are. If
we did, we would fix them.
In any case, how can I know where the error was happening from the log
messages? In a USB hub or in a USB device?
I can't answer that because you only showed a few lines from the log.
Even with the complete log it might not be possible to tell where the
error is. It could be in the driver, in the computer's USB controller, in
the USB cable, in an intermediate hub, or in the device. I've seen
examples of each kind.
Thanks again for your time and help. I really appreciate it.
Of course I understand that the kernel might have bugs. Maybe I did not
asked the question correctly (I am not an English native speaker). What
I wanted to know if there were some reports of errors of the same kind,
but that could not be solved since they were not easily reproduced. In
any case, I have finally found out that it is the USB device that is
failing.
What I would suggest is that the USB device driver should protect itself
from failing devices (or hubs, cables, etc.) I think that there is no
point in trying to contact again and again with a device that is not
respoding. After 10/100/1000/?? times, the device driver should stop
trying. Filling the syslog with repeated error messages is useless.
Regards,
Pedro Monjo
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
