Supermicro MBD-X11SCL-IF Mainboard: Sporadische Freezes

[Fusseltuch]

Proxmox setzt aber auf einen modifizierten Ubuntu-Kernel. Eventuell ist da ein Bug drin. Ich habe den Thread auf dem Handy nur überflogen, aber könntest du mal ein Debian testen? Nicht, dass Proxmox ausgerechnet den Bug, der vll in Ubuntu existiert, mitschleppt.

 

[visar]

Und wieder ein Freeze (diesmal erst nach knapp 16 Std. uptime):

Hier wieder der letzte Screenshot vor dem Freeze:

(Es war um 06:20. Die oben angezeigten Zeiten sind z.T. wegen falscher Timezone verschoben.)

Somit haben meine gestern gemachten BIOS-Änderungen nichts gebracht. (Ich habe es unterdessen wieder auf BIOS Defaults zurückgesetzt.)

Habe gestern ZWEI neue 32 GB Kingston RAM Riegel bestellt, welche gemäss Kingston-Seite für dieses Board kompatibel sein sollten. Weiss nicht, ob sie schon heute bei mir ankommen.
Abgesehen von einem anderen RAM Riegel könnte es evtl. auch eine Rolle spielen, wenn dann Dual Channel verwendet wird.

Da mein Proxmox Node 1 (gleicher Server wie der in diesem Thread behandelte) ein Chassis-Lüfter Ausfall hatte, habe ich gestern den Lüfter getauscht. Dabei nutzte ich grad die Gelegenheit, um das neue BIOS zu installieren. Soweit gut...leider habe ich jetzt dort auch das Problem, dass er nicht mehr von der SSD bootet, egal, welchen Boot Mode ich im BIOS setze (vor dem Update war "Dual" gesetzt).
Hab dann von einem Super grub2 ISO gestartet und konnte so die SSD (und Proxmox) starten. Werde mich um das "Reparieren" des Bootloaders später kümmern. Möchte nicht etwas verschlimmbessern. Da ich diesen Server ja nicht ständig reboote, ist das Booten von diesem ISO im Moment ein guter Workaround.
Dieser Proxmox 1 Server ist nun auch schon wieder fast 11 Std. online. Natürlich habe ich hier nur das BIOS geändert und 2-3x den Server rebootet. Am OS selber habe ich nichts geändert. (Was wieder meine Beobachtung unterstützt, dass diese Freezes nur kommen, wenn auch was neu installiert oder grösseres aktualisiert wird.)

 

[visar]

So, ein paar Tage verspätet habe ich endlich meine neuen 2x32 GB Kingston Memory (ECC) erhalten und vorhin eingebaut:

Hier noch das alte Memory:

Und hier das neue:

Das ist jetzt das erste Mal, dass in einem dieser 3 Problemserver 64 GB RAM (und somit beide RAM-Slots gefüllt) eingebaut wurden.

Am Wochenende habe ich auf diesem Server wieder Proxmox (Node 2 im Cluster) installiert und wie üblich danach ein Freeze gehabt (aber schon nach wenigen Stunden). Danach lief das System bis heute tagelang stabil. Zwar keine VM, aber trotzdem habe ich immer mal wieder dran rumgespielt.
Ich werde heute Abend die SSD wieder löschen und Ubuntu 23.04 Server installieren und dann mit dem TOP-Befehl laufen lassen. (Über Nacht und morgen den ganzen Tag.)
Wenn ich morgen Abend wieder ein Freeze sehe, hat das neue Memory auch nichts gebracht. Falls nicht, wäre das eher schon ein positives Zeichen.

Stay tuned...

 

[Supaman]

Was mir noch einfallen würde:
- wenn Du die Boards gebraucht gekauft hast, alle Jumper prüfen ob die auf default stehen
- Watchdog im Bios abschalten + prüfen ob der Jumper abgezogen ist.

 

[visar]

Zwischenbericht: Seit 20 Std. läuft nun der Linux TOP-Befehl ohne Freeze. Und dies, obwohl ich gestern das OS (Ubuntu) ja neu installiert habe, was "üblicherweise" nach "einigen Stunden" (oft so >8 Std.) ein Freeze ausgelöst hat.

Bin mal gaaaaaaaaaaaaaaaaaaaaaaaaaaaanz vorsichtig optimistisch. Da es ja leider nicht wirklich reproduzierbar ist, könnte der Freeze noch kommen. Zumindest kam er in den letzten (ähnlichen) Fällen schon viel früher.

Geändert haben sich jetzt nur 2 Dinge:

• RAM der Marke Kingston (aber gleiche Spezifikationen)
• Dual Channel Modus (2x32 GB RAM)

Ich glaube nicht, dass es am Memory selber liegt, da ich abgesehen von diesen (eigentlich nicht wirklich zufälligen) Freezes ja keine Probleme hatte und auch Burn-In Tests unauffällig waren.
Aber ich habe halt immer nur EIN 32 GB Riegel im Board gehabt (bei allen 3 betroffenen Boards!).
D.h. ich habe jetzt das erste Mal Dual Channel im Einsatz. Und vielleicht ist genau das die Lösung. (Vielleicht mag dieses Board oder das Kingston Memory oder meine Default BIOS Settings kein Single Channel...oder...oder...)

Da ich ja jetzt noch ein Samsung 32 GB RAM übrig habe, werde ich das demnächst mal in den anderen Server (Proxmox Node 1) einbauen. Dann sind dort auch 2x32 GB (Samsung) drin und somit auch Dual Channel. (Das war eigentlich bereits vor einem Jahr geplant gewesen. Nur waren damals die RAM-Preis viel zu teuer.)

Leider läuft aktuell mein Proxmox 1 Server so halbweg produktiv (2 aktive VMs). D.h. ich müsste auf diesen Server mal für paar Tage verzichten, damit ich die Tests mit Dual Channel durchführen kann. (Dazu muss ich ja zwingend ein neues OS installieren.)

 

[visar]

Ich hab nun den TOP-Befehl abgebrochen und installiere gerade neu wieder Proxmox und somit auch Debian. (Damit ich die Nacht nutzen kann, ob er auch hier nach mehr als 8 Std. nicht mehr freezed.)

Der TOP-Befehl lief übrigens nun fast 13 Std. lang!

 

[visar]

F**K, jetzt habe ich doch noch ein Freeze bekommen.

Habe ja gestern nach meiner letzten Nachricht (so um 23 Uhr) Proxmox neu installiert und soweit eingerichtet (in Cluster aufgenommen etc.). Aber keine VMs erstellt. Bin dann noch vor Mitternacht ins Bett (da lief noch alles normal.)
Und heute im Log sehe ich, dass es um 0:41 (die Logzeiten sind UTC) ein Freeze gegeben hat. Also diesmal unter 2 Std.

Aber egal, ob jetzt 2, 8 oder 12 Std. uptime, der (vermutlich einmalige) "Nach-Neuinstallation-Freeze" ist auch mit Dual Channel und anderem Memory immer noch da. Nur die Ubuntu-Neuinstallation hat das System lange überlebt. (Was nicht heisst, dass dort der Freeze vielleicht in paar Stunden doch noch gekommen wäre.)

Tja, viel fällt mir jetzt leider auch nicht mehr ein. (Die Motherboards wurden übrigens neu gekauft und die nur 5 Jumper-Settings sind normal gesetzt.)

 

[visar]

Was mir noch einfallen würde:
- wenn Du die Boards gebraucht gekauft hast, alle Jumper prüfen ob die auf default stehen
- Watchdog im Bios abschalten + prüfen ob der Jumper abgezogen ist.

Wie weiter oben erwähnt, sind die Boards neu gekauft und die Jumper stehen auf Default.

Bezüglich Watchdog im BIOS muss ich zuerst schauen, wo ich das bei meinem BIOS finde (und abschalten kann).
Gemäss Board-Anleitung gibt es ein Watchdog-Jumper:

Es scheint sich um eine Reset-Funktion zu handeln. (Wenn man den Jumper setzt, wird der Watchdog Timer resettet ähnlich wie ein CMOS Clear Jumper, richtig?)
Was macht der Watchdog genau? In welchem Zusammenhang könnte das mit meinem Freeze stehen? (Verständnisfrage)

 

[Supaman]

Wachtdog ist ein Freeze/Absturz Wachhund. Sprich, wenn das sich System aufhängt, macht es einen automatischen Reboot, jedenfall in der Theorie. Ich habe damit selber noch nicht aktiv gearbeitet, es kann sein das noch eine Software Komponente dazugehört. Ich hatte mal Probleme mit im Bios aktivierten Watchdog, sprich wenn WD=on hat sich der ESX weggehängt. WD=off und alles war gut.

 

[visar]

Wieder mal was neues von meiner Seite.

Zuerst eher eine weitere Bestätigung und keine News:
Am Wochenende habe ich endlich mal meine OPNsense Firewall von 22.7.11 auf 23.7.6 upgedated, was ein Major Update (mit mehreren Reboots) bedeutete.
Bekanntlich läuft meine OPNsense auch auf einem dieser 3 Supermicro Boards. Den letzten Freeze hatte ich dort vor fast einem Jahr, obwohl die Firewall in dieser Zeit 24h in Betrieb war. Also sehr stabil. Der Unterschied hier lag daran, dass ich eben nie einen grösseren Update durchgeführt habe und das ist ja unterdessen DAS Merkmal für ein Freeze zu erhalten.
Und tja, was soll ich sagen? Schon während dem Update (es waren mehrere Zwischenschritte nötig) gabs ein Freeze! Nicht, dass mich das jetzt überraschte. Aber dass es so schnell kam war etwas unüblich. (Seit diesem Freeze läuft das Teil wieder normal stabil...und so wird es wohl auch bleiben, bis ich wieder ein OS-Update durchführen muss.)
Also nur so am Rande, dass die Freeze auch dort immer noch geschehen. (Und dies ist ja FreeBSD und nicht Debian/Ubuntu)

Nun aber wieder zu meinem (immer noch) Proxmox-Testserver. Eigentlich bin ich ja praktisch alle kritischen Komponenten durchgegangen bzw. habe sie ersetzt/aktualisiert (Memory, CPU und auch BIOS). Ohne Erfolg.
Gestern kam mir aber doch noch was in den Sinn: In allen drei Supermicro Servern habe ich die gleiche PCI-Netzwerkkarte verbaut (und auch im Einsatz): Eine Broadcom NetXtreme II BCM57810 Dual 10 Gigabit Ethernet Karte. In allen 3 Systemen habe ich diese Karte als Bonding konfiguriert und nie Probleme (Stabilität oder Performance) bemerkt. Sowohl FreeBSD (OPNsense), wie auch Proxmox (Debian) oder Ubuntu haben die Karte automatisch erkannt und ich musste nur das Bonding konfigurieren.
Etwas, was in allen 3 betroffenen Systemen vorkommt, müsste man eigentlich ins Troubleshooting aufnehmen. Ich habe diese Karte aber eigentlich nie in Verdacht gehabt. Vermutlich, weil sie ja normal funktionierte.

Also habe ich sie gestern mal aus dem Test-Server entfernt und danach Proxmox wieder mal komplett neu installiert (um den Freeze zu forcieren) und am Ende mein top-Befehl gestartet und bin dann ins Bett.
Erste Erkenntnis: Nach 15 Std. uptime ohne diese Karte habe ich noch kein Freeze erhalten! Ich denke, der wäre längst überfällig. Natürlich ist dieser eine Test jetzt noch nicht ausschlaggebend, aber gibt mir doch wieder etwas Hoffnung. (Aktuell installiere ich grad Fedora Server auf diesem Server, damit ich auch mal noch ein weiteres Linux getestet habe.)
Wenn ich dann morgen Abend (nach weiteren 12-15 Std.) immer noch kein Freeze habe, würde diese Karte langsam zum Hauptverdächtigen werden.

Obwohl ich noch kein abschliessendes Urteil fällen kann, mache ich mir natürlich schon mal meine ersten Gedanken:

• Die Karte war bei allen Freezes in dem jeweiligen System eingebaut. (Aber nicht immer war das Netzwerk konfiguriert! Dies spielt offenbar keine Rolle.)
• Bei einer solchen Karte können zwei Dinge buggy sein: Die Firmware oder der (Linux) Treiber. Mein Gefühl geht eher in Richtung Firmware, denn die Treiber waren ja immer unterschiedlich: (FreeBSD 1 Jahr alt/aktuell, Debian 1 Jahr alt/aktuell, Ubuntu 1 Jahr alt/aktuell). Das würde mich wundern, wenn ALLE diese Treiber immer den gleichen Bug hätten. Hingegen die Firmware (in der Karte) wäre ja bei allen 3 Karten identisch und evtl. veraltet, weil es diese Karten schon einige Jahre gibt.
• (Gerade noch in den Sinn gekommen!) Könnten die eingesteckten SFP+ Module evtl. auch eine Rolle spielen und vielleicht gar nicht die Karte selber??

Leider sehe ich bezüglich Firmware-Update die Chancen eher schlecht, weil es eine OEM-Karte ist. BCM57810 wurde zuerst von der Firma Broadcom und dann später von der Firma Qlogic gebrandet. (Marvell ist glaub auch noch involviert)
Dieser Chip (oder Karte) wird auch von Dell, HP und früher glaub Lenovo verkauft. Deshalb findet man im Internet leider viele, sehr unterschiedliche Referenzen. Welche (aktuelle) Firmware ich aber jetzt wo finde und ob sie überhaupt bei meiner Karte funktioniert, ist schwierig zu sagen und könnte eine grosse Herausforderung werden. Zumindest bin ich da noch nicht wirklich fündig geworden.

Zuerst werde ich jetzt mal weiter testen, damit ich wirklich keine Freezes mehr sehe und dann wohl diese Karte als Ursache bezeichnen kann. Das wäre natürlich ein Riesenfortschritt und würde das Problem MASSIV eingrenzen. Aber gelöst hätte ich es natürlich noch nicht.

Hier schon vorab noch paar Infos zu dieser Karte (vom produktiven Proxmox/Debian System):

 

[java4ever]

Interessant. Zum Glück gibt's ja für n schmalen Taler Mellanox ConnectX-3 / ConnectX-4 Lx

 

[visar]

Interessant. Zum Glück gibt's ja für n schmalen Taler Mellanox ConnectX-3 / ConnectX-4 Lx

Ja, falls es wirklich an der LAN-Karte liegt und ich diese nicht updaten bzw. das Problem lösen kann, dann müsste ich nach einer Alternative suchen. Aber ganz soweit bin ich noch nicht.

Zwischenupdate: Nach 8:15 Std. Fedora auch noch kein Freeze. Gutes Zeichen. Am Abend weiss ich dann mehr...

 

[underclocker2k4]

Wo hast du denn die Karte her? Das sieht mir sehr stark nach einer Billigkarte aus. Da würde ich nicht mal unbedingt auf die Firmware tippen, sondern, dass die Karte an sich grundsätzlich Müll ist. (wird man ja anhand "ohne Karte" sehen, was passiert)

Karte einzeln:

Mellanox ConnectX-3 CX311A PCIe x4 10GBe SFP+ 10Gbit Full Profile 42706799031 | eBay

Entdecken Sie Mellanox ConnectX-3 CX311A PCIe x4 10GBe SFP+ 10Gbit Full Profile in der großen Auswahl bei eBay. Kostenlose Lieferung für viele Artikel!

www.ebay.de

mehrere:

Mellanox ConnectX-3 MCX311A-XCAT CX311A 10GBe 10GB SFP+ Normal profile | eBay

Entdecken Sie Mellanox ConnectX-3 MCX311A-XCAT CX311A 10GBe 10GB SFP+ Normal profile in der großen Auswahl bei eBay. Kostenlose Lieferung für viele Artikel!

www.ebay.de

Aber aufgepasst, wenn mal ESX im Raume steht oder so, dann wird das mit den Karten nichts mehr. (bei aktuellen Versionen)

 

[Fusseltuch]

Manchmal ist es wie verhext. Wenn du ein Firmware-Update versuchen möchtest, die gibt es inzwischen tatsächlich direkt bei Marvell. Zum Glück öffentlich zugänglich. Die letzte Version ist von März 2022 und neuer als die, die du installiert hast.

Public Driver Downloads | QLogic Fibre Channel HBAs and FastLinQ Ethernet adapters and controllers - Marvell

Download Marvell drivers by Platform or Part Number for Marvell QLogic Fibre Channel HBA and Marvell FastLinQ Ethernet adapters and controllers.

www.marvell.com

Intelligent Ethernet Adapter > Linux > Part Number: QLE34xx

Es KANN sein, dass du beim Update ein "id mismatch" erhälst, aber das lässt sich ggf umgehen, siehe hier: https://www.reddit.com/r/homelab/co...cm57810_10_gigabit_ethernet_firmware/iq57s85/

 

[wddn]

Kaufe doch mal eine Mellanox, oder Intel SFP+ Karte zum Testen - du hast schon soviel Zeit rein gesteckt…

Ich nutze ausschließlich Intel NICs, da die Kompatibilität am besten ist.

 

[Fusseltuch]

Ich kaufe zB keine Intel-NICs mehr. Die 700er-Serie ist in meinen Augen Schrott, die 2.5G i225 und i226 sind fehlerbehaftet... Mellanox gehe ich aber mit, das geht. ;-)

 

[underclocker2k4]

Alle haben da ihre Probleme. Ja, die 710er war nicht so geil. (bzw. ist)
Aber ne X520 ist nicht so verkehrt. Und selbst ne 710er ist für den use case OK.
Aktuell erstmal abwarten, was ohne die BCM passiert und dann mal schauen, dass man eine gepatcht bekommt.
Der Fehler scheint ja irgendwie halbwegs reproduzierbar zu sein, das hilft ja schonmal, dass man relativ schnell ne Erkenntnis hat.

Intel hat einfach eine relativ hohe Unterstützung. Wobei auch beim vSphere 7.0.3 mit der 520er schon Schluss ist. Wäre also in dem Fall (wenn man auch nur mit dem Gedanken spielt) wieder eher schlecht. Ist bei der MLX C3-X analog.

 

[visar]

21 Std. uptime mit Fedora und laufenden top-Befehl. Und auch hier noch kein Freeze. (Wobei ich dem Ganzen noch nicht wirklich traue...)

Werde jetzt mal die Karte wieder einbauen und mal schauen, ob ich mit der Marvell-Firmware etwas machen kann.

Können eigentlich die SFP+ Module (in meinem Fall DAC-Kabel) auch eine Rolle spielen oder sind diese Komponenten "zu dumm", um einen Freeze auslösen zu können? (Denn ich hatte die DAC-Kabel immer angeschlossen. Aber wie schon erwähnt: nicht immer konfiguriert und damit nicht aktiv genutzt.)

 

[visar]

Manchmal ist es wie verhext. Wenn du ein Firmware-Update versuchen möchtest, die gibt es inzwischen tatsächlich direkt bei Marvell. Zum Glück öffentlich zugänglich. Die letzte Version ist von März 2022 und neuer als die, die du installiert hast.

Public Driver Downloads | QLogic Fibre Channel HBAs and FastLinQ Ethernet adapters and controllers - Marvell

Download Marvell drivers by Platform or Part Number for Marvell QLogic Fibre Channel HBA and Marvell FastLinQ Ethernet adapters and controllers.

www.marvell.com

Intelligent Ethernet Adapter > Linux > Part Number: QLE34xx

Es KANN sein, dass du beim Update ein "id mismatch" erhälst, aber das lässt sich ggf umgehen, siehe hier: https://www.reddit.com/r/homelab/co...cm57810_10_gigabit_ethernet_firmware/iq57s85/

Danke. Genau auf diese reddit Seite bin ich gestern auch schon gestossen.

Ich habe nun von diesem Marvell Link das entsprechene Linux Firmware Package runtergeladen.
Wenn ich das (interaktive) Firmware Utility starte, werden meine beiden Dual Ports angezeigt:

Da wusste ich dann nicht mehr weiter. (bzw. das readme File besitzt soviele Befehle, dass es mir schwindlig wurde...)

(Mit dem Befehl "dev" bekomme ich übrigens nochmals genau die obige Liste zurück. Im readme steht zu diesem Befehl: "'dev' will display a list of upgradeable devices." Also erkennt er die Karte als upgradeable an.)

Habe aber dann im readme ein Beispiel für den nicht interaktiven Modus gefunden, mit dem man zumindest mal prüfen kann, ob es zur Firmware gültige Adapter gibt:

[root@localhost firmware]# ./lnxfwnx2 -all dir -mbi ql_mbi_7.16.01.bin
QLogic Firmware Upgrade Utility for Linux: v2.11.14
There is no supported network adapter found on this server!!!
Please make sure that devices are up and running.Quitting program ...

Hier scheint es ihm dann nicht mehr "upgradeable" zu sein.

Ich vermute, dass ich nun genau das Problem mit der PCI Sub Device ID habe.
Bei reddit stand dazu das folgende:

The firmware is deployed as a monolithic image and it will fail due to an incorrect subsystem device ID.
You can either manipulate the table within the firmware or for long-term trouble free updates, it's easier to modify the subsystem device ID within nvram. Please note that you'll need to do this for each device ie. port. eg.

Und danach folgt ein Beispiel, mit dem ich leider gar nichts anfangen kann.

Was würdest du mir hier empfehlen? Eher die Firmware-Tabelle anpassen oder die Sub Device ID? Das erste würde halt nur für diese aktuelle Firmware (7.16.01) gelten und das zweite, wenn man in Zukunft immer wieder mal ein Firmware Update durchführen möchte.
Ich vermute, dass es zu dieser Karte nicht mehr viele Firmware-Updates geben wird (wenn überhaupt) und ich normalerweise auch kein Update durchführe, falls mein Freeze-Problem mit dieser Firmware behoben würde.
Also ich tendiere deshalb eher zu ersten Variante ("manipulate the table within the firmware").

Nur wie? Das ist ja ein .bin File. Ich denke, dazu braucht es ein spezielles Tool oder zumindest einen Hex-Editor. Und dann müsste man wissen, an welcher Stelle die Änderungen vorgenommen wird. Wir aber durch diese Manipulation nicht der Hash des Files geändert?

Hat mir da jemand mehr Infos dazu? (Gemäss reddit hat es der Topic Starter und zuletzt noch ein andere User so den Firmware-Update geschafft...leider hat er es nicht erklärt, wie.)

Beitrag automatisch zusammengeführt: 25.10.2023

Vielleicht wäre es aber in meinem Fall doch einfacher, "nur" die falsche PCI Sub Device ID anzupassen? Ich müsste das zwar bei jeder Karte für jeden Port machen, aber wäre evtl. (für mich) einfacher.

Wenn ich das richtig verstehe, sind das meine PCI IDs:

Vendor: 14e4
Device: 168e
Sub-Vendor: 14e4
Sub Device: 1006

Gemäss dem reddit Post müsste jedoch der Marvell-Treiber auf folgendem lauten: QLE3442-CU-CK 14e4:168e 14e4:5006
Ich müsste also die Sub Device ID von jetzt 1006 auf 5006 ändern können. Dann könnte der Firmware-Update durchlaufen (wenn ich das richtig verstanden habe).

Das bei reddit angegebene Beispiel mit "ediag_x64.efi -b10eng" ist aber glaub kein normaler Linux-Befehl, sondern für ESXi.

[Edit] Je länger ich da nachdenke, desto unlogischer wird es für mich, dass man mit einem Tool einfach die PCI ID direkt auf dem Device ändern kann. Vermutlich geht das im oben gezeigten Beispiel nur, weil dort die Karte in der VM so angezeigt werden soll. Man ändert also nicht direkt die Karte, sondern nur, wie es VMware dann in der VM anzeigt. Das könnte sicher gehen, weil man bei einer VM ja fast alles ändern kann (Seriennummer etc.).
Aber in meinem Fall würde mir das wohl nichts nützen. Ich müsste es ja direkt in der Karte geändert haben. Und ob das geht?
Dann bleibt doch nur noch die Anpassung der Firmware-Datei, oder sehe ich das falsch?

 

[Fusseltuch]

Du warst mit dem zweiten Edit auf dem richtigen Weg. ;-)

Gemäss dem reddit Post müsste jedoch der Marvell-Treiber auf folgendem lauten: QLE3442-CU-CK 14e4:168e 14e4:5006
Ich müsste also die Sub Device ID von jetzt 1006 auf 5006 ändern können. Dann könnte der Firmware-Update durchlaufen (wenn ich das richtig verstanden habe).

Genau das macht man. Hat auch nichts mit "an eine VM durchreichen" zu tun, sondern du änderst die ID direkt im EEPROM der Karte. Das ist an sich aber nichts schlimmes. Das kann man mit vielen Herstellern machen. Gerade Mellanox-Karten gehen dafür wunderbar.

Das bei reddit angegebene Beispiel mit "ediag_x64.efi -b10eng" ist aber glaub kein normaler Linux-Befehl, sondern für ESXi.

Habe den Beitrag nur überflogen, aber das sieht für mich so aus, als würde man das direkt aus EFI Shell machen. Das ergibt auch Sinn, das so zu machen. Im Prinzip ganz einfach. Die .efi Datei auf einen FAT32 formatierten USB-Stick kopieren und in die EFI shell booten. Entweder kann man die direkt aus dem BIOS/EFI heraus starten (meist unter "boot" oder irgendwo am Ende) oder du rufst das Bootmenü des Mainboards auf und kannst von dort in die Shell springen. Ich glaube das geht bei Supermicro.

Du landest dann in einer rudimentären Shell und wechselst mit "fs0:" (ohne die Anführungsstriche, Doppelpunkt ist Ö auf einer deutschen Tastatur) auf den USB-Stick. Mit "ls" kannst du dir sicherheitshalber noch anzeigen lassen, ob du tatsächlich auf dem richtigen Laufwerk bist und dann geht es mit dem genannten Befehl weiter.

Falls du nicht weiterkommst, können wir hier versuchen, dich durchzulotsen. Ich muss mal schauen, ob ich irgendwo auf der Arbeit noch so eine Karte habe, mit der ich das mal testen kann. Will dazu aber nichts versprechen.

Und ein wirklich ernst gemeinter Ratschlag zum Schluss: wenn du die Chance hast, die Informationen von der Karte zu sichern, tu das auf jeden Fall. Kenne die Syntax von dem Flashtool nicht, aber sowas geht meistens. Wenn du dir unsicher bist, mach ein Foto oder Screenshot, stell's hier rein und dann sehen wir weiter. Und nun gutes Gelingen.

€dit: Ich hätte eine BCM57840 mit alter FIrmware, mit der ich das ggf. durchtesten kann. Ich GLAUBE, die hat aber schon die korrekten Sub Device IDs. Habe das Firmware-Tool aber noch nicht getestet.

 

[visar]

Und ein wirklich ernst gemeinter Ratschlag zum Schluss: wenn du die Chance hast, die Informationen von der Karte zu sichern, tu das auf jeden Fall.

Immer ein guter Ratschlag.

Ich denke, ich konnte mit dem Qlogic Firmware Utility (das von der Marvell-Seite) ein "Backup" des NVRAM erstellen.
Im readme steht zu diesem Befehl:

dumpnvram {<filename>}
Dumps the NVRAM contents or MDUMP image to the specified file.
if "mdump" option is not specified then dump the entire NVMRAM contents
to specified file.
<filename> is a mandatory parameter. Use forwardslash instead of
backslash when specifying <filename>. Alternatively you could also
use two backslashes in the file path. Use file/directory paths
without quotes/spaces.

Und so habe ichs gemacht. Zumindest habe ich nun für jeden Port eine Datei geschrieben.

Was dort genau drinsteht und ob ich diese mit dem gleichen Tool im Notfall wieder zurückschreiben kann, weiss ich natürlich nicht. Gemäss dem restorenvram Befehl müsste es gehen. Das könnte ich ja mal testen. Bekanntlich ist ein Backup immer nur so gut, wie man ein Restore davon getestet hat.

restorenvram {<filename>} [idmatch] [lic] [config [mac]] [preserve [vpd]]
This command reads complete NVRAM image from a file and
writes the image to NVRAM.
Before writing the NVRAM image to adapter, verifications
against source NVRAM image will be performed. If any verification
failed, the image will not be written to adapter.
<filename> is the file name of NVRAM image.
<filename> is a mandatory parameter. Use forwardslash instead of
backslash when specifying <filename>. Alternatively you could also
use two backslashes in the file path. Use file/directory paths
without quotes/spaces.
'idmatch' requests the Firmware Upgrade Tool to restore the NVRAM
image only if the 4 IDs (vendor_id, device_id, subsystem_vendor_id,
subsystem_device_id) in the image file match those in the device.
'lic' means licencing information will be copied from
the source image, without this parameter it's preserved.
'config' means configuration area will copy from source
image except MAC address.
Configuration area includes MAC address and various
options.
'mac' applies only when 'config' is specified.
When 'mac' is specified, all configuration are copied
including MAC address.
'preserve' means all other components will be copied from
the source image except for the parameters supplied\r\n"
after this command.
'vpd' is applicable with 'preserve' option. When 'vpd' is
specified, vpd information of nvram is preserved.

Habe den Beitrag nur überflogen, aber das sieht für mich so aus, als würde man das direkt aus EFI Shell machen. Das ergibt auch Sinn, das so zu machen. Im Prinzip ganz einfach. Die .efi Datei auf einen FAT32 formatierten USB-Stick kopieren und in die EFI shell booten.

OK. Als ich das BIOS des Supermicro Boards aktualisiert habe, musste ich auch in die EFI Shell gehen und mit dem USB-Stick (fs0 hantieren. Das kenne ich somit.
Die Frage ist nur, was hat es mit dem "ediag_x64.efi -b10eng" auf sich? Von wo bekommt man diese .efi Datei her? Und ist das generisch/kompatibel mit jeder EFI Shell (64bit)?
Und gilt bei mir auch der Parameter "-b10eng"?

 

[Fusseltuch]

koduinternet-cpe/README.md at main · tonusoo/koduinternet-cpe

Linux-based CPE for Telia's (AS3249) "Koduinternet" service - tonusoo/koduinternet-cpe

github.com

Unter Punkt 3 gibt es einen Link zu https://github.com/tonusoo/koduinternet-cpe/raw/main/uefi_ediag.tgz

Da ist das Tool drin. Wie seriös die Quelle ist, kann ich aber nicht bewerten.

Beitrag automatisch zusammengeführt: 26.10.2023

Und ist das generisch/kompatibel mit jeder EFI Shell (64bit)?
Und gilt bei mir auch der Parameter "-b10eng"?

Ja, das bezieht sich auf den Engineering Mode von Broadcom, das passt bei deiner Konstellation auch. 👍🏻 Warum der Befehl genau so heißt wie er heißt, weiß nur Broadcom. Jedenfalls ist das wohl ein Tool aus der Produktion oder den Labors von Broadcom, mit denen die Chips parametriert werden. Die Chips, die vom Band fallen, sind vermutlich von der Hardware her alle gleich. Welche "Teilenummer" und welche Funktionen die Chips bekommen, entscheidet allein die Firmware bzw die Parameter in der Firmware. Und mit diesem Tool kann man die Parameter verändern. Eigentlich nicht für den Endkunden gedacht, aber egal.

 

[visar]

P.S.:
Hab nun mein vorher erstelltes NVRAM Backup mit dem Utility erfolgreich zurückschreiben können. Somit sollte dies im Notfall funktionieren.
Befehl: "restorenvram backup_enp1s0f0_7.13.75.nvram"

Beitrag automatisch zusammengeführt: 26.10.2023

koduinternet-cpe/README.md at main · tonusoo/koduinternet-cpe

Linux-based CPE for Telia's (AS3249) "Koduinternet" service - tonusoo/koduinternet-cpe

github.com

Unter Punkt 3 gibt es einen Link zu https://github.com/tonusoo/koduinternet-cpe/raw/main/uefi_ediag.tgz

Da ist das Tool drin. Wie seriös die Quelle ist, kann ich aber nicht bewerten.

Beitrag automatisch zusammengeführt: 26.10.2023

Ja, das bezieht sich auf den Engineering Mode von Broadcom, das passt bei deiner Konstellation auch. 👍🏻 Warum der Befehl genau so heißt wie er heißt, weiß nur Broadcom. Jedenfalls ist das wohl ein Tool aus der Produktion oder den Labors von Broadcom, mit denen die Chips parametriert werden. Die Chips, die vom Band fallen, sind vermutlich von der Hardware her alle gleich. Welche "Teilenummer" und welche Funktionen die Chips bekommen, entscheidet allein die Firmware bzw die Parameter in der Firmware. Und mit diesem Tool kann man die Parameter verändern. Eigentlich nicht für den Endkunden gedacht, aber egal.

Danke. Ja, habe in diesem (etwas älteren) PDF von Broadcom auch diese Infos erhalten.

Mal sehen, ob ich mit deinem verlinkten eDiag weiterkomme. Wird spannend...

 

[Fusseltuch]

Ja, das Zurückspielen sieht doch gut aus. So würde ich das erwarten. Dann steht einem Flashversuch ja nichts im Wege. Viel Erfolg, ich bin auf's Feedback gespannt. 😎

 

[visar]

So, brauche leider doch etwas Hilfe.

Habe das ediag_x64.efi Tool auf ein USB-Stick kopiert, in die EFI-Shell gebootet und auf den Stick gewechselt. Wenn ich das Tool starte, wird mir die Dual Karte angezeigt. Soweit schon mal gut.

Im reddit Post standen die folgenden Anweisungen:

ediag_x64.efi -b10eng

dev 1
nvm cfg
9=5006
save

dev 2
nvm cfg
9=5006
save

Nach etwas Suchen habe ich gesehen, dass die gesuchte Option 9 in einem Untermenü (3 Board config) versteckt ist:

Hier wird auch die (für mich "falsche") Subsystem Device ID angezeigt.

Mit "9=5006" und danach "save" müsste ich das nun ändern können.
Leider passiert nach der Eingabe von "9=5006 (Enter)" zuerst mal nichts. Weiss natürlich nicht, ob da überhaupt schon eine Bestätigung erscheinen sollte.
Und wenn ich dann auf der nächsten Zeile "save (Enter)" eingebe, kommt die obengezeigte Fehlermeldung (gelb markiert).

Beitrag automatisch zusammengeführt: 26.10.2023

Sorry, habs nun doch irgendwie geschafft. Zumindest zeigt er mir jetzt die 5006 an. Und bei "save" kam auch eine entsprechende Bestätigung, dass die Config gesichert wurde.

(Habs natürlich bei beiden Ports angepasst.)

Jetzt sollte ich die Voraussetzungen haben, um die Firmware zu flashen...mal sehen.

Beitrag automatisch zusammengeführt: 26.10.2023

Zum Flashen:

Nach dem Reboot und in der Fedora Shell zeigt mir der Befehl "lspci -vs 01:00 -nn" leider immer noch die alte PCI ID. (Ich habe vorhin extra nochmals im eDiag Tool nachgeschaut. Dort steht immer noch 5006!)

Unabhängig davon wollte ich trotzdem den Firmware-Flash probieren. Komme dort aber auch nicht weiter. Ich glaube aber langsam, dass es dort gar nicht wegen der PCI ID, sondern vielleicht wegen einer falschen Auswahl liegt:

Ich habs mit der Option "-mbi" (für Monolithic firmware) probiert. Aber vielleicht müsste ich eine der anderen Optionen verwenden. Nur welche?
Oder sollte ich mutig den "-F" (Force upgrade without checking version) verwenden? Trotzdem wärs gut, wenn ich die korrekte Option für DIESE Firmware nutzen würde...

 

[Fusseltuch]

Das sieht meiner Meinung nach erstmal richtig aus. Nur warum die Sub Device ID nicht geändert ist, weiß ich nicht. Eventuell mal komplett stromlos machen, den Server, nach dem Ändern?

Ich schaue eben mal, ob ich was herausfinden kann. Dauert ein wenig.

€dit: Kann es sein, dass du das Archiv falsch entpackt hast? Der Flashvorgang läuft bei mir aktuell ohne groß was zu machen. Das tgz File darf nicht entpackt werden, so sollte es aussehen:

Danach noch ein

chmod +x LnxQlgcUpg.sh

und dann mit

./LnxQlgcUpg.sh

starten.

Beitrag automatisch zusammengeführt: 26.10.2023

Siehe €dit weiter oben. ;-) Die Syntax aus dem Script ist auf alle Fälle so:

./lnxfwnx2 -all upgrade -f -mbi ql_mbi_7.16.01.bin

Ich habe der Vorgang wie gesagt über das Shell-Script gestartet. Und so sah es dann aus:

 

[visar]

Alle ok!! Nach einem erneuten Reboot zeigt mir nun lspci die korrekte PCI ID an:

Und der Firmware Upgrade (mit der gleichen -mbi Option) hat nun auch funktioniert. Scheinbar hat ihn doch nur die "falsche" PCI ID gestört.

Juhuuuu!! Freu mich grad wie ein kleines Kind.

Als ich es noch auf dem 2. Port updaten wollte (muss ja doch für jeden Port einzeln machen, oder?) kam die Meldung, dass es schon die gleiche Version sei. Habs dann aber zur Sicherheit nochmals (erfolgreich) mit dem -F (force without checking version) ausgeführt. Falls es unnötig gewesen ist, dann ists egal. Ansonsten bin ich mir jetzt sicher, dass auf beiden Ports diese Firmware drauf ist

ethtool zeigt mir zwar immer noch die alte Firmware an, aber vielleicht braucht der auch noch eine Zeit (oder Reboot).

Jetzt fängt also wieder der Versuch mit dem Reproduzieren des Freeze an. Ich werden in den nächsten Tagen berichten. (Und vielen Dank @Fusseltuch für deine jeweils raschen Antworten! Hast mir echt geholfen...)

 

[Fusseltuch]

Klasse 👍🏻

Ja, Reboot ist auf alle Fälle nötig, damit die Firmware aktiv ist.

 

[visar]

Ja, Reboot ist auf alle Fälle nötig, damit die Firmware aktiv ist.

YESS

Wird nun auch mit dem ethtool korrekt angezeigt:

Da jemand mal gefragt hatte: Ich habe diese 3 Karten neu auf Amazon gekauft: https://www.amazon.de/gp/product/B06X9T683K/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8&psc=1
Vor einem Jahr noch knapp € 100, (aktuell ca. € 50). Die gleiche Karte wird glaub auch noch von "10Gtek" auf Amazon angeboten.

Ich könnte mir vorstellen, dass einige diese Karte auf Amazon gekauft haben und vielleicht auch mit einem Firmware-Upgrade liebäugeln. (Sie scheint ja auch ohne Update gut zu laufen...mein Freeze ist sicher etwas exotisch und meiner Konfiguration geschuldet.)
Ich hoffe mit meiner (nicht wirklich geplanten) ausführlichen Dokumentation in diesem Thread einigen anderen Usern mit dieser Karte auch ein erfolgreiches Updaten zu ermöglichen.

 

[Fusseltuch]

Als "Geheimtipp", ähnlich wie auch bei den Mellanox ConnectX-3, ConnectX-3 Pro und ConnectX-4, könnte man die ganzen OEM Varianten von HP, Dell, Cisco und Oracle hernehmen. Die werden auf eBay gerade zu verramscht und lassen sich offenbar mit wenig Aufwand auch in eine "originale" Broadcom/QLogic/Marvell umflashen.