Broadcom NetXtreme BCM5721 Gigabit Ethernet PCI Express

Hálózati eszközök

Üdvözlet!

Van egy HP szerverünkben egy
0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)
kártya. Egy ideje ezek vannak a logban:
Sep 5 10:26:21 ns2 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Sep 5 10:26:21 ns2 kernel: tg3: eth0: Link is down.
Sep 5 10:26:25 ns2 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Sep 5 10:26:25 ns2 kernel: tg3: eth0: Flow control is off for TX and off for RX.
Sep 5 10:37:45 ns2 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Sep 5 10:37:45 ns2 kernel: tg3: eth0: Link is down.
Sep 5 10:37:48 ns2 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Sep 5 10:37:48 ns2 kernel: tg3: eth0: Flow control is off for TX and off for RX.

Nagyjából van sejtésem, hogy mit is jelent :) mert a gép ilyenkor "eltűnik" a hálózatról, nem érhető el. Majd mindenféle közbeavatkozás nélkül helyreáll a dolog. A gép a T-Com adatparkjában figyel. Lehetséges, hogy a switch portja rosszalkodik, amibe a szerverünk megy? Vagy mi okozhat ilyet, mert korábban nem igen találkoztam a jelenséggel.
A kernel:
2.6.17.7 #1 SMP Wed Jul 26 10:28:41 CEST 2006 i686 GNU/Linux
Előre is köszönöm a segítséget!

Laci

  • 4068 megtekintés

( lacika v | 2006. 09. 05., k – 11:54 )

A googlin találtam, hogy driver probléma okozta másnál is ezt. Ahogy nézem a kernelt, a tg3 és a bnx2 is bele van fordítva a kernelbe, de a bnx2 -re írja azt, hogy az javasolt a NetXtreme kártyákhoz. Most fordul a legfrisebb kernel, a tg3 csak modulként lesz jelen és a bnx2 lesz fixen a kernelben. Majd délután hazafele be is ugrok az Adatparkba és nyomok egy rebootot az új kernelre, azt meglátjuk.

( lacika v | 2006. 09. 05., k – 21:24 )

Sorry! Jó sok hülyeséget írtam. Ez egy NetXtreme kártya, és nem NetXtremeII -es, így csak a tg3 driver jó hozzá. Frissítettem a 2.6.17.11 -re, de ahogy néztem a tg3 forráskódját a régebbi és az újabb kernelben, de nem volt verziószám változás. Majd kiderül...

( szimi (nem ellenőrzött) | 2006. 09. 06., sze – 08:28 )

Hat, az meg okozhatja szerintem, hogy ki van kapcsolva a switch portjan a portfasting. Ilyenkor lassabban jon fel a halozat, mert STP-vel probalkozik egy darabig (hu, de szakszeruen irtam). Gondolom Cisco switchek vannak, azok meg alapbol ilyenek. Ha nem ez a helyzet, akkor driver.

Nekem 5752-es kartya van FreeBSD-vel. Ott is ugyanez a helyzet azzal a kulonbseggel, hogy magat latja, de kifele meg befele nyista halozat.

( uid_4672 | 2006. 09. 06., sze – 10:17 )

blőd kérdés: nem a switchet húzta ki véletlenül a takarító néni a konnektorból? :D

( karfijol | 2006. 09. 13., sze – 00:59 )

Pont ugyanez kergetett sírba majdnem az elmúlt pár napban, dettó ez a NIC, ez a kernel, csak IBM serverben.
Én arra jutottam, hogy a TSO okozza, legalábbis mióta kikapcsoltam megszűnt a bug.
ethtool -K eth0 tso off