driver modul unloaden

[jano]

Wie kann ich dafür sorgen, dass ein bestimmtes driver-Module beim booten nicht mehr geladen wird?

blacklist sata_mv
in der /etc/modprobe.conf.local hat nicht geholfen.

Gruß

Jan

[Rain_maker]

Fürs Blacklisten nimmt man am besten die entsprechende Blacklist-Datei der (ungenannten) Distribution.

Ich versuche mal gut zu raten, openSUSE?

=> /etc/modprobe.d/blacklist

Das nützt aber alles nichts, wenn besagtes Modul in Abhängigkeit von einem anderen Modul "mit"geladen wird.

Das eigentliche Problem (warum will man dieses Modul blacklisten?) wäre also auch nicht uninteressant.

[jano]

ich habe openSuse 10.3

das modul sata_mv wird standartmäßig für meinen RocketRaid 1820A Controller geladen.
Das raid 5 funktioniert jedoch nichht mit diesem Treiber.
Daher musste ich den Treiber downloaden und kompilieren.
Um das Modul hptmv(neuer Treiber) erfolgreich zu laden, muss erst das Treibermodul sata_mv geunloaded werden, sonst crashed das System und zerschießt dan Raid5.

Eintrag in der /etc/modprobe.d/blacklist hat auch nichts genützt.

Bitte um Hilfe

Gruß

Jan

[Rain_maker]

//Edit:

Blödsinn gepostet


lsmod|grep sata natürlich.

Und ein



grep INITRD_MODULES /etc/sysconfig/kernelauch gleich noch hinterher.

(Wenn es das ist, was ich vermute, dann dürfte die Sache etwas kniffliger werden, vor allem, wenn man sich einen Fallback für alle Notfälle bereithalten möchte bzw. bei/nach einem Kernelupdate).

[jano]

Ausgabe von: lsmod|grep sata



sata_mv 23816 0
sata_promise 16516 0
libata 136776 3 sata_mv,sata_promise,ata_piix


Ausgabe von: grep INITRD_MODULES /etc/sysconfig/kernel


INITRD_MODULES="processor thermal ata_piix sata_mv sata_promise fan jbd ext3 edd"
DOMU_INITRD_MODULES="xennet xenblk"

Ich nehme mal an aus "INITRD_MODULES" muss das sata_mv raus.
Kann ich das einfach editieren, oder muss dann was neu "kompiliert" werden.

Gruß

Jan

[Rain_maker]

1. Du nimmst richtig an.

2. Das wird nun etwas kniffliger, denn der neue Treiber muss

a) in die Initrd eingebunden werden

b) das muss nach jedem Kernelupdate und _vor_ dem darauf folgenden Neustart erneut wiederholt werden

c) wenn man das einmal vergisst, dann wirds lustig.

d) Netz und doppelter Boden ist wohl leider nicht drin, wenn man das heraus nehmen muss.

Wie wurde dieser RAID-Treiber kompiliert? (ich nehme an von Hand und mit make&&make install)

Hast Du einen direkten Downloadlink zu besagtem Treiber?

Vielleicht gibt es eine bessere Lösung als das alles von Hand zu machen.

//Edit:

Welcher Kernel läuft da gerade?



uname -asagt?

Greetz,

RM

[jano]

Hi

1. Auf dem RAID 5 befinden sich keine Daten, nichtmal ein fs.
2. Das System ist auf einer extra Platte installiert.
3. Der Treiber wurde von Hand compiliert, also mit make && make install
d.h. fertiges Modul hptmv.ko liegt in einem Verzeichnis.

Ich habe Testweise vor deinem Post mal das sata_mv aus der /ets/sys/kernel
bei INITRD_MODULES entfernt und /sbin/mkinitrd ausgeführt.
Beim booten wurde trotzdem wieder sata_mv geladen -.-

Wo liegt eigendlich das Problem Linux zu sagen:
Du darfst Treiber sata_mv nie wieder, egal wann, aber NIE laden.
Beim starten sollst du Treiber hptmv laden.

Hier (http://www.molecularbear.com/blog/?p=52)wird exakt das Selbe Problem beschrieben mit exakt dem selben Controller, allerdings hat dort ein "blacklist sata_mv" gereicht.

/edit: 2.6.22.5-31-default

Gruß

Jan

[Rain_maker]

Hier (http://www.molecularbear.com/blog/?p=52)wird exakt das Selbe Problem beschrieben mit exakt dem selben Controller, allerdings hat dort ein "blacklist sata_mv" gereicht.

Wenn ich mir das so durchlese, dann klingt das aber nicht so, als wären die Probleme damit gelöst worden.


UPDATE: doing a full (as opposed to quick) initialization of the RAID5 is fun. It goes through about 1% every minute or two, then somewhere in the mid 60s jumps to completion. But when the OS boots up, the array hasn’t been created - each disk is separate. I then have to go back into the BIOS, set the array up with quick initialization, and then it appears to “stick”. I actually ran the initialization again and checked every 10-15 minutes to try to catch what was happening at the end, but I apparently missed the window; it must zoom through 30% in like 5 minutes. Guess I’ll copy that terabyte to the array overnight and just see if it works.

Aber egal, mach erst mal ein Kernelupdate auf den aktuellen Distributionskernel 2.6.22.18, das erspart Dir so oder so Arbeit, egal ob/wie man das mit dem "falschen" sata_mv hinbekommt.

Greetz,

RM

[jano]

UPDATE: doing a full (as opposed to quick) initialization of the RAID5 is fun. It goes through about 1% every minute or two, then somewhere in the mid 60s jumps to completion. But when the OS boots up, the array hasn’t been created - each disk is separate. I then have to go back into the BIOS, set the array up with quick initialization, and then it appears to “stick”. I actually ran the initialization again and checked every 10-15 minutes to try to catch what was happening at the end, but I apparently missed the window; it must zoom through 30% in like 5 minutes. Guess I’ll copy that terabyte to the array overnight and just see if it works.

Sry mein exakt war ein wenig zu exakt ausgedrückt:rolleyes: das o.g. Prob hatte ich nicht.

Ich habe jetzt in die /etc/syscofig/kernel bei INITRD_MODULES das hptmv Modul zugefügt.
Es wird jetzt zusätzlich zu dem sata_mv Modul beim Start geladen, allerdings dauerte der Bootvorgang wesentlich länger und meine eth0 und eth1 werden nicht mehr erkannt.
Erstaunlicherweise wird das Array jetzt als einzelnes im yast partioner angezeigt.
Dabei wurden anscheinen meine Systemplatte inkl. deren PArtitionen auf sdb umgenannt und das Raid ist jetzt sda...keine Ahnung wieso???

/edit: 10min später--->Raidcontroller beept --->Raid kaputt

Was soll ein Kernelupdate bringen?

Gruß

Jan

[Rain_maker]

Was soll ein Kernelupdate bringen?

Ausser den üblichen Security-Updates und Bugfixes (kann ja auch sein, daß Du hier einem Käferchen aufgesessen bist):

- Für einen eventuellen Bugreport auf bugzilla.novell.com (https://bugzilla.novell.com/index.cgi) eine Basis, die so oder so wahrscheinlich "verlangt" wird, denn die erste Antwort in einem Bugreport wird sein daß Du updaten sollst.

Greetz,

RM

[jano]

ein einfaches "brokenmodules=sata_mv" als Bootoption für eine Neuinstallation hat das Problem gelöst.

Danach Treiber compiliert und in die /etc/sysconfig/kernel unter "MODULES_LOADED_ON_BOOT=hptmv" eingetragen.

--->alles läuft perfekt, Array sofort erkannt, stabil und das System rennt.

Trotzdem danke für die Hilfe

Gruß

Jan