From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 17 17:42:23 2007 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8D4B16A400 for ; Sat, 17 Mar 2007 17:42:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 47DB813C480 for ; Sat, 17 Mar 2007 17:42:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HScHw-000MHM-IA; Sat, 17 Mar 2007 19:01:52 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Andriy Gapon In-reply-to: <45FACBE4.5090403@icyb.net.ua> References: <45FACBE4.5090403@icyb.net.ua> Comments: In-reply-to Andriy Gapon message dated "Fri, 16 Mar 2007 18:55:00 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Mar 2007 19:01:52 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: nve: ethernet address reversal code X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 17:42:23 -0000 > > 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: 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: on nve0 > Mar 14 19:05:32 rein kernel: ukphy0: 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