Hello all,
I had yesterday a surprising kernel message
NETDEV WATCHDOG: bnep0: transmit timed out
It occurred exactly once and then never more.
This happened on a FOXBoard with an Etrax100LX,
i.e. cris architecture, almost exactly twenty
four hours after the bnep link was initiated.
The kernel is 2.6.19, with bluez code seemingly
identical to the code in 2.6.18-mh8, but that
is beside my present point.
My question: Is it more probable that it is the
usb driver that has a suboptimal timer use within
the kernel, or could it be that bnep/core.c or
bnep/netdev.c somehow should take timing of a
particular usb interface into account? The regular
kernel documentation mentions that the ethernet
driver e1000.ko can have a timer issue. That is how
I come to think along these lines.
The remarkable aftermath is that after the isolated
barking of my watchdog, the bnep link transmitted
in a fragmented manner (like spikes viewed with gkrellm)
for three hours, and then magically recovered again
and is now running for an additional twenty four hours.
The only extraneous log message for bluez in these
forty eight hours, is that singular "NETDEV WATCHDOG" call.
The FOXBoard is the PANU-side, and on the NAP-side the
logging is completely silent!
Thanks for your attention and presumptive remarks.
Mats Erik Andersson, PhD
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Mats,
> I had yesterday a surprising kernel message
>
> NETDEV WATCHDOG: bnep0: transmit timed out
>
> It occurred exactly once and then never more.
> This happened on a FOXBoard with an Etrax100LX,
> i.e. cris architecture, almost exactly twenty
> four hours after the bnep link was initiated.
> The kernel is 2.6.19, with bluez code seemingly
> identical to the code in 2.6.18-mh8, but that
> is beside my present point.
>
> My question: Is it more probable that it is the
> usb driver that has a suboptimal timer use within
> the kernel, or could it be that bnep/core.c or
> bnep/netdev.c somehow should take timing of a
> particular usb interface into account? The regular
> kernel documentation mentions that the ethernet
> driver e1000.ko can have a timer issue. That is how
> I come to think along these lines.
the 2.6.19 kernel is old. So I have no idea. In some cases disabling the
SCO support of the hci_usb driver helps. Either via kernel option or
loading it with isoc=0.
Also BNEP is in general able to recover from wrong data packets so it
might be simply something that can happen or a bug in the network stack
that has already been fixed. Use a 2.6.22 or later kernel.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users