nve: ethernet address reversal code

[Danny Braniss]

> 
> I am wondering what is the purpose of the following pieces of code in
> if_nve.c:
> 
> /* ... nve_attach ... */
> 	/* MAC is loaded backwards into h/w reg */
> 	sc->hwapi->pfnGetNodeAddress(sc->hwapi->pADCX, sc->original_mac_addr);
> 	for (i = 0; i < 6; i++) {
> 		eaddr[i] = sc->original_mac_addr[5 - i];
> 	}
> 	sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, eaddr);
> 	bcopy(eaddr, (char *)&sc->sc_macaddr, ETHER_ADDR_LEN);
> 
> 
> /* ... nve_detach ... */
> 	/* Reload unreversed address back into MAC in original state */
> 	if (sc->original_mac_addr)
> 		sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX,
> 		    sc->original_mac_addr);
> 
> Small note: pointer check in nve_detach is obviously not needed because
> sc->original_mac_addr is not a pointer but an array.
> 
> 
> I am asking the question for two reasons:
> 
> 1. [theoretical] I am not sure what pfnSetNodeAddress() is doing, but if
> it makes modification in NIC memory that can persist across PC reset or
> poweroff, then this code can be dangerous if a machine crashes/hangs/etc.
> 
> 2. [practical] I recently installed 6.2-RELEASE amd64 on Asus M2N
> machine (chipset nForce 430 MCP == MCP61, onboard NIC pci chip id is
> 03ef). After a small patch to add this ID to nve everything worked very
> well (in 1 Gb mode). That is, almost everything: I had a very strange
> problems access one particular machine on my LAN. I still don't know
> what exactly was the problem, but during its investigation I noticed my
> MAC address looked strange compared to other MAC addresses. You, we have
> a bunch of machines with identical HW on our LAN, they all run either
> Linux or Windows, mine is the only FreeBSD one.
> So, my ethernet address was a5:07:9f:f3:18:00, but other guys had
> something like 00:18:f3:9f:XX:YY. After some digging around I went into
> the sources, changed [5-i] to [i] and everything started to work perfectly.
> Then I looked at some other machine that uses nve: FreeBSD 6.1 i386,
> Abit NF7 motherboard (nForce2 chipset). MAC address there is
> 00:50:8d:4d:aa:83, which looks pretty normal.
> 
> So I am wondering if this is a 64-bit thing or something specific to a
> particular chipset. Unfortunately, I can not test i386 version of
> FreeBSD (patched to recognize my chipset) on this hardware now.
> 
> P.S. just in case, here's a verbose dmesg after both of my patches and
> kldunload/kldload:
> Mar 14 19:05:32 rein kernel: pci0:7:0: reprobing on driver added
> Mar 14 19:05:32 rein kernel: nve0: <NVIDIA nForce MCP14 Networking
> Adapter> port 0xe480-0xe487 mem 0xddefd000-0xddefdfff irq 20 at device 7.0
>  on pci0
> Mar 14 19:05:32 rein kernel: nve0: nvenetlib.o version 1.0-13
> Mar 14 19:05:32 rein kernel: nve0: Ethernet address 00:18:f3:9f:07:a5
> Mar 14 19:05:32 rein kernel: miibus0: <MII bus> on nve0
> Mar 14 19:05:32 rein kernel: ukphy0: <Generic IEEE 802.3u media
> interface> on miibus0
> Mar 14 19:05:32 rein kernel: ukphy0: OUI 0x001374, model 0x0001, rev. 6
> Mar 14 19:05:32 rein kernel: ukphy0:  10baseT, 10baseT-FDX, 100baseTX,
> 100baseTX-FDX, 1000baseT-FDX, auto
> Mar 14 19:05:32 rein kernel: nve0: bpf attached
> Mar 14 19:05:32 rein kernel: nve0: Ethernet address: 00:18:f3:9f:07:a5
> Mar 14 19:05:32 rein kernel: nve0: [MPSAFE]
> Mar 14 19:05:32 rein kernel: pci1: driver added
> Mar 14 19:05:32 rein kernel: pci2: driver added
> Mar 14 19:05:32 rein kernel: found->    vendor=0x10de, dev=0x016a,
> revid=0xa1
> Mar 14 19:05:32 rein kernel: bus=2, slot=0, func=0
> Mar 14 19:05:32 rein kernel: class=03-00-00, hdrtype=0x00, mfdev=0
> Mar 14 19:05:32 rein kernel: cmdreg=0x0007, statreg=0x0010, cachelnsz=16
> (dwords)
> Mar 14 19:05:32 rein kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns),
> maxlat=0x00 (0 ns)
> Mar 14 19:05:32 rein kernel: intpin=a, irq=16
> Mar 14 19:05:32 rein kernel: powerspec 2  supports D0 D3  current D0
> Mar 14 19:05:32 rein kernel: MSI supports 1 message, 64 bit
> 
> 
> -- 
> Andriy Gapon

we saw this too!, downgrading the BIOS fixed it for us.
btw, 00:18:.... is the correct mac.
the problem shows up only when booting via PXE.

danny