• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Netzwerk immer wieder down seit upgrade auf 12.0

pbtraveller

Well-Known Member
Themenstarter #1
Hi,

seit dem upgrade meines Servers auf 12.0 gehen die Netzwerkports (4x Intel Karte) eine Weile nach dem Neustart nicht mehr. Ich habe folgende Fehlermeldung im Logfile:

kernel: TX(1) desc avail = 1024, pidx = 0
kernel: igb0: TX(1) desc avail = 1024, pidx = 0

Meine Netzwerkkonfig in /etc/rc.conf sieht wie folgt aus:

cloned_interfaces="bridge0"
ifconfig_bridge0="inet 192.168.88.2/24 addm em0 addm igb0 addm igb1 addm igb2 addm igb3 up"
ifconfig_em0="up"
ifconfig_igb0="up"
ifconfig_igb1="up"
ifconfig_igb2="up"
ifconfig_igb3="up"


Kann mir jemand weiterhelfen?
Vielen Dank!

Cheers
pbtraveller
 

Crest

rm -rf /*
Mitarbeiter
#2
In FreeBSD 12.0 wurden der legacy em Treiber und der igb Treiber in einen neuen Treiber, der iflib verwendet zusammengeführt. Dabei wurde in guter alter Inteltradition mal wieder nur eine Untermenge der aktuellen Hardware getestet. Noch gibt es eine Version des alten Treibers als Port. Das Paket heisst intel-em-kmod.
 

bsd4me

Well-Known Member
#3
ja, das Problem habe/hatte ich auch in einem Supermicro Server. Nach der Installation von intel-em-kmod scheint alles wieder gut zu sein.
Grüße, Norbert
 

pbtraveller

Well-Known Member
Themenstarter #4
Hi,

habe die intel-em-kmod als paket installiert und über if_em_updated_load="YES" in /boot/loader.conf geladen. Leider bleibt das Problem bestehen. Ersetzt denn der intel-em-kmod den Standardtreibers und muss das Laden dieses Standardtreibers verhindern?

kldstat gibt mir sowohl if_igb.ko als auch if_em_updated.ko aus.

Vielen Dank und viele grüße
pbtraveller
 

mr44er

Well-Known Member
#5
Ersetzt denn der intel-em-kmod den Standardtreibers und muss das Laden dieses Standardtreibers verhindern?
Kann ich akut nicht beantworten. Um sicher zu gehen, kannst du einen Kernel ohne die Treiber bauen und dann den Eintrag in der loader.conf erstmal rausnehmen.

Interessant wäre dann auch dmesg, wenn du kldload if_em_updated absetzt.

Edit: https://forums.freebsd.org/threads/compile-and-load-a-newer-network-driver.69817/post-419349
-> Es sollte 'overriden'
 

bsd4me

Well-Known Member
#6
Hi, kldstat gibt mir sowohl if_igb.ko als auch if_em_updated.ko aus.
Nutzt Du denn auf den igb treiber? Bie mir sieht es auf dem Server nach dem if_em_kmod gut aus - läuft ohne Probleme... Hier die kldstat

# kldstat
Id Refs Address Size Name
1 34 0xffffffff80200000 243cd00 kernel
2 1 0xffffffff8263d000 68c38 if_em_updated.ko
3 1 0xffffffff826a6000 3a9a10 zfs.ko
4 2 0xffffffff82a50000 a4f0 opensolaris.ko
5 1 0xffffffff82c21000 490c linprocfs.ko
6 1 0xffffffff82c26000 2e28 linux_common.ko
7 1 0xffffffff82c29000 1800 uhid.ko
8 1 0xffffffff82c2b000 23a8 ums.ko
9 1 0xffffffff82c2e000 acf mac_ntpd.ko


Gruss, Norbert
 

mr44er

Well-Known Member
#7
Nutzt Du denn auf den igb treiber?
Ich musste auch 2x hingucken. Im ersten Post steht es, aber leicht übersehbar.
1x em, 4x igb :)

Wenn es bei dir so funktioniert, dann wird ein/das Kernelmodul wohl bevorzugt behandelt.
pciconf -lv spuckt ja die Treiberinfo aus, aber man kann nicht zwischen 'im Kernel' und Kernelmodul bzw. 'what's in use?' unterscheiden, oder? Den Fall hatte ich auch noch nicht und ich hab bis auf den Link im vorherigen Post nichts gefunden, was die Thematik behandelt.

Kann das jemand bestätigen oder genauer erklären? :)
 

pbtraveller

Well-Known Member
Themenstarter #8
Ich hatte zwischenzeitlich den alten Treiber daran gehindert zu laden, in dem ich if_igb.ko in if_igb.ko.blacklist umgenannt habe. Das hat leider nichts geändert. Nach einer Weile war die Netzwerkkarte wieder down.

/var/log/messages gibt mir folgendes aus:

Jul 4 20:35:36 Server kernel: igb0: link state changed to UP
Jul 4 20:35:36 Server kernel: igb0: link state changed to DOWN
Jul 4 20:35:37 Server kernel: igb0: TX(0) desc avail = 1024, pidx = 0
Jul 4 20:36:08 Server syslogd: last message repeated 18 times
Jul 4 20:37:53 Server syslogd: last message repeated 63 times
Jul 4 20:37:53 Server kernel: igb0: link state changed to UP
Jul 4 20:37:53 Server kernel: igb0: link state changed to DOWN
Jul 4 20:37:55 Server kernel: igb0: TX(0) desc avail = 1024, pidx = 0

Ich bereue das upgrade auf 12.0 echt. Was ein Mist! Hat jemand noch eine Idee was ich machen könnte?

Vielen Dank

pbtraveller
 

bsd4me

Well-Known Member
#11
Ich hatte zwischenzeitlich den alten Treiber daran gehindert zu laden, in dem ich if_igb.ko in if_igb.ko.blacklist umgenannt habe. Das hat leider nichts geändert. Nach einer Weile war die Netzwerkkarte wieder down.

Ich bereue das upgrade auf 12.0 echt. Was ein Mist! Hat jemand noch eine Idee was ich machen könnte?
das ist schade - ich habe zu Hause und 2 "Storage" Server auf meiner Arbeit unter 12.0 laufen - bis auf dieses dumme problem ohne Zwischenfälle. Ich kann dich gut verstehen - habe deswegen am "Vatertag" um 6:30 auf der Arbeit gesessen und den Server wieder neu gestartet, der danach wieder Probleme machte und nachher erstmal eine Rundmail geschrieben, dass er vorrübergehen nicht genutzt werden könne... Wenn mir was sinnvolles einfallen sollte, lass ich es wissen...

VG Norbert
 

pbtraveller

Well-Known Member
Themenstarter #13
Hallo zusammen,

ich habe mal per sysctl net.inet.tcp.tso=0 tso ausgeschaltet und auch noch die entsprechenden Einträge in /etc/sysctl aufgenommen. Leider hat das nichts geändert. Das logfile enthält die gleichen Einträge, und das Netzwerk ist down. Ich werde mir jetzt vorübergehend eine neue Netzwerkkarte mit einem anderen Chip besorgen. Leider läuft meine APU mit Intel-NICs unter 12.0 auch nicht wirklich rund.

Eine Erkenntnis bleibt (erneut). Bei FreeBSD erst auf das nächste Hauptrelease upgraden, wenn es ein zweites Release gibt, also erst ab 12.1. Das wird wohl nicht ausreichend getestet....

Meine APU werde ich jetzt wohl erst mal neu aufsetzen und dort ein 11.X verwenden.

Falls noch jemand etwas einfällt, bin ich ich dankbar, vielleicht gibt es ja doch noch eine Lösung...

VG pbtraveller
 

pbtraveller

Well-Known Member
Themenstarter #15
Ich habe jetzt folgende Einstellungen in /etc/rc.conf vorgenommen:

ifconfig_igb0="mtu 9000 -tco -lro -rxcsum -txcsum -txrtlmt up"
ifconfig_igb1="mtu 9000 -tco -lro -rxcsum -txcsum -txrtlmt up"
....

Die interfaces sind Bestandteile von bridge0, über die ich weitere Geräte (u.a. einen Drucker) ans Netzwerk angebunden habe.

Leider hat das Ganze nicht den gewünschten Erfolg.
Wenn ich den Drucker anlasse, der an einem der Netzwerkports hängt, scheint der Netzwerkport auch oben zu bleiben. Schalte ich den aber aus und nach 24 Std. wieder ein, kann er nicht mehr angesteuert werden, bis ich den Server, an dessen Netzwerkkarte der Drucker hängt, neugestartet wurde. Vermutlich braucht es ein Mindestmaß an Netzwerkverkehr auf dem Port, damit dieser nicht down ist.

Ich werden jetzt schauen, wie ich auf 11 zurückgehen kann. Was ein Mist!

BG pbtraveller
 

mr44er

Well-Known Member
#16
Ich habe mir eine Quad 82580 Gigabit Network Connection gegönnt, diese nutzt ebenfalls den igb.
Allerdings nutze ich die Karte mit bhyve und passthrough.

Habe nun ähnliche Probleme, bisher fiel es nur unter Last auf (zfs send über igb0). In der vm sehe ich dann, dass igb0 down geht, direkt danach wieder up. Sobald das eintritt, ist die komplette Verbindung weg, sogar ping bleibt tot. Nur ein Neustart der vm hilft.

Hatte zuerst Überhitzung vermutet, daher heute mal einen Lüfter montiert, der direkt auf die Rippen bläst. Danach die FW von 1.3.irgendwas auf 1.5.88 geflasht.

Wegen
https://forum.opnsense.org/index.php?topic=5511.msg28681#msg28681
+
https://www.thomas-krenn.com/de/wiki/OPNsense_igb_EEE_Funktion_deaktivieren
habe ich da nochmal geschaut.

Das powersaving-feature rennt wohl nicht so ideal, wie es sollte. Gelesen habe ich, dass es beim Umschalten der Modi zu den Hängern kommen kann. Auswirkungen vom Zusammenwerfen der Treiber?

https://www.freebsd.org/cgi/man.cgi?igb(4) ist ein wenig dünn hinsichtlich der tunables.

irq267: igb0:rxq0:87 @cpu0(domain0): 370
irq268: igb0:rxq1:89 @cpu1(domain0): 218
irq269: igb0:aq:91 @cpu0(domain0): 2
dev.igb.0.interrupts.rx_overrun: 0
dev.igb.0.interrupts.rx_desc_min_thresh: 0
dev.igb.0.interrupts.tx_queue_min_thresh: 337
dev.igb.0.interrupts.tx_queue_empty: 365
dev.igb.0.interrupts.tx_abs_timer: 0
dev.igb.0.interrupts.tx_pkt_timer: 0
dev.igb.0.interrupts.rx_abs_timer: 0
dev.igb.0.interrupts.rx_pkt_timer: 337
dev.igb.0.interrupts.asserts: 590
dev.igb.0.mac_stats.tso_ctx_fail: 0
dev.igb.0.mac_stats.tso_txd: 52
dev.igb.0.mac_stats.tx_frames_1024_1522: 237
dev.igb.0.mac_stats.tx_frames_512_1023: 24
dev.igb.0.mac_stats.tx_frames_256_511: 17
dev.igb.0.mac_stats.tx_frames_128_255: 2
dev.igb.0.mac_stats.tx_frames_65_127: 83
dev.igb.0.mac_stats.tx_frames_64: 2
dev.igb.0.mac_stats.mcast_pkts_txd: 0
dev.igb.0.mac_stats.bcast_pkts_txd: 0
dev.igb.0.mac_stats.good_pkts_txd: 365
dev.igb.0.mac_stats.total_pkts_txd: 365
dev.igb.0.mac_stats.good_octets_txd: 383923
dev.igb.0.mac_stats.good_octets_recvd: 76496
dev.igb.0.mac_stats.rx_frames_1024_1522: 0
dev.igb.0.mac_stats.rx_frames_512_1023: 17
dev.igb.0.mac_stats.rx_frames_256_511: 155
dev.igb.0.mac_stats.rx_frames_128_255: 0
dev.igb.0.mac_stats.rx_frames_65_127: 152
dev.igb.0.mac_stats.rx_frames_64: 13
dev.igb.0.mac_stats.mcast_pkts_recvd: 130
dev.igb.0.mac_stats.bcast_pkts_recvd: 12
dev.igb.0.mac_stats.good_pkts_recvd: 337
dev.igb.0.mac_stats.total_pkts_recvd: 337
dev.igb.0.mac_stats.xoff_txd: 0
dev.igb.0.mac_stats.xoff_recvd: 0
dev.igb.0.mac_stats.xon_txd: 0
dev.igb.0.mac_stats.xon_recvd: 0
dev.igb.0.mac_stats.coll_ext_errs: 0
dev.igb.0.mac_stats.alignment_errs: 0
dev.igb.0.mac_stats.crc_errs: 0
dev.igb.0.mac_stats.recv_errs: 0
dev.igb.0.mac_stats.recv_jabber: 0
dev.igb.0.mac_stats.recv_oversize: 0
dev.igb.0.mac_stats.recv_fragmented: 0
dev.igb.0.mac_stats.recv_undersize: 0
dev.igb.0.mac_stats.recv_no_buff: 0
dev.igb.0.mac_stats.missed_packets: 0
dev.igb.0.mac_stats.defer_count: 0
dev.igb.0.mac_stats.sequence_errors: 0
dev.igb.0.mac_stats.symbol_errors: 0
dev.igb.0.mac_stats.collision_count: 0
dev.igb.0.mac_stats.late_coll: 0
dev.igb.0.mac_stats.multiple_coll: 0
dev.igb.0.mac_stats.single_coll: 0
dev.igb.0.mac_stats.excess_coll: 0
dev.igb.0.queue_rx_1.rx_irq: 0
dev.igb.0.queue_rx_1.rxd_tail: 108
dev.igb.0.queue_rx_1.rxd_head: 110
dev.igb.0.queue_rx_0.rx_irq: 0
dev.igb.0.queue_rx_0.rxd_tail: 225
dev.igb.0.queue_rx_0.rxd_head: 227
dev.igb.0.queue_tx_1.tx_irq: 0
dev.igb.0.queue_tx_1.txd_tail: 198
dev.igb.0.queue_tx_1.txd_head: 198
dev.igb.0.queue_tx_0.tx_irq: 0
dev.igb.0.queue_tx_0.txd_tail: 265
dev.igb.0.queue_tx_0.txd_head: 265
dev.igb.0.fc_low_water: 34800
dev.igb.0.fc_high_water: 34816
dev.igb.0.rx_control: 67141662
dev.igb.0.device_control: 416285249
dev.igb.0.watchdog_timeouts: 0
dev.igb.0.rx_overruns: 0
dev.igb.0.tx_dma_fail: 0
dev.igb.0.mbuf_defrag_fail: 0
dev.igb.0.link_irq: 2
dev.igb.0.dropped: 0
dev.igb.0.eee_control: 1
dev.igb.0.itr: 488
dev.igb.0.tx_abs_int_delay: 66
dev.igb.0.rx_abs_int_delay: 66
dev.igb.0.tx_int_delay: 66
dev.igb.0.rx_int_delay: 0
dev.igb.0.rs_dump: 0
dev.igb.0.reg_dump: General Registers
dev.igb.0.fc: 3
dev.igb.0.debug: -1
dev.igb.0.nvm: -1
dev.igb.0.iflib.rxq1.rxq_fl0.credits: 1023
dev.igb.0.iflib.rxq1.rxq_fl0.cidx: 110
dev.igb.0.iflib.rxq1.rxq_fl0.pidx: 109
dev.igb.0.iflib.rxq0.rxq_fl0.credits: 1023
dev.igb.0.iflib.rxq0.rxq_fl0.cidx: 227
dev.igb.0.iflib.rxq0.rxq_fl0.pidx: 226
dev.igb.0.iflib.txq1.r_abdications: 0
dev.igb.0.iflib.txq1.r_restarts: 0
dev.igb.0.iflib.txq1.r_stalls: 0
dev.igb.0.iflib.txq1.r_starts: 74
dev.igb.0.iflib.txq1.r_drops: 0
dev.igb.0.iflib.txq1.r_enqueues: 74
dev.igb.0.iflib.txq1.ring_state: pidx_head: 0074 pidx_tail: 0074 cidx: 0074 state: IDLE
dev.igb.0.iflib.txq1.txq_cleaned: 155
dev.igb.0.iflib.txq1.txq_processed: 195
dev.igb.0.iflib.txq1.txq_in_use: 43
dev.igb.0.iflib.txq1.txq_cidx_processed: 195
dev.igb.0.iflib.txq1.txq_cidx: 155
dev.igb.0.iflib.txq1.txq_pidx: 198
dev.igb.0.iflib.txq1.no_tx_dma_setup: 0
dev.igb.0.iflib.txq1.txd_encap_efbig: 0
dev.igb.0.iflib.txq1.tx_map_failed: 0
dev.igb.0.iflib.txq1.no_desc_avail: 0
dev.igb.0.iflib.txq1.mbuf_defrag_failed: 0
dev.igb.0.iflib.txq1.m_pullups: 0
dev.igb.0.iflib.txq1.mbuf_defrag: 0
dev.igb.0.iflib.txq0.r_abdications: 0
dev.igb.0.iflib.txq0.r_restarts: 0
dev.igb.0.iflib.txq0.r_stalls: 0
dev.igb.0.iflib.txq0.r_starts: 88
dev.igb.0.iflib.txq0.r_drops: 0
dev.igb.0.iflib.txq0.r_enqueues: 88
dev.igb.0.iflib.txq0.ring_state: pidx_head: 0088 pidx_tail: 0088 cidx: 0088 state: IDLE
dev.igb.0.iflib.txq0.txq_cleaned: 220
dev.igb.0.iflib.txq0.txq_processed: 260
dev.igb.0.iflib.txq0.txq_in_use: 45
dev.igb.0.iflib.txq0.txq_cidx_processed: 260
dev.igb.0.iflib.txq0.txq_cidx: 220
dev.igb.0.iflib.txq0.txq_pidx: 265
dev.igb.0.iflib.txq0.no_tx_dma_setup: 0
dev.igb.0.iflib.txq0.txd_encap_efbig: 0
dev.igb.0.iflib.txq0.tx_map_failed: 0
dev.igb.0.iflib.txq0.no_desc_avail: 0
dev.igb.0.iflib.txq0.mbuf_defrag_failed: 0
dev.igb.0.iflib.txq0.m_pullups: 0
dev.igb.0.iflib.txq0.mbuf_defrag: 0
dev.igb.0.iflib.override_nrxds: 0
dev.igb.0.iflib.override_ntxds: 0
dev.igb.0.iflib.tx_abdicate: 0
dev.igb.0.iflib.rx_budget: 0
dev.igb.0.iflib.disable_msix: 0
dev.igb.0.iflib.override_qs_enable: 0
dev.igb.0.iflib.override_nrxqs: 0
dev.igb.0.iflib.override_ntxqs: 0
dev.igb.0.iflib.driver_version: 7.6.1-k
dev.igb.0.%parent: pci0
dev.igb.0.%pnpinfo: vendor=0x8086 device=0x150e subvendor=0x1734 subdevice=0x11a8 class=0x020000
dev.igb.0.%location: slot=6 function=0 dbsf=pci0:0:6:0
dev.igb.0.%driver: igb
dev.igb.0.%desc: Intel(R) PRO/1000 PCI-Express Network Driver
dev.igb.%parent:

dev.igb.0.eee_control: 1 Hier wüßte ich gerne, ob 1 disabled bedeutet oder nicht. :confused:

Ich teste nun bei Gelegenheit, ob Kühlung+FW schon die Lösung war. Wenn nicht, wird dev.igb.0.eee_control: 0 ausprobiert.
 

pbtraveller

Well-Known Member
Themenstarter #17
Habe gerade mal testweise dev.igb.0.eee_control auf 0 gestellt. Dabei ist die Netzwerkverbindung sofort eingefroren. Ich werde mal meine Bios-Settings anschauen, was ich an Powersaving-Einstellungen gesetzt habe. Vielleicht lässt sich ja so das Problem umschiffen....
Angeblich gibt es für mein Board kein Bios-Update (sagt jedenfalls die eingebaute Update-Lösung, die über das Netzwerk anfragt). Werde mal schauen, ob ich dennoch was neueres finde...

Der Wert 1 soll (laut Thomas Krenn-Seite) aus bedeuten, 0 würde es also einschalten......

Viele Grüße

pbtraveller