… die sind so unglaublich, dass sie eigentlich nicht existieren dürften.

Wir haben hier in der Firma einen von vielen HP DL580 G6 am laufen, welcher vor einer Woche mit einem Speicherfehler hingestanden ist. Nett in diesem Zustand sind vor allem die hübschen Diagnose-LEDs für die Speicherbänke an der Vorderseiten. Warum ILO und das ganze HP-Geraffel den Speicherfehler nicht festgestellt haben, ist seltsam, aber wenn man die Software näher kennt, durchaus verständlich. Also gabs eine hübsche Kernelpanic und ganz viel Alarm beim anschließenden Reboot. Wie gesagt, bei einem oder mehreren defekten Speicherriegel blinken an der Front alle LEDs – das macht die Suche nicht einfacht. Die Downtime war lang und weil wir sowieso Zeit hatten, die Systeme darauf waren mehr oder weniger redundant ausgelegt, haben wir gleich ein BIOS- und Firmware-Update eingespielt … Wir hätten es lieber bleiben lassen sollen.
Der anschließende Reboot wurde uns mit einer weiteren Kernel-Panic in Bezug auf einen DMA-Zugriff des SCSI-Controllers gemeldet. Was tun in diesem Fall? Schließlich hatte vor dem Firmware-Update noch alles funktioniert. Klare Sache … HP-Support. Leider was das neue Mainboard mit der selben BIOS- und Firmware ausgestattet und der Fehler weiterhin vorhanden *gnahhhh*
Google unser großer Freund wusste glücklicherweise Bescheid, dass man dieses im Firmware-Update aktivierte “Feature”, es handelt sich hierbei um IOMMU, über einen Grub-Parameter wieder ausschalten kann. Der Hint war “ iommu=off”
Was dann kam war absolut kurios und absolut fantastisch unglaublich. Dmesg meldete bei den Netzwerkkarten “Firmware not running. Aborting…“  *wtf???* Selbst Google war etwas ratlos. Es gibt momentan genau 29 Treffer, von denen 20 einen Verweis auf den Sourcecode für die Treiber von Broadcom (bnx2) und Alteon (acenic) sind. Der Rest sind ein paar verstreute Foreneinträge ohne zufriedenstellende Antwort oder ein Blog-Eintrag, bei dem der ganze Schrott zurück an HP ging.

Der Vorteil von OpenSource stellt sich dann wieder bei so einem Problem raus. Die Jungs von 3com und Alteon haben einen Hint in die richtige Richtung geliefert.

/*
* aman@sgi.com - its useful to do a NIC reset here to
* address the `Firmware not running' problem subsequent
* to any crashes involving the NIC
*/

Im Sourcecode des bnx2-Treibers gab es einen ähnlichen Eintrag. Leider fehlt dort die Funktion, die Karten zurück zu setzen.

if ((reg & BNX2_DEV_INFO_SIGNATURE_MAGIC_MASK) !=
       BNX2_DEV_INFO_SIGNATURE_MAGIC) {
       dev_err(&pdev->dev, "Firmware not running, aborting.\n");
       rc = -ENODEV;
       goto err_out_unmap;
}

Die Lösung war schlußendlich ziemlich simpel …
- HP hat Ersatz für den defekten Speicher geliefert
- Server ausgeschaltet
- Stromlos gemacht
- Speicher eingebaut
- Power on …
- … und Firmware running.

Die Reset-Funktion der Broadcom-Netzwerkkarte scheint wohl Hardwaremäßig in Form von Stecker ziehen implementiert zu sein.
Was solls … Jetzt gehts.