Intel I340-T4 (net-igb) verweigert Dienst unter EXi 6.0

[marco80]

Guten Tag zusammen,

ich bin zur Zeit ziemlich ratlos - und hoffe Ihr könnt etwas Licht ins Dunkel bringen.

Es geht darum eine Intel I340-T4 unter ESXi 6.0 zur Kooperation zu bewegen. Nach meiner Information ist diese unter ESXi 6.0 lauffähig (http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=14749&deviceCategory=io&details=1&partner=46&releases=273&deviceTypes=6&page=5&display_interval=10&sortColumn=Partner&sortOrder=Asc) mit der igb version 5.2.5.

Diese habe ich nach folgender Anleitung http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1034782 auch zur Zusammenarbeit bewegen wollen - ohne Erfolg.

Ausgabe esxcli network nic list

Code: Alles auswählen

Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address         MTU  Description                               
------  ------------  ------  ------------  -----------  -----  ------  -----------------  ----  -------------------------------------------
vmnic0  0000:00:14.0  igb     Up            Up            1000  Full    00:25:90:82:9a:f8  1500  Intel Corporation Ethernet Connection I354
vmnic1  0000:00:14.1  igb     Up            Down             0  Half    00:25:90:82:9a:f9  1500  Intel Corporation Ethernet Connection I354
vmnic2  0000:00:14.2  igb     Up            Down             0  Half    00:25:90:82:9a:fa  1500  Intel Corporation Ethernet Connection I354
vmnic3  0000:00:14.3  igb     Up            Down             0  Half    00:25:90:82:9a:fb  1500  Intel Corporation Ethernet Connection I354


Ausgabe: lspci -v |less

Code: Alles auswählen

0000:00:00.0 Host bridge Bridge: Intel Corporation Avoton SSA-Cunit
    Class 0600: 8086:1f08

0000:00:01.0 PCI bridge Bridge: Intel Corporation Avoton PCIe Root Port 1 [PCIe RP[0000:00:01.0]]
    Class 0604: 8086:1f10

0000:00:02.0 PCI bridge Bridge: Intel Corporation Avoton PCIe Root Port 2 [PCIe RP[0000:00:02.0]]
    Class 0604: 8086:1f11

0000:00:03.0 PCI bridge Bridge: Intel Corporation Avoton PCIe Root Port 3 [PCIe RP[0000:00:03.0]]
    Class 0604: 8086:1f12

0000:00:0b.0 Co-processor Processor: Intel Corporation Avoton nCPM
    Class 0b40: 8086:1f18

0000:00:0e.0 Host bridge Bridge: Intel Corporation Avoton RAS
    Class 0600: 8086:1f14

0000:00:0f.0 IOMMU Generic system peripheral: Intel Corporation Avoton RCEC [PCIe EC[0000:00:0f.0]]
    Class 0806: 8086:1f16

0000:00:13.0 System peripheral Generic system peripheral: Intel Corporation Avoton SMBus 2.0
    Class 0880: 8086:1f15

0000:00:14.0 Ethernet controller Network controller: Intel Corporation Ethernet Connection I354  [vmnic0]
    Class 0200: 8086:1f41

0000:00:14.1 Ethernet controller Network controller: Intel Corporation Ethernet Connection I354  [vmnic1]
    Class 0200: 8086:1f41

0000:00:14.2 Ethernet controller Network controller: Intel Corporation Ethernet Connection I354  [vmnic2]
    Class 0200: 8086:1f41

0000:00:14.3 Ethernet controller Network controller: Intel Corporation Ethernet Connection I354  [vmnic3]
    Class 0200: 8086:1f41

0000:00:16.0 USB controller Serial bus controller: Intel Corporation Avoton USB Enhanced Host Controller
    Class 0c03: 8086:1f2c

0000:00:17.0 SATA controller Mass storage controller: Intel Corporation Avoton AHCI Controller [vmhba0]
    Class 0106: 8086:1f22

0000:00:18.0 SATA controller Mass storage controller: Intel Corporation Avoton AHCI Controller [vmhba1]
    Class 0106: 8086:1f32

0000:00:1f.0 ISA bridge Bridge: Intel Corporation Avoton PCU
    Class 0601: 8086:1f38

0000:00:1f.3 SMBus Serial bus controller: Intel Corporation Avoton PCU SMBus
    Class 0c05: 8086:1f3c

0000:01:00.0 PCI bridge Bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge
    Class 0604: 1a03:1150

0000:02:00.0 VGA compatible controller Display controller: ASPEED Technology, Inc. ASPEED Graphics Family
    Class 0300: 1a03:2000

0000:03:00.0 USB controller Serial bus controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller
    Class 0c03: 1912:0014

0000:04:00.0 Ethernet controller Network controller: Intel Corporation 82580 Gigabit Network Connection [vmnic4]
    Class 0200: 8086:150e

0000:04:00.1 Ethernet controller Network controller: Intel Corporation 82580 Gigabit Network Connection [vmnic5]
    Class 0200: 8086:150e

0000:04:00.2 Ethernet controller Network controller: Intel Corporation 82580 Gigabit Network Connection [vmnic6]
    Class 0200: 8086:150e

0000:04:00.3 Ethernet controller Network controller: Intel Corporation 82580 Gigabit Network Connection [vmnic7]
    Class 0200: 8086:150e


Ausgabe esxcli software vib list | grep net-igb

Code: Alles auswählen

net-igb                        5.2.5-1OEM.550.0.0.1331820            Intel   VMwareCertified   2015-07-25


Aktuell steh ich auf dem Schlauch und bin für jegliche Hilfe dankbar.

[~thc]

Sieht das Fehlerbild mit dem Inbox-igb-Treiber von 6.0 gleich aus?

[marco80]

Mit den inbox-Treibern identisches Bild.

[Dayworker]

Was mir auffällt, ist dein NIC-Link. Du sprichst die "Intel Corporation 82580 Gigabit Network Connection" an und hast aber eine i340-T4 verbaut. Daher stimmen auch die VID/DID-Werte nicht. Unabhängig davon werden alle NICs durch den 5.2.5er Treiber unterstützt.

Was sagt denn das "vmkernel.log" dazu?

[JustMe]

Hast Du die Karte auch mal in einem anderen Rechner (z.B. vSphere-zertifiziert) ausprobiert?

Ich befuerchte, dass das eher der Avoton-Chipsatz ist auf Deinem MB, der hier Ursache spielen koennte...

Als PCI-Device werden die Ports erkannt, sogar vmnic# zugewiesen.

Hast Du auch mal in der boot.gz u/o syslog.log (oder so...) geschaut, was der Treiber bei der Initialisierung so zum Besten gibt?

PS:
8086:150e wird auch in der HCL gelistet, mit Treiber igb 5.2.5. Gibt's z.B. bei FTS als "I350-T4", und wird in ESXi ebenfalls mit Text "...82850 Gigabit..." gelistet (auf unterstuetzter Server-Hardware, selbstverstaendlich...)

[kastlr]

Hallo,

laut lspci -v|less handelt es sich um eine Intel Netzwerkkarte mit der DID 1f41, dein Link verweist jedoch auf eine Karte mit der DID 1510.

Wenn ich explizit nach der Kombination VID:DID (8086:1f41) suche, liefert VMware folgendes Ergebnis.
Intel(R) Ethernet Connection I354

Der aktuellste Treiber liegt hier zum Download bereit.
Download VMware ESXi 5.5 igb 5.3.0 NIC Driver for Intel Ethernet Controllers 82580, I210, I350, and I354

Vielleicht probierst du es mal mit ihm.

Gruß,
Ralf

[Dayworker]

Sein Avoton-MB sieht mir nach http://www.supermicro.com/support/resources/OS/Atom_X10.cfm aus und das ist bisher nur für 5.5 U1/U2 freigegeben.

[Dayworker]

@kastlr
Das Problem ist nicht die "Intel(R) Ethernet Connection I354" sondern die unter "Intel Corporation 82580 Gigabit Network Connection 8086:150e" gelistete und der von dir verlinkte Treiber (5.2.5) paßt anscheinend auf alle Karten.

[marco80]

Hallo zusammen,

erstmal besten Dank für die vielen konstruktiven Anregungen. Habe den ESXi nochmals aufgesetzt um sauber die Inbox-igb-Treiber zu verwenden.

Zur Hardware:

es handelt sich um ein Supermicro 5018A-FTN4 - dieser ist nicht VMware zertifiziert. Wollte es dennoch versuchen. Andere Hardware habe ich aktuell nicht am Start.

syslog.log:
http://pastebin.com/jubYmqvT

vmkernel.log:
http://pastebin.com/pyHWQw5m

vmkwarning.log:
http://pastebin.com/F8r176Ni

Im vmkwarning log sind mir folgende Zeilen aufgefallen die die I340 betreffen.

Code: Alles auswählen

2015-07-25T18:32:39.578Z cpu0:33143)WARNING: vmklinux: pci_announce_device:1486: PCI: driver igb probe failed for device 0000:04:00.0
2015-07-25T18:32:39.648Z cpu0:33143)WARNING: vmklinux: pci_announce_device:1486: PCI: driver igb probe failed for device 0000:04:00.1
2015-07-25T18:32:39.717Z cpu0:33143)WARNING: vmklinux: pci_announce_device:1486: PCI: driver igb probe failed for device 0000:04:00.2
2015-07-25T18:32:39.785Z cpu0:33143)WARNING: vmklinux: pci_announce_device:1486: PCI: driver igb probe failed for device 0000:04:00.3


und falls es keine Möglichkeit mit VMware gibt muss ich halt weiter gucken für eine Alternative.

Grüsse Marco

[JustMe]

Boote Dein System doch mal mit einer Linux-Live-CD (oder auch mit einem Windows 7/8/...-Stick), und schau, ob die Karte dort korrekt initialisiert wird.

Ich wage jetzt einfach mal die ketzerische Behauptung: Das wird auch dort nicht gehen.

Wenn ich schon 8 LAN-Ports brauche, muss es ja nicht unbedingt ein Atom-Chipsatz sein...[/b]

[marco80]

Die Karte funktioniert unter Windows Server 2012R2 einwandfrei.

[OT]
Für den Kauf des Atom Systems sprach der Energieverbrauch von 30W. Mit der zusätzlichen Netzwerkkarte sowie den beiden HDD's komme ich auf einen Energieaufwand von rund 50W.

Mittels Hyper-V wurden 3 Firewalls (jeweils physisch und logisch getrennte LAN) sowie der Windows Server als PDC konfiguriert. Die Performance reichte vollkommen aus (CPU Last unter 10%). Jedoch verwunderte es mich stark, als ich die Firewall vor dem Load Balancing Router ausschaltete und trotzdem noch Internet Zugriff hatte. - Weswegen ich lieber auf Hyper-V verzichten möchte.
[/OT]

[Dayworker]

@JustMe
Deine Einschätzung zwecks Atom-Chipsatz hatte ich mal geteilt. Dann bin ich auf Paul "TinkerTry" Braren und sein Posting https://tinkertry.com/mini-tower-superserver gestossen. Die kleinen Atom-Dingens sind native Octacores und sprechen mal eben 64GB bzw sogar 128GB bei "TinkerTry" an. Wenn ich mir bei Paul die CPU-Vergleichsliste ansehe, versägt dieser kleine Prozzi selbst einen Intel E5-1000/2000 und verbraucht gerade mal ~50W.



[Edit]
Schreibe vom Mobile und unsere Postings haben sich überschnitten.

[Dayworker]

@marco80
Das System finde ich - wie bereits geschrieben - genial und die von Haus aus verbaute Quad-NIC läuft auch. Ist nur ärgerlich, daß du jetzt keine Redundanz über die zweite NIC aufbauen kannst. Aber mit 4 Ports könnte es dich schlechter treffen.

[marco80]

@Dayworker

klar könnte es schlimmer sein - nur brauche ich um mein Konzept durchzubringen 7 voneinander getrennte LAN Ports. 5 sind in der abgespeckten Variante das absolute minimum. und ob es dann läuft, selbst wenn ich die I340 durch eine andere Quad-LAN ersetze bleibt die Frage ob diese unter VMware läuft.

Diese Frage kann ich nur klären in dem ich die Ursache finde. Wollte zu dem Zweck mal den ESXi 5 oder 5.5 installieren - zur Zeit kriege ich nur die VMware Wartungsseite.

Soviel dazu im Moment - ausser jemand hat noch eine ander Idee woran es liegen könnte.

[Dayworker]

Ausgehend von den VMTN-Threads Vsphere 5.5 won't see my certified NIC. und Intel I350-T4 only recognized by Esx 5.5, not by 5.5 U2 scheint es von entscheidender Bedeutung zu sein, ob die zum Treiber passende Firmware an Bord ist.


Dazu würde in meinen Augen folgendes passen:

2015-07-25T18:32:39.508Z cpu0:33143)module heap vmklnx_igb: creation succeeded. id = 0x430440add000
2015-07-25T18:32:39.509Z cpu0:33143)<6>Intel(R) Gigabit Ethernet Network Driver - version 5.0.5.1
2015-07-25T18:32:39.509Z cpu0:33143)<6>Copyright (c) 2007-2013 Intel Corporation.
2015-07-25T18:32:39.509Z cpu0:33143)PCI: driver igb is looking for devices
2015-07-25T18:32:39.509Z cpu0:33143)DMA: 646: DMA Engine 'vmklnxpci-0:4:0.0' created using mapper 'DMANull'.
2015-07-25T18:32:39.509Z cpu0:33143)DMA: 646: DMA Engine 'vmklnxpci-0:4:0.0' created using mapper 'DMANull'.
2015-07-25T18:32:39.509Z cpu0:33143)DMA: 646: DMA Engine 'vmklnxpci-0:4:0.0' created using mapper 'DMANull'.
2015-07-25T18:32:39.509Z cpu0:33143)DMA: 691: DMA Engine 'vmklnxpci-0:4:0.0' destroyed.
2015-07-25T18:32:39.509Z cpu0:33143)IntrCookie: 3494: cookie 0x13 vector 0x70
2015-07-25T18:32:39.509Z cpu0:33143)IntrCookie: 3494: cookie 0x14 vector 0x71
2015-07-25T18:32:39.509Z cpu0:33143)VMK_PCI: 740: device 0000:04:00.0 allocated 2 MSIX interrupts
2015-07-25T18:32:39.509Z cpu0:33143)MSIX enabled for dev 0000:04:00.0
2015-07-25T18:32:39.509Z cpu0:33143)CpuSched: 592: user latency of 33144 netpoll-backup 0 changed by 33143 vmkeventd -6
2015-07-25T18:32:39.556Z cpu0:33143)<3>igb 0000:04:00.0: The NVM Checksum Is Not Valid
2015-07-25T18:32:39.578Z cpu0:33143)Disabling MSIX for dev 0000:04:00.0
2015-07-25T18:32:39.578Z cpu0:33143)VMK_PCI: 740: device 0000:04:00.0 allocated 1 INTx interrupt
2015-07-25T18:32:39.578Z cpu0:33143)WARNING: vmklinux: pci_announce_device:1486: PCI: driver igb probe failed for device 0000:04:00.0
2015-07-25T18:32:39.578Z cpu0:33143)LinPCI: LinuxPCI_DeviceUnclaimed:257: Device 0000:04:00.0 unclaimed.
2015-07-25T18:32:39.578Z cpu0:33143)DMA: 646: DMA Engine 'vmklnxpci-0:4:0.1' created using mapper 'DMANull'.
2015-07-25T18:32:39.578Z cpu0:33143)DMA: 646: DMA Engine 'vmklnxpci-0:4:0.1' created using mapper 'DMANull'.
2015-07-25T18:32:39.578Z cpu0:33143)DMA: 646: DMA Engine 'vmklnxpci-0:4:0.1' created using mapper 'DMANull'.
2015-07-25T18:32:39.578Z cpu0:33143)DMA: 691: DMA Engine 'vmklnxpci-0:4:0.1' destroyed.

[marco80]

So habe die Firmware der NIC aktualisiert - und voilà es läuft.

Besten Dank an alle Helfer.

[Dayworker]

0:00:00:05.311 cpu0:32768)PCI: 1109: 0000:04:00.3 8086:150e 8086:12a2 added

SVID: 8086 SSID: 12a2 bedeutet Brand Name: IBM Ist das eine OEM-Karte?

SVID: 0000 SSID: 0000 bedeutet Brand Name: Intel



[add]
Eine Übersicht über alle $Vendor dieser NIC siehe auch i340-T4.

[marco80]

ist ne original intel bulk. interessant...

[JustMe]

2015-07-25T18:32:39.556Z cpu0:33143)<3>igb 0000:04:00.0: The NVM Checksum Is Not Valid

Ach Du gerechter...

Wenn ich das lese, schrillen mir wieder saemtliche Alarmsirenen.
Erinnert sich noch jemand an ESX/i 3.5u2, und ein paar Linux-Versionen, deren Intel-Treiber die Checksum prueften, obwohl die Karte nicht fuer's Booten benutzt wurde?
Problem gab's unter Windows nicht, weil dessen Treiber einfach die Pruefsumme nicht checkte.
Bei den damaligen Karten gab's das Problem, dass deren Firmware mit bestimmten Abfragen nicht klarkam, und sich mal eben genau diese eigene Firmware zerschoss. Beim naechsten Boot des ESXi (ggfs. Monate spaeter) waren dann alle (oder viele) NICs weg...

Hoffentlich haben die da bei Intel sich nicht wieder so einen Mist eingebaut, und es handelt sich "nur" um einen Exemplarfehler. Den "Bug" im Treiber haben sie ja offensichtlich noch...

PS:
Es laege mir fern, irgendjemandes Hardware grundsaetzlich zu verdammen. Aber auch, wenn die neuesten Atoms "kraftvoll" daherkommen, und neuere wahrscheinlich noch besser werden, ist es immer sinnvoll, das Gesamtsystem zu betrachten. Wenn man persoenlich damit gluecklich wird: bitte sehr...

[Dayworker]

Wenn ich mir seinen Server unter http://www.supermicro.com/products/system/1u/5018/sys-5018a-ftn4.cfm mal genauer ansehe, kommt dort das MB namens "A1SRi-2758F" zum Einsatz und dieses ist laut http://www.supermicro.com/support/resources/OS/Atom_X10.cfm nicht für den ESXi freigegeben. Selbst für die wenigen für den ESXi freigegebenen MBs wird dort nur 5.5 U1 und U2 genannt. Vom 6er ist dort keine Rede.

Unabhängig davon würde er dieses nervige Problem überhaupt nicht bemerkt haben, wenn er mit der im Chipsatz enthaltenen Quadport-NIC ausgekommen wäre oder irgendeine andere Intel-NIC verbaut hätte. Da das NIC-Problem ja nach einem FW-Update beseitigt war, dürfte es zu keinen weiteren Problemen von dieser Seite kommen. Das Intel sich da wieder mal selbst das Bein stellt, ist leider auch nichts wirklich neues. Manche dieser Bugs muß man vielleicht einfach nur als Feature einordnen und abheften.

[JustMe]

Ich sach ma: toitoitoi...

Das Problem damals war ja, dass die Karte an sich beim Boot des ESX/i ja noch ok war, aber waehrend der Laufzeit dann durch HW-Status-Abfragen so durcheinander geriet, dass sie sich selbst ihr NVM ueberschrieb. Dadurch lief die Karte genau so lange weiter, bis das System gebootet wurde. Bei diesem Boot schlug dann der Treiber(-fehler) zu, der (unnoetigerweise) die Pruefsumme pruefte, und den Dienst verweigerte...

Damals konnte man auch die Firmware flashen (so oft man eben wollte...), und wieder genau 1x booten. (Oder eben auch testweise zig-mal, solange der Ueberschreiber nicht auftrat.)

[irix]

Ich kenne was aehnliches und wollte es gestern auch schreiben aber Zeitmangel war das Problem.

Der Kunde hatte Proliants welche vor 1.5 Jahren noch unter ESX 4.1 liefen und der Wechsel auf 10GbE stand aber an. Gesagt getan und das Systemhaus mit dem gruenen B lieferte HP Karten. Ueber die HCL gesehen das es neuere Async Treiber gab und ihm Zuge von ESXi Patching hatten wie die schon mal mit einspielt um Spaeter nur noch die Hardware einstecken zumuessen.

Gesagt getan und am Ende des Tags gabs keine vmnic und wie bei dir auch zeigt aber lspci das es die Karten sieht. Da an jedem Standort andere Prolients standen gabs natuerlich unterschiedliche HP NICs und mit den QLogics gab es keine Probleme.

PCI und Vendor IDs geprueft und genau die welche auf der HCL stehen sind auch geliefert worden. Das gruene B liefert noch eine Ersatzkarte aber so Fragen zur Problematik blieben unbeantwortet. Die Frage ob die Karte aus dem selben Karton kommt erbrachte auch nur ein Schulter zucken.

Natuerlich hat die Ersatzkarte das gleiche "Problem" gezeigt.

Aber wozu hat mann denn HP und VMware Support? Na bis man HP klar gemacht hat was man fuer ein Problem hat und die gleich mit dem Finger auf VMware zeigten war VMware der Meinung wir sollten doch einfach mal jeden Patchstand durchtesten. Ich kann sagen das die NetextremeI+II eine Menge Updates hatten fuer ESX 4.1 und wenn wir den Host noch 2x mehr bebootet haetten waere der bestimmt implodiert. Mal davon abgesehen das wenn man auf Fortschrittsbalken schaut es einem ja auch immer doppelt solange vorkommt.

Wie auch immer konnte der VMware Support aus den Logs ermitteln das der Host die NICs sieht beim starten und versucht auch den Treiber zu initialsieren aber da kam dann nix mehr zurueck. Die interne FehlerDB des Supports enthielt Eintrage das FW Probleme existieren koennten.

Ein Durchlauf mit einer damals aktuellen Smartstart CD erbrachte aber auch nix und auch das einbauen von aktuellen Treibern in so eine CD scheitere mangels Wissen von mir und dem Kunden.

Tja.... guckte man sich die HP Supportseite auf Deutsch an so war auch nicht viel zu erkennen fuer ESX. Aber wenn man dem Browser sagte das man doch eher Englisch bevorzuge so konnte man erkennen das sie ein FW Flashtool fuer die NICs anbieten was auch unter ESX tut.

Gesagt getan und beim Auslesen der FW Staende konnte man sehen das jeder Port der Karte aus 3 unterschiedlichen Komponenten besteht aber Teils Version 0.0 ausgewiesen wurde und das der 2. Port der Karte andere oder keine FW Versionen hatte. Mittels "Force" konnte man dann den aktuellen Stand ueberschreiben bzw. hinterher hatte alle Komponenten eine FW Version in der Anzeige.

Nach dem Neustart vom ESX waren dann natuerlich auch beide VMNICs sichtbar.

Merke:
- Gucke dir immer die engl. Version eine Website an
- Nur weil etwas "neu" geliefert wird muss es nicht funktionieren
- HCL und gereifte Version schuetzt nicht vor neuen Erfahrungen

Gruss
Joerg