Re: nfe problem on 8.0-BETA2

From: Ryan Rogers <webmaster_at_doghouserepair.com>
Date: Tue, 21 Jul 2009 16:44:31 -0700
Sam Fourman Jr. wrote:
> On Mon, Jul 20, 2009 at 8:48 PM, Ryan
> Rogers<webmaster_at_doghouserepair.com> wrote:
>> I'm running 8.0-BETA2/amd64 on a system that has on-board ethernet.  It is
>> detected by FreeBSD as the following:
>>
>> nfe0: <NVIDIA nForce MCP55 Networking Adapter> port 0xac00-0xac07 mem
>> 0xcfffa000-0xcfffafff,0xcfff9000-0xcfff90ff,0xcfff8000-0xcfff800f irq 22 at
>> device 17.0 on pci0
>> miibus1: <MII bus> on nfe0
>> e1000phy0: <Marvell 88E1116 Gigabit PHY> PHY 1 on miibus1
>> e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> 1000baseT-FDX, auto
>>
>> The problem is, I can't get packets to move across the interface.  I know
>> that the interface works in Windows as well as Ubuntu, but it looks like
>> it's failing to get fully configured in FreeBSD.  The output of ifconfig
>> nfe0 is:
>>
>> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>        ether 00:04:4b:01:8c:0b
>>        inet 10.10.10.3 netmask 0xffffff00 broadcast 10.10.10.255
>>        media: Ethernet autoselect (none)
>>        status: active
>>
>> The part that I find odd is "media: Ethernet autoselect (none)".  If I
>> manually force it to "media 1000baseT mediaopt full-duplex", that line
>> becomes "media: 1000baseT full-duplex (10baseT/UTP half-duplex)". Still, the
>> interface is dead.
>>
>> I found PR kern/127910 which describes the same problem, except for
>> 7.0-RELEASE.  There's been no activity on that for 9 months though (aside
>> from my update today).  Can anyone offer me any insight on this?
>>
>> Thanks,
>> Ryan
> 
> 
> I can confirm this is a nfe problem, I first reported it to the
> mailing list a few weeks back
> under the subject FreeBSD 8 BETA1 DHCP trouble.
> http://groups.google.co.jp/group/muc.lists.freebsd.current/browse_thread/thread/ba7b35e561d3e868
> I have several different motherboards with nfe nics, My findings are as follows.
> 
> on a FreeBSD -CURRENT snapshot dated 6-1-2009 dhcp works as expected.
> somewhere after ~ 6-6-2009 something broke.
> 
> dhclient nfe0
> DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 4
> DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9
> DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9
> DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 12
> DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18
> DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.
> 
> the odd thing is that on motherboards that have dual nfe nics nfe1
> always works,and nfe0 is always broke.
> on motherboards that have only a single nfe interface nfe0 is indeed broke.
> 
> on a dual nic motherboard, if you go into BIOS and disable one of the
> LAN devices. DHCP will fail if the interface name is nfe0
> even though it worked 5 min before when that same nic and MAC address
> had the nfe1 name.
> 
> This entire thing is odd :)
> 
> 
> Sam Fourman Jr.
> 
> 

I have 7.2-RELEASE/i386 running perfectly using the same motherboard 
that is causing me nfe problems in 8.0-BETA2/amd64.  I then decided to 
see if perhaps it was something with i386 vs amd64, so I downloaded a 
7.2-RELEASE/amd64 iso, and the nics worked perfectly there as well.

Seeing that nfe apparently worked on June 1st, I headed to the FTP to 
see which snapshots were available.  The earliest -CURRENT June snapshot 
was dated the 8th, so I grabbed that one.  The nics didn't work at all.

So, there's a small window where something changed which broke nfe. 
Looking at the SVN commit logs for if_nfe.c, nothing really fits in that 
window.  To me, this looks like something about general network device 
handling changed which nfe nics can't cope with.  I have no idea what 
that could be though, so I'm hoping that someone on this list would be 
able to point me in the right direction.

Ryan
Received on Tue Jul 21 2009 - 22:13:16 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC