Hi guys,
I do have a motherboard based on the Intel C206 chipset which us used with an Intel Xeon E3-1260L processor. The board does have two Gb Intel NICs, one being an Intel 82574L (07:00.0) and the other being an Intel 82579LM (00:19.0); both numbers in paranthesis from lspic on linux - full details from lspci as follows (the two NICs are in bold and marked by ==>):
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:01.1 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 Processor Family Integrated Graphics Controller (rev 09)
00:06.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
==> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation C206 Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 02)
02:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)
03:00.0 Unassigned class [ff00]: OpenVox Communication Co. Ltd. Device 0100 (rev 01)
04:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
05:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
06:00.0 Communication controller: OpenVox Communication Co. Ltd. Device 0810 (rev 14)
==> 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
09:00.0 PCI bridge: Pericom Semiconductor PI7C8148A/PI7C8148B PCI-to-PCI Bridge
0a:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
0a:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
0a:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
0a:0b.0 Network controller: Qualcomm Atheros AR922X Wireless Network Adapter (rev 01)
.
Already at the beginning there have been issues with one of the onboard NICs: Although according to the board's MAC-address sticker its MAC address should have been 00:18:7d:1d:72:74 it actually identified with 88:88:88:88:87:88 to my DHCP server. The board manufacturer then sent me a firmware update tool and advised me to update the MAC adress - which I did.
Subsequentyl I faced substantial issues trying to bond the two NICs together which resulted in packet loss and very instable connections (e.g. long delays in ssh before a response came). As I was not sure whether I did something wrong, I decided to change plan und only use one NIC - according to lspci it was the 82579LM on address 00:19.0 - for my dom0 (the system will be used under XEN) and pass the second one through to a virtual HVM domu machine. After the XEN system was up and configured with a number of PV domUs I started to install the HVM domu and passed through the second.
Then the fun started again: Pinging the dom0 from the domu resulted in duplicate packets. There were NO duplicate packets when pinged from a Win7 machine so my first idea was that there's something wrong with the PCI-passthrough or linux. After thorough investigation it however turned out that the dom0 actually really sent two ICMP echo replies in reply to one ICMP echo request from the domU. Thise problems did not surface in Win7 because duplicates are obviously silently ignored by MS. All this was confirmed after lengthy inverstigations by mirroring a port on the switch and capture the traffic on that port on a third linux machine by tcpdump.
Next step was to go back to standard linux without XEN, drop the bridge and have a plain linux up and running:
If I only used the 82579LM I also saw DUP replies to ping from the other linux machine. After switching over to the 82574L the DUPs were gone - although and interestingly enough the arp information suggested that instead of the MAC address displayed in ifconfig (00:18:7d:1d:71:de), the card was cached as 00:18:7d:1d:71:74. Also the instability and the delays (both during session initiation and when it is on) for ssh sessions re-appeared - the connection was completrly lost when the session was left idle for some time.
To me this looks as if something is considerably broken - my idea would be that there's something wrong with the firmware. Albeit that's where all the trouble has started.
If somebody from Intel is able to provide me with a current firmware version together with a recent flash-tool I'd try to go dwon that route and see whether that changes anything. That is unless someone has a better idea or can pinpoint what to try next.
Thanks in advance and best regards
KK
P.S. I attach the current firmware version for both NICs; they have been extracted from DOS with EEUPDATE.EXE (date 08.11-2010 03:46, size 432.523 byte)