Crash bei Einsatz von CCISS Treiber auf HP DL380G3

Gute Morgen!

Ich habe am Wochenende Spass gehabt. Geplant war die Umsetzung eines Cluster auf Basis eines Debian Systems. :mad:

Dabei musste ich feststellen, dass das System bzw. der Prozess, der das Kernelmodul für den SmartArray 5i Controller laden soll, hängen bleibt. Allerdings nur auf dem betreffenden System. ( HP DL380 G3 - SmartArray 5i ).
Auf einem anderen System ( HP DL380 G4 - SmartArray 6i ) gibt es hingegen absolut keine Probleme.

Zum Einsatz kam dabei immer ein Kernel 2.4.32. Version des CCISS Moduls das Ärger macht ist 2.4.60.

Hat jemand von euch schonmal ähnliche Probleme in Verbindung mit den genannten Controllern feststellen müssen?

Gruß Andre

Hi,

kann den Fehler nicht bestätigen. AFAIK ist Debian aber auch nicht supportet. PSP installiert? cpqarrayd installiert? Mal mal ein apt get install cpqarrayd und schau mal obs nun funktioniert.

Huhu Bla!zilla :)

Richtig, Debian ist nicht offiziell supportet - ändert aber nix :) . Das System basiert auf Debian ( Univention Corporate Server ) und da der Kunde das System braucht gibt es daran auch nichts zu rütteln. Also muss ich es zum laufen kriegen.

Ich bin jetzt soweit, dass das Problem scheinbar nur mit einer bestimmten Kernelversion auftritt. ( Kernel 2.4.32. - Version der cciss Treibers 2.4.60 ).
Denn das aktuelle System läuft ja auf derselben Hardware - nur mit älten Kernel Versionen und Treibern... Auch ein aktueller 2.6er Kernel läuft problemlos. ( Denn können wir allerdings Momentan nicht benutzen weil andere Module den Einsatz von Kernel 2.4.x vorschreiben.

Nach ein bisschen Suche habe ich ( im Linuxforum ) Release Notes zum 2.4.33.3er Kernel gefunden:

Code:

---

PaX Team:
cciss: do not mark cciss_scsi_detect __init

---

Das hat mich dann etwas stutzig gemacht - zumindest ist es eine erste Spur die man verfolgen könnte...

PSP und die restliche HP Software ist nicht installiert. Das Problem ist ja bereits, dass das System beim Installieren während des Ladens der Treiber stehenbleibt ( Eingaben sind möglich, aber der Prozess, der das Modul lädt wartet sich zu Tode )

Ahh, verstehe. Trotzdem muss ich mahnend den Finger heben: Ist nicht supportet und du begibst dich da in eine blöde Abhängigkeit dem Kunden gegenüber, wenn du es supportest. ;)

Kannst du nicht einfach einen Kernel nehmen, bei dem der Fehler nicht auftritt?

Ich weiss, dass das doof ist - nur was soll man machen. ;)

Die Alternative wäre, Hardware zu nehmen für die Debian Zertifiziert ist. Nur wieviel Hardware gibt es da? ( Wenn man bestimmte Funktionen will, und die Hardware auch noch professionell sein soll) Da der Kunde auch sonst nur HP Hardware einsetzt nehmen wir lieber Hardware die zumindest für SLES und RHES zertifiziert ist. Die Warscheinlichkeit, dass es dann nicht läuft ist zumindest geringer ( gefühlt ) als beim Einsatz von WaldundWiesenHardware. Das es trotzdem Probleme geben kann sieht man ja jetzt...

Einfach einen anderen Kernel zu nehmen wäre die einfachste Möglichkeit, und werden wir wohl auch tun ( auf den alten Kernel Versionen - die natürlich die neusten Security Patche nicht haben ) lief es ja auch Problemlos. Ist zwar Ärgerlich, aber da die Kisten eh im Lan stehen und mit einer Firewall dicht gemacht werden sollte das Risiko vertretbar sein.

Ich finde es trotzdem ganz nützlich sowas trotzdem mal anzusprechen. Denn wenn keiner einen Thread dazu startet, kann auch niemand davon profitieren wenn er mal selber das Problem hat.

btw. Ich meine das Univention eine Koorperation mit HP angekündigt hat - evtl. gibt es da von dieser Seite aus später mal etwas mehr Support für Debian Systeme.

Gruß

Davon würde ich mal ausgehen. Alternativ mal einen Feature-Request bei HP abseilen. Nach meinen letzten Informationen ist das ein Kernel Bug und der lässt sich nur durch einen neuen, funktionierenden Kernel beheben.