Intel e1000 (Riverbed) - no link

Sziasztok,

Egy érdekes problémába sikerült bele futni, adott egy "Riverbed Steelhead 2050M Series 1UABA WAN Accelerator", ez tulajdonképpen egy 1U házba csomagolt Tyan alaplap 2+4 integrált Intel LAN-al.

Ezt szeretnénk teljesen másra használni mint amire a gyártó kitalálta :D
Mivel van rajta 6db Gigabites LAN idális tűzfalnak. (e54xx CPU, 8GB RAM, 4xSATA HDD)

Mi Open v. FreeBSD-t szeretnénk rá rakni, de sajnos a következő érdekes problémát produkálja:
adott 6 db LAN:
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
09:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

Ezekből 2 (82574L) teljesen tökéletesen mükődik.
Viszont a másik 4 (82571EB), látszik, configolható, bármit csinálhatok vele, csak linket nem veszi fel.
Olyan szinten nem, hogy bedugott UTP kábelnél linket jelző led nem világit.

Mivel ezen a hardwaren hivatalosan Linux alapú RIOS fut, most linux-al próbálkozunk, biztos hogy valamilyen flag-et kéne csak átbillenteni hogy menjen.

Van valakinek esetlegesen valamilyen 5lete, mit nézzünk meg ?

Pár infó:

root@debian:~# ethtool -k eth2
Features for eth2:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-unneeded: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]

root@debian:~# ethtool -i eth2
driver: e1000e
version: 1.5.1-k
firmware-version: 5.11-2
bus-info: 0000:09:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

root@debian:~# lshw -C network
*-network:0
description: Ethernet interface
product: 82571EB Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:0a:00.0
logical name: eth6
version: 06
serial: 00:0e:b6:98:5a:dd
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.5.1-k firmware=5.11-2 ip=192.168.1.1 latency=0 link=no multicast=yes port=twisted pair
resources: irq:49 memory:fde80000-fde9ffff memory:fde60000-fde7ffff ioport:d880(size=32) memory:fde40000-fde5ffff
*-network:1 DISABLED
description: Ethernet interface
product: 82571EB Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:0a:00.1
logical name: eth1
version: 06
serial: 00:0e:b6:98:5a:dc
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.5.1-k firmware=5.11-2 latency=0 link=no multicast=yes port=twisted pair
resources: irq:51 memory:fdee0000-fdefffff memory:fdec0000-fdedffff ioport:dc00(size=32) memory:fdea0000-fdebffff
*-network:0 DISABLED
description: Ethernet interface
product: 82571EB Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:09:00.0
logical name: eth2
version: 06
serial: 00:0e:b6:98:5a:db
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.5.1-k firmware=5.11-2 latency=0 link=no multicast=yes port=twisted pair
resources: irq:52 memory:fdc80000-fdc9ffff memory:fdc60000-fdc7ffff ioport:c880(size=32) memory:fdc40000-fdc5ffff
*-network:1 DISABLED
description: Ethernet interface
product: 82571EB Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:09:00.1
logical name: eth3
version: 06
serial: 00:0e:b6:98:5a:da
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.5.1-k firmware=5.11-2 latency=0 link=no multicast=yes port=twisted pair
resources: irq:53 memory:fdce0000-fdcfffff memory:fdcc0000-fdcdffff ioport:cc00(size=32) memory:fdca0000-fdcbffff
*-network DISABLED
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth4
version: 00
serial: 00:0e:b6:43:76:99
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.5.1-k firmware=1.8-0 latency=0 link=no multicast=yes port=twisted pair
resources: irq:16 memory:f99e0000-f99fffff ioport:bc00(size=32) memory:f99dc000-f99dffff
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:02:00.0
logical name: eth5
version: 00
serial: 00:0e:b6:43:76:98
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.5.1-k duplex=full firmware=1.8-0 ip=10.0.100.179 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:17 memory:f98e0000-f98fffff ioport:ac00(size=32) memory:f98dc000-f98dffff

Hozzászólások

Bocs, ha triviális, de én a BIOS-ban nézném meg, hogy nincs-e hardver-esen kikapcsolva? Olyan kill_switch szaga van a dolognak.
Az eredeti OS-be belépnék konzol-on és ott próbálnám nézni a hálókártyák status-at, meg hogy a boot során hogyan inicializálja őket esetleg.
Gondolom Google a megfelelő Tyan alaplapra már megvolt.
Nem lehet, hogy valami speciális firmware-t használ a gyártó a Tyan alaplaphoz? Mert akkor rá kell dobni a hivatalos firmware-t, hátha azzal jól viselkedik.

Egy vicces megjegyzés: RIOS fut a prohardver lapcsaládnál is...

Végezetül egy kérdés: mi a jó fenét csinál ez az eszköz? Mert a gyártó oldalán nem tudtam túl sokat kigobozni... Olyan misztikusnak tűnik. Tekintsünk el az egyszerű cache-eléstől. Tényleg tudná úgy optimalizálni a csomagok útvonalát, hogy az érezhetően jobb legyen? Miközben beiktat egy olyan eszközt, ami biztosan belevisz valamennyi késleltetést...

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Hozzánk már OS nélkül jött, RIOS-t meg csak úgy nem lehet letölteni :) - igy ezzel kipróbálni sajnos nem tudjuk.

Hivatalosan ilyan Tyan lap nincsen, igy bios/firmware/etc ... sincsen hozzá.
BIOS-ban természetesen nincsen kikapcsolva, hiszen ha ki lenne semmilyen OS sem látná.

Éppen ez az érdekes, minden kártya specifikus (intel e1000) beállítást, etc megy, csak Link-et nem veszi fel.

Valami kill_switch szerű dologra gondolok még, mint wireless hálókártyáknál.
Bár ahhoz meg driver szinten kéne támogatás. Ha írt hozzá a gyártó valamit, akkor annak nyíltnak kéne lenni elvileg...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Probaljatok ra a FreeBSD 9.2 aktualis rc-jet es kiderul az igazsag. Az is lehet, hogy regi a debian kernel es siman nem szereti a kartyat meg.

FreeBSD 9.x menne rá ha menne, 9.1-el próbáltuk már, sajnos ott sem megy.
Ugyan ez a helyzet OpenBSD 5.3-al is.

Linux-ból Wheezy-vel próbáltam, kicsit több infót lehet kinyerni mint BSD-ben a kártyából, de itt sem megy.

Elvileg ez 2 db 2 portos Intel Gigabit kártya, egymás mellett vannak szépen a lapon, a legfurcsább az hogy kártyák 99% linket azért felveszi ha dugok bele egy kábelt, ezeknél link led "néma" marad. Ebből gondolnám hogy valami módon maga a port van tiltva, mert a hálókártyák azok mennek.

Próbáld meg pci=nomsi kernel paraméterrel indítva.

Szerintem driver vagy firmware probléma lesz a háttérben.

Nem is olyan rég egy Netgear router-re telepítettem Openwrt-t, ahol a gyárilag beépített NPE-B firmware hibája miatt nem működött a VLAN-ok kezelése. Miután manuálisan újrafordítottam a mikrokódot VLAN támogatás nélkül, a probléma rögvest megoldódott.

Esetleg próbáld meg felrakni az intel-féle drivereket, egész frissnek tűnnek, hátha ezekkel működni fog:

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17509&l…
https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=15817&l…

Visszagondolva a 3.8.0 és 3.8.3 között például olyan patch-ek kerültek be az e1000e driver-be, hogy a laptopomon megszűnt működni az integrált hálókártya. Elvesztette a carrier-t és utána csak az újraindítás segített. De amint forgalmazni kezdett, egyből megint megmakkant. Még a DHCP címig sem jutott el.
http://gentoo.2317880.n4.nabble.com/e1000e-integrated-laptop-NIC-loses-…

A hibajelenséget az alábbi három patch orvosolta végül:
https://lkml.org/lkml/2013/5/9/546
https://lkml.org/lkml/2013/5/9/548
https://lkml.org/lkml/2013/5/9/642

Nem azt mondom, hogy neked ugyanez a bajod, mert nálam azért égtek a LED-ek. Bár a carrier elvesztésénél az egyik elaludt. Viszont akár power-management-tel kapcsolatos dolgok is betarthatnak a hálókártyáknak.

Kipróbálnám egy 3.10-es, friss kernellel is a helyedben.
Bár sajnos az elég rossz jel, hogy FreeBSD-vel se megy...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Könnyen lehet...

Kicsit off, de azért érdekességképp leírom: nekünk is van egy Riverbedünk, amit aktívan használunk a céges hálózaton. Egyszer egy pár órás nem tervezett áramszünet után összeszakadt az eszköz root fájlrendszere, és emiatt folyton újraindítgatta magát. Természetesen szünetmentesen tápon van, de mivel nincs hozzá UPS agent, nem tudtuk szabályosan leállítani időben, ezért a fájlrendszere megsérült. Ezek után semmilyen recovery üzemmódban nem volt hajlandó elindulni, se nekem, se a hivatalos support-nak nem sikerült életet lehelni belé. Végül az lett a megoldás, hogy a konzolportján keresztül újrahúzták az egész rendszert... ez mondjuk már zökkenőmentesen ment, azóta nem is volt gondunk vele, de azért elég ijesztő, hogy egy szimpla áramszünet így padlóra tud küldeni egy 1000 dolláros eszközt...

Bár a statisztikák tanúsága szerint szépen teszi a dolgát, ebből mi abszolút semmit nem észlelünk a gyakorlatban pl. webes forgalomnál. Lehet, hogy csak azért, mert eleve használunk proxy-t a belső hálózaton, ami cache-el, de más (optimalizált) forgalmaknál sem tapasztalunk érezhető gyorsulást.

A statisztikákra rápillantva azt látom, hogy most átlagosan 2,44X-os optimalizálással dolgozik, ami elvileg azt jelentené, hogy a netkapcsolatunk sávszélességét több mint duplájára kellene emelnie. Ebből persze semmit nem érzünk, egy normál HTTP-s fájlletöltés így sem igazán lépi túl a netkapcsolatunk sávszélességét.

Még egy ide kapcsolódó érdekesség (ha már így elkanyarodtunk az eredeti témától): a fájlszerverünket (amit éppen cserélni szeretnénk, mert kinőttük) a kinti IT vezetés ki akarja váltani egy távoli adatközpontban futó Riverbed+Netapp kombóval. Ez nagy érvágás lenne nekünk, mivel az eddigi tesztek alapján csak a már feltöltött fájloknál lehet érezhető teljesítményjavulást elérni a Riverbed-en keresztül. Ez annyit jelent, hogy a tesztünk során kb. 20 MByte/sec-ig tudott növekedni a letöltési sebesség, amikor egy korábban feltöltött távoli fájlt átmásoltunk egy helyi gépre (a netkapcsolatunk 7 MByte/sec-et bír el, vagyis ebben az esetben tényleg jelentősen javult a sebesség). Ez sajnos a mostani, dedikált gigabites sávszélességhez képest édeskevés, pláne, hogy a teszt során csak egy szálon tudtunk stabilan és elfogadható sebességgel adatot mozgatni (ez mondjuk lehet konfigurációs probléma is, gyanús hogy van valahol egy NAT, ami a tapasztalataim alapján könnyen meg tudja akasztani a CIFS-kapcsolatokat)...

Azt hiszem erre több időt nem érdemes vesztegetni, nagy valószínűséggel itt valamilyen hardware-es tiltás van.

A 2 db 82574L szépen rendben megy.
A 4 db 82571EB (2x 2db) viszont semmilyen módon nem indul el.

Mivel több ilyet is vettünk, HW hibát kizárandó kipróbáltunk egy másikat is, a helyzet ott is ugyan ez.

Lehet hogy egy Windows-t még rápróbálok kiváncsiság képen.

Margó szélére:

Került a gépbe egy 4 portos Intel kártya, ugyan úgy Intel 82571EB, ezt minden OS szépen látja.

Ergó, innentől teljesen biztos hogy alaplapon lévő 2+2 portos kártyán valamilyen HW tiltás van :(

OpenBSD alatt:
em0 at pci1 dev 0 function 0 "Intel PRO/1000 PT (82571EB)" rev 0x06: apic 4 int 16, address 00:0e:b6:92:2e:b1
em1 at pci1 dev 0 function 1 "Intel PRO/1000 PT (82571EB)" rev 0x06: apic 4 int 17, address 00:0e:b6:92:2e:b0
em2 at pci2 dev 0 function 0 "Intel PRO/1000 PT (82571EB)" rev 0x06: apic 4 int 16, address 00:0e:b6:92:2e:af
em3 at pci2 dev 0 function 1 "Intel PRO/1000 PT (82571EB)" rev 0x06: apic 4 int 17, address 00:0e:b6:92:2e:ae
em4 at pci7 dev 0 function 0 "Intel PRO/1000 QP (82571EB)" rev 0x06: apic 4 int 16, address 00:15:17:2d:75:f8
em5 at pci7 dev 0 function 1 "Intel PRO/1000 QP (82571EB)" rev 0x06: apic 4 int 17, address 00:15:17:2d:75:f9
em6 at pci8 dev 0 function 0 "Intel PRO/1000 QP (82571EB)" rev 0x06: apic 4 int 17, address 00:15:17:2d:75:fa
em7 at pci8 dev 0 function 1 "Intel PRO/1000 QP (82571EB)" rev 0x06: apic 4 int 18, address 00:15:17:2d:75:fb
em8 at pci11 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi, address 00:0e:b6:45:bd:c1
em9 at pci12 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi, address 00:0e:b6:45:bd:c0

em0-3 alaplapi 2+2 portos kártya - No Link
em4-7 pciex 4 portos intel kártya - Link ok
em8-9 alaplapi dual kártya - link ok