Re: nve: ethernet address reversal code

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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • nve: ethernet address reversal code
    ... MAC address looked strange compared to other MAC addresses. ... mine is the only FreeBSD one. ... Abit NF7 motherboard (nForce2 chipset). ... here's a verbose dmesg after both of my patches and ...
    (freebsd-hackers)
  • Re: nve: ethernet address reversal code
    ... MAC address looked strange compared to other MAC addresses. ... mine is the only FreeBSD one. ... Abit NF7 motherboard (nForce2 chipset). ... here's a verbose dmesg after both of my patches and ...
    (freebsd-hackers)
  • RE: Realtek 811B LAN card on FreeBSD 7.0
    ... PCI Express LAN chipset is. ... The conclusion was that its behavior was rather flaky on FreeBSD 7.0 ... I had not kept the patches that worked on i386, ... I am currently using a PCI lan card that works with the rl driver but it ...
    (freebsd-questions)
  • RE: Security Announcements
    ... While I don't take your approach to maintaining my machines (I ... Perhaps patches to -RELEASE wouldn't come out as quickly as they ... maintain a single source tree for all of my machines. ... I just want to add my voice as to how I use FreeBSD. ...
    (FreeBSD-Security)
  • Re: Distributions of security patches.
    ... > installation of security patches to our FreeBSD machines. ... > releases easy to install it is a shame that it is not easy to install ...
    (FreeBSD-Security)