VMware-Forum

Ich bekomme zur Laufzeit (nicht direkt reproduzierbar) einen Purple Screen Of Death (PSOD). -> siehe Attachment.

2x Intel Xeon Quadcore 5405
Tyan Tempest i5100X (S5375)
4x 2GB ECC Reg Kingston RAM
Adaptec 3405 SAS Controller

Neuestes Bios-Update ist appliziert.

Hat jemand eine Idee, woran dies liegen könnte oder ob evtl. bestimmte Bios-Einstellungen dafür verantwortlich sind?

Hallo,

ich würde auf kaputte CPU.

Mfg Marco

Habe für ca. 60 Minuten einen Stresstest auf allen 8 cores laufen lassen, so dass quasi 0% idle waren. Kein Absturz.
Einen CPU-Defekt schließe ich damit weitesgehend aus.

Dann mach doch nen Case bei VMware auf, du müsstest doch
eigentlich support haben. Oder?

Die Jungs können das wensentlich besser denke ich interpretieren.

wir hatten das auch mal, haben aber einen Call beim HW Hersteller aufgemacht, der dann u.A. eine CPU gewechselt hatte. Hat aber lange gedauert, die mussten sogar die Maschine mitnehmen zum Testen, weil Sie nicht dahinter kamen was es war. Wir hatten aber das Glück, damals drei identische Maschinen gekauft zu haben und nur bei einer trat es regelmäßig auf.

Moin, moin,

wurde auf dem ESX der Adaptec Storage Manager (asm_linux_x86.....) installiert?

Wenn ja, schau Dir einmal das hier an:
http://vmware-forum.de/viewtopic.php?p=55536#55536

Vielen Dank für die Antworten!

@sirrossi:
Das hat mir in der Tat weitergeholfen.
Hatte den asm v5.30 installiert. Nach Upgrade auf v6.00 stürzt es zumindest nicht mehr einfach so zur Laufzeit ab. Ich hatte heute allerdings ein Raid5 mit Quick-Init erstellt und habe dann während ESX gebooted war ein "Verify with fix" laufen lassen. Gleichzeitige I/O Zugriffe hat das System dann nicht so gut vertragen. -> erneut PSOD

Lasse nun nochmal von Grund auf neu einen "Clear" Raid Build laufen und hoffe, dass es dann stabil funktioniert.

Leider wird bereits bei wiederholtem Aufruf von "arcconf" das System in den Zustand des PSOD versetzt. Dies passierte sowohl mit der ASM Version 5.3x wie auch der 6.xx. Dies wurde auch so von Adaptec bestätigt.
Erst mit ESX Update 4 soll ein von VMware zertifizierter Treiber kommen. Also in 4-6 Monaten

Wollen hoffen, das bis dahin die Platten halten.

Danke Dir für die Information.
Lasse den ASM dann erstmal runter und hoffe einfach mal, dass in den nächsten Monaten nicht mehr als eine Platte ausfällt.

sirrossi hat geschrieben:Leider wird bereits bei wiederholtem Aufruf von "arcconf" das System in den Zustand des PSOD versetzt. Dies passierte sowohl mit der ASM Version 5.3x wie auch der 6.xx. Dies wurde auch so von Adaptec bestätigt.
Erst mit ESX Update 4 soll ein von VMware zertifizierter Treiber kommen. Also in 4-6 Monaten

Wollen hoffen, das bis dahin die Platten halten.

Das ist natürlich nicht die optimale Lösung...

StevensDE hat geschrieben:Das ist natürlich nicht die optimale Lösung...

Da gebe ich Dir gerne Recht, welchen Vorschlag hast Du?

sirrossi hat geschrieben:Da gebe ich Dir gerne Recht, welchen Vorschlag hast Du?

Wenn ihr wisst, dass das Problem in ESX Update 4 behoben wird, dann würde ich bei VMWare Anfragen ob man den Adaptec zertifizierten ESX Treiber bereits vorher in Form eines Patches erhalten kann.

Die Systeme mit einen instabilen Treiber laufen zu lassen wo es jeden Moment einen "PSOD" geben kann wäre mir auf jeden Fall zu riskant.. Und dann noch bei so einer enorm wichtigen Sache wie Storage / Daten.

Hallo Sirrossi,

habe den Thread bezüglich Adaptec Controller ESX und Adaptec Storage Manager gelesen:

ICH HABE GENAU DAS SELBE PROBELM.

Ohne den Storage Manager Agent läuft der Host ohne Probleme. Sobald ich aber den Agent installiere, dauert es nicht lange bis ich auch n PSOD bekomme.

Habe heute auch bei Adaptec einen Call aufgemacht und dieses Problem beschrieben.

Hast du vielleicht schon eine Lösung zu dem Problem gefunden?

Ich benutze ESX 3.5 U3, leider keine Besserung....

So,

ich werde jetzt mal alle meine weiteren Beiträge auf diesen

http://vmware-forum.de/viewtopic.php?p=55536#55536


Thread posten.

Wir sehn uns da.

Hmm .. soweit ich mich erinner war die proc node der Adaptectreiber recht aussagekräftig. Reicht es zur Überwachung nicht ein cronjob der ein trap sended wenn seine vorletzte Kopie der Procnode sich von der letzten unterscheided ?

So hatte ich das mal unter Debian potato auf einem HP Netserver mit NR4m gelöst, der war ein Adaptec.