[ipxe-devel] Intel 82576 MAC swapping

Thu Jul 26 18:00:42 UTC 2012

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

-- 
Anton D. Kachalov

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