"Probleme" mit einem Kernelmodul

[deMalte]

Hallo Leute,
ich stehe gerade vor einem kleinen Problem.
Ich arbeite als Hiwi an einem Institut der Uni, an der ich studiere als Helfer des Administrators. Eine meiner letzten Aufgaben war, eine Temperatur-Kontrollroutine an den Rechnern im Serverraum einzurichten. Da jetzt speziell in den Sommermonaten ein Totalschaden entstehen könnte, falls die Klimaanlage ausfällt etc....
Meine bisherige Lösung sieht so aus, dass ich ganz einfach lm-sensors installiert habe und n kleines Script eingerichtet habe, welches sensors auswertet und überprüft, ob irgendwo "ALARM" in der Ausgabe von sensors steht. Das ist ja nur, wenn einer der Werte außerhalb der Toleranz liegt. Wenn dem so ist, bekommen alle Verantwortlichen Mitarbeiter ne Mail mit der Warnung. Das Script wird alle 5 Minuten per Cronjob aufgerufen und funktioniert soweit einwandfrei. Hätte man vielleicht auch schöner lösen können, aber hey, ich bin ja kein Profi
Nun gibt es aber folgendes Problem. Jedes mal wenn sensors ausgeführt wird, erscheinen in dmesg folgende Warnungen:

hwmon-vid: requested unknown VRM version
hwmon-vid: requested unknown VRM version

Und zwar pro Aufruf genau zweimal... Ist jetzt ja prinzipiell nicht die Welt, aber so werden doch die Logs ziemlich unübersichtlich, wenn alle paar Minuten zwei solche Meldungen hinzukommen. Beim suchen im Web nach dem Fehler bin ich eigentlich nur letztendlich auf den Quelltext des hwmon-vid Modules gestoßen. Denn das sorgt ja letztendlich dafür, dass die Meldung ausgegeben wird. Nun hab ich nichts hilfreiches gefunden, um irgendwie dafür zu sorgen, dass dem die VRM-Version bekannt wird (Was auch immer das ist...). Demnach hatte ich die Idee, mir die hwmon-vid.c mal zu kopieren und manuell so nachzubearbeiten, dass der halt einfach nichts ausgibt, sondern nur ans Programm zurückgibt, dass da was nicht läuft. Ist sicher auch alles andere als sauber, aber ich scheitere jetzt schon daran, dass ich nicht weiß, wie ich jetzt so eine isoliert vorliegende *.c zu einem funktionierenden *.ko machen kann, welches ich dann an Stelle des alten Moduls setzten kann. Seh ich das richtig, dass das so garnicht geht und ich quasi in den aktuellen Kernelsourcen den Treiberquelltext ändern müsste und danach mit "make modules" alles neu bauen müsste damit das klappt? Könnt ihr mir da aus der Klemme helfen, bzw. habt eventuell eine bessere Idee? Wenn ihr sonst noch Infos braucht, fragt an, dann stell ich die sofort rein! Hoffe ich bin im richtigen Forum?

MfG Malte

 

[Gast1]

Seh ich das richtig, dass das so garnicht geht und ich quasi in den aktuellen Kernelsourcen den Treiberquelltext ändern müsste und danach mit "make modules" alles neu bauen müsste damit das klappt?

Nein, das ist nicht nötig, man kann problemlos einzelne Module "out of tree" übersetzen, meist muss make aber explizit mit den passenden Optionen aufgerufen werden um die entsprechende Buildumgebung zu finden.

make -C /lib/modules/(uname -r)/build M=$(pwd) modules

passt meistens.

 

[deMalte]

Okay, habs mal ausprobiert.
Eventuell hab ich da auch was fehlinterpretiert, aber so wie ich es jetzt mal gemacht habe, klappts noch nicht.

vomendt@pc07:~/ARBEIT/Sensoren/dmesg-fehler> make -C /lib/modules/2.6.16.60-0.39.3-smp/build M=/nfshome/vomendt/ARBEIT/Sensoren/dmesg-fehler hwmon-vid.c
make: Entering directory `/usr/src/linux-2.6.16.60-0.39.3-obj/x86_64/smp'
make -C ../../../linux-2.6.16.60-0.39.3 O=../linux-2.6.16.60-0.39.3-obj/x86_64/smp hwmon-vid.c
make[2]: Nothing to be done for `/nfshome/vomendt/ARBEIT/Sensoren/dmesg-fehler/hwmon-vid.c'.
make: Leaving directory `/usr/src/linux-2.6.16.60-0.39.3-obj/x86_64/smp'
vomendt@pc07:~/ARBEIT/Sensoren/dmesg-fehler>

 

[Gast1]

Lies noch mal _genau_ was ich geschrieben habe.

 

[deMalte]

Hmm nenn mich langsam und begriffsstutzig, aber ich weiß wirklich nicht, was du grade genau meinst? Sollte ich nicht einfach die entsprechenden Pfade und den Modulnamen angeben?

 

[Gast1]

make -C /lib/modules/(uname -r)/build M=$(pwd)[B] modules[/B]

 

[deMalte]

Achsoo, okay.
Das führt dann allerdings zu Folgendem:

vomendt@pc07:~/ARBEIT/Sensoren/dmesg-fehler> make -C /lib/modules/2.6.16.60-0.39.3-smp/build M=/nfshome/vomendt/ARBEIT/Sensoren/dmesg-fehler modules
make: Entering directory `/usr/src/linux-2.6.16.60-0.39.3-obj/x86_64/smp'
make -C ../../../linux-2.6.16.60-0.39.3 O=../linux-2.6.16.60-0.39.3-obj/x86_64/smp modules
/usr/src/linux-2.6.16.60-0.39.3/scripts/Makefile.build:17: /nfshome/vomendt/ARBEIT/Sensoren/dmesg-fehler/Makefile: No such file or directory
make[3]: *** No rule to make target `/nfshome/vomendt/ARBEIT/Sensoren/dmesg-fehler/Makefile'.  Stop.
make[2]: *** [_module_/nfshome/vomendt/ARBEIT/Sensoren/dmesg-fehler] Error 2
make[1]: *** [modules] Error 2
make: *** [modules] Error 2
make: Leaving directory `/usr/src/linux-2.6.16.60-0.39.3-obj/x86_64/smp'
vomendt@pc07:~/ARBEIT/Sensoren/dmesg-fehler>

Heißt das jetzt, dass ich jetzt extra ein Makefile anlegen muss?

 

[Gast1]

*ARGL*

Ohne Makefile macht ein make _wenig_ Sinn.

Das passende Makefile muss natürlich auch vorhanden sein, findet sich im Ordner, wo auch die entsprechenden Quellcodedateien her sind.

GGf. muss es noch zusammengestutzt werden, sonst baut man alles, was in dem jeweiligen Ordner ist (= alles löschen, was nichts mit dem Modul zu tun hat, welches man bauen will).

 

[deMalte]

Upps, entschuldige!
Ich hab da noch wenig bis garkeine Ahnung von.
Mit sowas ärger ich mich halt gerade zum ersten Mal rum.
Aber danke für deine Hilfe!
Jetzt hatt es funktioniert.
Ich werde mal das alte Modul sichern, dann entladen, dann ersetzten und schließlich neu laden.
Mal schaun ob der Server das überlebt mit mit

Danke nochmal!

 

[Gast1]

Wenn Du das Modul in /lib/modules/*Kernelversion*/updates/ kopierst (und depmod ausführst), dann ist Ersetzen unnötig.

 

[deMalte]

Das hört sich wesentlich sauberer an!
Bei mir existiert ../updates noch nicht, wenn ich das jetzt anlege und das da reinkopiere, funktioniert das dann auch, oder müsste man da erst noch mehr einrichten?