Date: Mon, 19 Mar 2007 19:24:44 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: nve: ethernet address reversal code Message-ID: <20070319102444.GD13303@cdnetworks.co.kr> In-Reply-To: <45FACBE4.5090403@icyb.net.ua> References: <45FACBE4.5090403@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 16, 2007 at 06:55:00PM +0200, Andriy Gapon wrote:
>
> 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
>
Unlike other MCP hardwares, MCP61/MCP65/MCP67 stores ethernet address
in-order. nve(4)/nfe(4) should not swap ethernet address on these
hardwares. Peer Chen at NVIDIA and Shigeaki Tagashira sent me patches
to the issue and I've updated new nfe(4).
If you use CURRENT, try updated nfe(4) at the following URL.
http://people.freebsd.org/~yongari/if_nfe.c
http://people.freebsd.org/~yongari/if_nfereg.h
http://people.freebsd.org/~yongari/if_nfevar.h
For more detailed revision history and RELENG_6 sources, see
http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html
--
Regards,
Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070319102444.GD13303>