[ipxe-devel] Intel 82576 MAC swapping

Anton D. Kachalov mouse at yandex-team.ru
Thu Jul 26 20:22:57 UTC 2012


Try to build iPXE with DEBUG=intel parameter passed to make and check MAC value and port number, especially for messages:

   "INTEL %p has autoloaded MAC address %s"

and

   "INTEL %p has EEPROM MAC address %s (port %d)\n"


26.07.2012, 22:10, "Kieran Evans" <keyz182 at gmail.com>:
> Here you go:
>
> # ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:1b:21:ad:d0:a0
>            inet6 addr: fe80::21b:21ff:fead:d0a0/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:1965 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:420 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:645671 (645.6 KB)  TX bytes:86364 (86.3 KB)
>
> eth1      Link encap:Ethernet  HWaddr 00:26:6c:fc:e4:0c
>            inet addr:192.168.1.27  Bcast:192.168.1.255 Mask:255.255.255.0
>            inet6 addr: fe80::226:6cff:fefc:e40c/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:26395 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:3644 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:29191936 (29.1 MB)  TX bytes:265101 (265.1 KB)
>            Memory:dfe20000-dfe40000
>
> eth2      Link encap:Ethernet  HWaddr 00:1b:21:ad:d0:a1
>            inet6 addr: fe80::21b:21ff:fead:d0a1/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:1966 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:418 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:645912 (645.9 KB)  TX bytes:85680 (85.6 KB)
>
> eth3      Link encap:Ethernet  HWaddr 00:26:6c:fc:e4:0d
>            UP BROADCAST MULTICAST  MTU:1500  Metric:1
>            RX packets:8768 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:125 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:2965286 (2.9 MB)  TX bytes:17344 (17.3 KB)
>            Memory:dfee0000-dff00000
>
> lo        Link encap:Local Loopback
>            inet addr:127.0.0.1  Mask:255.0.0.0
>            inet6 addr: ::1/128 Scope:Host
>            UP LOOPBACK RUNNING  MTU:16436  Metric:1
>            RX packets:161 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:161 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:18583 (18.5 KB)  TX bytes:18583 (18.5 KB)
>
> # cat /etc/udev/rules.d/70-persistent-net.rules
> # This file maintains persistent names for network interfaces.
> # See udev(7) for syntax.
> #
> # Entries are automatically added by the 75-persistent-net-generator.rules
> # file; however you are also free to add your own entries.
>
> # PCI device
> 0x8086:/sys/devices/pci0000:40/0000:40:02.0/0000:41:00.0/0000:42:08.0/0000:43:00.1
> (ixgbe)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:1b:21:ad:d0:a1", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
>
> # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0 (igb)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:26:6c:fc:e4:0c", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
> # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.1 (igb)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:26:6c:fc:e4:0d", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
>
> # PCI device
> 0x8086:/sys/devices/pci0000:40/0000:40:02.0/0000:41:00.0/0000:42:08.0/0000:43:00.0
> (ixgbe)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:1b:21:ad:d0:a0", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
> On 26/07/2012 19:00, Anton D. Kachalov wrote:
>
>>  Hi Kieran,
>>
>>  could you please paste the output from ifconfig and contents of /etc/udev/rules.d/*persistent-net.rules if it is exists.
>>
>>  26.07.2012, 21:17, "Kieran Evans" <keyz182 at gmail.com>:
>>>  Hi Anton,
>>>
>>>  Here's the output you requested. I also have a dual 10G card on these
>>>  servers too, I've included the output for them too for completeness.
>>>
>>>  # lspci -nn | fgrep 0200
>>>
>>>  02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
>>>  Network Connection [8086:10c9] (rev 01)
>>>  02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
>>>  Network Connection [8086:10c9] (rev 01)
>>>  43:00.0 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit
>>>  SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>>>  43:00.1 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit
>>>  SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>>>
>>>  # ethtool -i eth[0-3]
>>>
>>>  eth0:
>>>  driver: ixgbe
>>>  version: 3.6.7-k
>>>  firmware-version: 0x546d0001
>>>  bus-info: 0000:43:00.0
>>>  supports-statistics: yes
>>>  supports-test: yes
>>>  supports-eeprom-access: yes
>>>  supports-register-dump: yes
>>>
>>>  eth1:
>>>  driver: igb
>>>  version: 3.2.10-k
>>>  firmware-version: 1.4-3
>>>  bus-info: 0000:02:00.0
>>>  supports-statistics: yes
>>>  supports-test: yes
>>>  supports-eeprom-access: yes
>>>  supports-register-dump: yes
>>>
>>>  eth2:
>>>  driver: ixgbe
>>>  version: 3.6.7-k
>>>  firmware-version: 0x546d0001
>>>  bus-info: 0000:43:00.1
>>>  supports-statistics: yes
>>>  supports-test: yes
>>>  supports-eeprom-access: yes
>>>  supports-register-dump: yes
>>>
>>>  eth3:
>>>  driver: igb
>>>  version: 3.2.10-k
>>>  firmware-version: 1.4-3
>>>  bus-info: 0000:02:00.1
>>>  supports-statistics: yes
>>>  supports-test: yes
>>>  supports-eeprom-access: yes
>>>  supports-register-dump: yes
>>>
>>>  Motherboard model:
>>>
>>>  dmidecode | grep -i "Base Board Information" -A12 -B1
>>>
>>>  Handle 0x0003, DMI type 2, 15 bytes
>>>  Base Board Information
>>>           Manufacturer: Dell Inc.
>>>           Product Name: 040N24
>>>           Version: A02
>>>           Serial Number: <<Omitted>>
>>>           Asset Tag: .2
>>>           Features:
>>>                   Board is a hosting board
>>>                   Board is replaceable
>>>           Location In Chassis: To Be Filled By O.E.M.
>>>           Chassis Handle: 0x0004
>>>           Type: Motherboard
>>>           Contained Object Handles: 0
>>>
>>>  /Kieran
>>>
>>>  On 26/07/2012 17:50, Anton D. Kachalov wrote:
>>>>    Hello, Kieran.
>>>>
>>>>    I saw quiet the same behaviour on Asus motheboards with integrated 82574 NIC. The same as Supermicro (82576) wiring will lead to different interface name in Linux. On Asus we usually have first LAN as eth1 and second LAN as eth0. Supermicro has proper correlation: eth0 for LAN1 and eth1 for LAN2.
>>>>
>>>>    What model of mobo has you?
>>>>
>>>>    Could you please provide the output of the following commands:
>>>>
>>>>       # lspci -nn | fgrep 0200
>>>>       # ethtool -i eth0
>>>>       # ethtool -i eth1
>>>>
>>>>    26.07.2012, 20:12, "Kieran Evans" <keyz182 at gmail.com>:
>>>>>    Hi,
>>>>>
>>>>>    I have several servers withe Intel 82576 Dual Port Gigabit NICs in them.
>>>>>
>>>>>    I currently have only one port from each wired up to the network, and
>>>>>    the other empty. I can get iPXE to boot, and it'll get a DHCP link and
>>>>>    do it's thing.
>>>>>
>>>>>    The problem is, iPXE will boot from nic0 with MAC address
>>>>>    XX:XX:XX:XX:XX:0d, but once in linux, trying to run dhclient on the
>>>>>    interface that has that MAC address fails. ethtool claims no link.
>>>>>    Running dhclient on the interface XX:XX:XX:XX:XX:0c succeeds however. 0c
>>>>>    is the interface iPXE claims to be net1, which it is unable to get a
>>>>>    link on.
>>>>>
>>>>>    I'm using the onboard PXE boot environment to chainload iPXE. The
>>>>>    onboard PXE gets a link and loads iPXE through the 0c interface,
>>>>>    followed by iPXE getting a link on the 0d interface, followed by Linux
>>>>>    being able to get a link on 0c again.
>>>>>
>>>>>    I believe this problem may be linked to point 5 in this FAQ[1] relating
>>>>>    to the 82580
>>>>>          Are the MAC Addresses still automatically calculated like on the 82576?
>>>>>
>>>>>    So my guess is that the MAC Addresses are calculated when the driver
>>>>>    loads, and some difference between the way the BIOS, iPXE and Linux
>>>>>    drivers work causes the interfaces to be enumerated in different orders.
>>>>>
>>>>>    This is an issue as trying to pass anything like BOOTIF to get
>>>>>    installers and such to use the correct interface to install from doesn't
>>>>>    work.
>>>>>
>>>>>    Output from ifstat if needed:
>>>>>
>>>>>    net0: 00:26:6c:fc:e4:0d using 82576 on PCI02:00.0 (open)
>>>>>        [Link:up, TX:4 TXE:0 RX:11 RXE:4]
>>>>>        [RXE: 4 x "Operation not supported (http://ipxe.org/3c086003)"]
>>>>>    net1: 00:26:6c:fc:e4:0c using 82576 on PCI02:00.1 (closed)
>>>>>        [Link:down, TX:0 TXE:0 RX:0 RXE:0]
>>>>>        [Link status: Down (http://ipxe.org/38086101)]
>>>>>
>>>>>    /Kieran
>>>>>
>>>>>    [1]
>>>>>    http://communities.intel.com/community/wired/blog/2010/05/20/frequently-asked-questions-for-the-intel-82580-gigabit-ethernet-controller
>>>>>
>>>>>    _______________________________________________
>>>>>    ipxe-devel mailing list
>>>>>    ipxe-devel at lists.ipxe.org
>>>>>    https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>>  _______________________________________________
>>>  ipxe-devel mailing list
>>>  ipxe-devel at lists.ipxe.org
>>>  https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

-- 
Anton D. Kachalov

ITO, R&D group, Senior System Engineer
Tel: +7 (495) 739-70-00 ext.7613



More information about the ipxe-devel mailing list