Date: Fri, 12 Nov 2010 00:00:54 GMT From: yongari@FreeBSD.org To: rfarmer@predatorlabs.net, yongari@FreeBSD.org, freebsd-bugs@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/152150: nfe(4) not working on Asus P5N32-SLI Premium motherboard (nforce 590) Message-ID: <201011120000.oAC00sG5079043@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Synopsis: nfe(4) not working on Asus P5N32-SLI Premium motherboard (nforce 590) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Nov 11 23:59:50 UTC 2010 State-Changed-Why: It seems you have three issues here. o watchdog timeout issue o can't send/receive frames with either DHCP and static IP assignment o generate bogus traffic storm which in turn make systems connected to switch lost connection For watchdog timeout issue, would you try the patch at the following URL? http://people.freebsd.org/~yongari/nfe/nfe.watchdog.diff The second issue could be related with tracking of link state change. The patch above will show "LINK UP" message on your console if nfe(4) think it established a link. Otherwise it would print "LINK DOWN". In order to send/receive frames, you always have to see "LINK UP" message first. Please check whether you can see the message with DHCP or static IP configuration. I have no idea for the last issue. Can you see what kind of traffic is generated on link partner side? I think you can connect two systems with straight cable and see what kind of traffic does the nfe(4) generate on other system with tcpdump. If it's 802.3x flow control traffic I have idea how to keep it from happening. Responsible-Changed-From-To: freebsd-bugs->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Nov 11 23:59:50 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=152150
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011120000.oAC00sG5079043>