NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/44072: misread of ethernet addresses on intel quadport gigabit (82576)



>Number:         44072
>Category:       kern
>Synopsis:       misread of ethernet addresses on intel quadport gigabit (82576)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 09 15:05:00 +0000 2010
>Originator:     Jean-Yves Moulin
>Release:        NetBSD-5.99.39
>Organization:
Eileo
>Environment:
NetBSD republique.eileo-local.org 5.99.39 NetBSD 5.99.39 (REPU) #3: Thu Nov  4 
17:44:55 CET 2010  
jym%republique.eileo-local.org@localhost:/usr/obj/sys/arch/amd64/compile/REPU 
amd64

>Description:
Hardware is: Dell poweredge R210 with intel quad-port gigabit (i82576 pci-e) 
bought from Dell.

The i82576 is recognized correctly but only two ports are working: wm0 and wm2. 
Ethernet addresses are correctly read for these two ports.

wm1 and wm3 are not working because of ethernet address set to 
'ff:ff:ff:ff:ff:ff' (broadcast).

Everything else is working (ifconfig, media negotiation...etc), 

The problem come from packets on wm1 and wm3: they are sent with this bogus 
ethernet address.


>How-To-Repeat:
Boot NetBSD with intel quad-port gigabit i82576. Try to use port 1 or 3 (wm1 or 
wm3).
>Fix:
Force the driver to increment address read from previous port (same eeprom). 
This is already done for some card. And this is done by FreeBSD driver too.

FreeBSD driver explain this (for 82575/82576):
 *  Reads the device MAC address from the EEPROM and stores the value.
 *  Since devices with two ports use the same EEPROM, we increment the
 *  last bit in the MAC address for the second port.


On NetBSD, in /usr/src/sys/dev/pci/if_wm.c: the alternate mac address offset is 
stored in EEPROM_ALT_MAC_ADDR_PTR. Driver read at (offset + sc->sc_funcid).
 
But the offset in EEPROM_ALT_MAC_ADDR_PTR in this card seems to be bad. It 
shows 0x3d0 on my card. And there is no Ethernet address in (offset + 
sc->sc_funcid). Nor in offset.

Using the following patch solve the problem. But it's based on my card offset 
data.


-- /usr/src/sys/dev/pci/if_wm.c.1.215    2010-11-09 15:41:31.000000000 +0100
+++ /usr/src/sys/dev/pci/if_wm.c        2010-11-09 15:47:30.000000000 +0100
@@ -4755,6 +4755,13 @@
                                do_invert = 1;
                                goto do_read;
                        }
+                       /* 82576 show offset but there is no data */
+                       if(sc->sc_type == WM_T_82576 && offset == 0x3d0) {
+                               /* reset the offset to LAN0 */
+                               offset = EEPROM_OFF_MACADDR;
+                               do_invert = 1;
+                               goto do_read;
+                       }
 
                        switch (sc->sc_funcid) {
                        case 1:



Home | Main Index | Thread Index | Old Index