nfe0 watchdog timeout
Pyun YongHyeon
pyunyh at gmail.com
Tue May 13 08:59:48 UTC 2008
On Tue, May 13, 2008 at 07:38:09AM +0200, Pascal Hofstee wrote:
> On Tue, 13 May 2008 11:09:27 +0900
> Pyun YongHyeon <pyunyh at gmail.com> wrote:
>
> > Can you see link state change reports of nfe(4) in your dmesg file?
> > If you find any entries related with nfe(4) please show them to me.
> > It may have a couple of link UP/DOWN messages and watchdog timeouts.
>
> You are right i initially overlooked the link state messages. They're
> no longer in dmesg ... but i copy/pasted a small set
> from /var/log/messages instead:
>
> May 10 15:59:31 trinity kernel: ums0: at uhub0 port 1 (addr 2)
> disconnected May 10 15:59:31 trinity kernel: ums0: detached
> May 10 15:59:33 trinity kernel: nfe0: link state changed to DOWN
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Something happend here. But I have no idea why link state was
changed here.
> May 10 15:59:33 trinity avahi-daemon[811]: Received packet from invalid
> interface.
> May 10 15:59:33 trinity acpi: resumed at 20080510 15:59:33
> May 10 15:59:34 trinity root: Unknown USB device: vendor 0x046d product
> 0xc404 bus uhub0
> May 10 15:59:34 trinity kernel: ums0: <Logitech Trackball, class 0/0,
> rev 1.10/2.20, addr 2> on uhub0
> May 10 15:59:34 trinity kernel: ums0: 3 buttons and Z dir.
> May 10 15:59:45 trinity kernel: nfe0: link state changed to UP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Shomething brought up the link again. If link partner is switch then
I hardly guess this unless you unplug/plug UTP cable.
> May 10 15:59:53 trinity kernel: nfe0: watchdog timeout (missed Tx
> interrupts) -- recovering
> May 10 16:00:35 trinity last message repeated 5 times
> May 10 16:01:53 trinity last message repeated 9 times
>
> I opted to include the usb-related messages as well since i find it
> somewhat odd my Trackball decided to disconnect since i never take it
> off ... Followed by the ACPI resumed message ... this to me feels like
> the system may have been in some sort of power saving mode ?
>
If this is something related with suspend mode I guess you can
easily verify this(Add some printfs in if_nfe.c:nfe_suspend).
I vaguely guess link state handling of nfe(4) is not complete so
it may have reprogrammed MAC with invalid speed/duplex during
link state transition.
> > When you know nfe(4) is not working anymore, would you check Rx MAC
> > is still able to see incoming packets by invoking tcpdump on
> > nfe(4) interface?
>
> Once it happens again i'll make sure to check on it.
>
> > It would be even better I can see verbosed boot messages related
> > with nfe(4).
>
> Will provide once i can reboot the system again (it's currently in the
> middle of a somewhat lengthy build process).
>
> With kind regards,
> --
> Pascal Hofstee
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list