Re: nfe0 watchdog timeout

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