This is a discussion on Re: nfe0 watchdog timeout - FreeBSD ; On Tue, May 13, 2008 at 07:38:09AM +0200, Pascal Hofstee wrote: > On Tue, 13 May 2008 11:09:27 +0900 > Pyun YongHyeon wrote: > > > Can you see link state change reports of nfe(4) in your dmesg file? > ...
On Tue, May 13, 2008 at 07:38:09AM +0200, Pascal Hofstee wrote:
> On Tue, 13 May 2008 11:09:27 +0900
> Pyun YongHyeon
> > 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
> May 10 15:59:33 trinity avahi-daemon: Received packet from invalid
> 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:
> 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
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"