Iceweasel lahmt

[Goodspeed]

Was spuckt denn dmesg mach dem missglückten Laden aus? Möglicherweise hast Du zum bauen des Modules nur eine andere GCC Version genommen, als der Kernel ... was sich u.U. derart äußert ...

 

[Aqualung]

linux:/home/user# modprobe nvidia
FATAL: Error inserting nvidia (/lib/modules/2.6.25-custom/kernel/drivers/video/nvidia.ko): Invalid module format

Hast Du einen zum laufenden Kernel passenden, korrekt konfigurierten Kernel-Source-Tree installiert, d.h. zeigt

/lib/modules/`uname -r`/build

auf ein Verzeichnis, in dem sich die aktuelle .config nebst header etc. befindet?

 

[wasserschlange]

dmesg sagt

nvidia: disagrees about version of symbol struct_module

Ich habe dann auch mal versucht den Treiber für meinen alten Kernel (2.6.24) zu intsallieren. Das ging auch, aber brachte die selbe Fehlermeldung.

Lustigerweise hat diese Aktion mir meine xorg.conf verhunst: Amerikanisches Tastaturlayout...
Hab das jetzt erstmal wieder so hingebogen.
Aber, selbst, wenn ich jetzt den Treiber wieder für meinen 2.6.25er Kernel iinstalliere, sieht die xorg.conf hinterher genauso aus, wie wenn ich das für den 2.6.24er mache und da gibt es schon ein paar Unterschiede.

Hast Du einen zum laufenden Kernel passenden, korrekt konfigurierten Kernel-Source-Tree installiert, d.h. zeigt

/lib/modules/`uname -r`/build

auf ein Verzeichnis, in dem sich die aktuelle .config nebst header etc. befindet?

Ja, ist alles da.

 

[Goodspeed]

Tante Google sagt zu der Meldung, dass die verlinkten kernel-header nicht zum Kernel selbst passen ...
"2.6.25-custom" ist ja nun auch was "Selbstgefrickeltes" ... mal nen Debian-Standardkernel + Headers probiert?

 

[Aqualung]

dmesg sagt

nvidia: disagrees about version of symbol struct_module

was sagt

modinfo nvidia

vs.

modinfo $(lsmod  | tail -1 | awk '{ print $1}')

Im erwähnten Verzeichnis die .config sichern, dann ein

make mrproper

Dann die .config wieder reinkopieren. Anschliessend den Kernel neu bauen.
Dann sollte der Installer wuppen.

 

[wasserschlange]

mal nen Debian-Standardkernel + Headers probiert?

Ja, gerade eben und der hat funktioniert...hm...
Das heißt wohl: Kernel neu basteln.
Aber: Die Autokonfiguration hat mir wieder alles verhunzt. Musste dann den X-Server wieder neu konfigurieren. *grml*

Ich frage mich bloß, was denn an meinem eigenen Kernel so schlecht konfiguriert ist. Ich habe nämlich die Konfiguration des Debian-Standardkernels übernommen und nur leicht abgeändert (Prozessortyp, Preemption Model).
Na gut, ich probiere das nochmal.

 

[marcellus]

Bah was macht ihr es so kompliziert?

Allein den kernel anzupassen und bisschen drinnen herumzustirdeln bringt dir weder performance noch stabilität, bleib bei debian beim standard kernel, sonst kannst du dir uu das leben richtig schwer machen.

Der proprietäre nvidia trieber ist ein shell script, ich hab zwar keine ahnung wie du auf

CC=gcc-[version] sh NVIDIA-Linux-x86-173.14.09-pkg1.run -k $(uname -r)

kommst, aber wie wärs mit

chmod +x NVIDIA-Linux-x86-173.14.09-pkg1.run ; #./NVIDIA-Linux-x86-173.14.09-pkg1.run --help

Da sind meines wissens auch vorkompilierte kernelmodule, debs rpms usw drinnen.


Ist vllt eine dumme frage, aber sollte der nvidia treiber nicht auch in den non free repos drinnen sein? Wär das nicht mal ein Wink?

 

[wasserschlange]

Allein den kernel anzupassen und bisschen drinnen herumzustirdeln bringt dir weder performance noch stabilität, bleib bei debian beim standard kernel, sonst kannst du dir uu das leben richtig schwer machen.

Also ich hatte eigentich noch nie wirklich Probleme mit eigenen Kerneln.
Außerdem muss ich mir nen eigenen Kernel bauen, weil ich ein bisschen Echtzeitkapazität brauche und die Treiber für meine externe USB-Karte noch nicht offiziell im Kernel enthalten sind.


CC=gcc-[version], weil die gcc-Version, mit dem der Kernel kompiliert wurde sich evtl. von der unterscheidet, die das NVIDIA-Skript benutzen will.

-k $(uname -r), damit das Modul auch wirklich für den laufenden Kernel gebaut wird.


So...ich habe gestern nochmal den 2.6.25er neu gebaut.
Dadurch ist schonmal die Sache mit der gcc-Version weggefallen.
Und: Die Sache funktioniert.
ABER: die X-Autokonfiguration von NVIDIA ist grauenvoll (oder ich bediene die falsch?!). Bei mir sind jetzt die Schriften in X irgendwie teils größer, teils genauso und das Tastaturlayout musste ich auch erstmal wieder auf pc105 umstellen...

Na ja, dafür läuft Neverball flüssig!

Ich werd X einfach nochmal grundlegend neu konfigurieren.

 

[Goodspeed]

Ein Grund mehr, warum ich lieber die nvidia-Pakete aus unstable und den module-assistant nutze ...

 

[marcellus]

Wenn du dir bei einer binary distribution einen eigenen kernel baust hast du einfach gewisse Probleme. Was würde dagegensprechen die Treiber für deine externe USB-Karte als modul zu bauen und dann in den laufenden kernel nachzuladen?

Dann wie gesagt den nvidia treiber aus deinem Packet manager, das hat auch den vorteil, das du dich um updates nicht selber kümmern musst und dein X server wird nicht so zusammengestaucht, weil im normalfall nicht die xorg.conf von nvidia verwendet wird sondern eine distributionsspezifische.

Echtzeitfähigkeit ist auch so eine sache, die du nur mit einem selbst gebauten kernel nicht erreichen kannst. Es gibt für solche zwecke ein realtime suse und redhat, mit sicherheit auch andere, aber solangs nicht gefordert wird würd ich auf echtzeifähigkeit getrost verzichten.

Aber wenn du latenzen abbauen willst schau dir mal latencytop an.

 

[wasserschlange]

Wenn du dir bei einer binary distribution einen eigenen kernel baust hast du einfach gewisse Probleme.

Ja, das mag stimmen. Aber mir macht das Kernelbasteln einfach auch bissl Spaß.
Und solange sich die Problemchen im erträglichen Bereich bewegen, ist das, denke ich, ok.

Was würde dagegensprechen die Treiber für deine externe USB-Karte als modul zu bauen und dann in den laufenden kernel nachzuladen?

Das Problem ist, dass der Treiber eigentich schon im Kernel enthalten ist, aber noch nicht korrekt funktioniert.
Deshalb muss die ganze Sache gepatcht werden.
Ich denke, das funktioniert das mit dem extra Modul nicht oder?

Dann wie gesagt den nvidia treiber aus deinem Packet manager

Die befinden sich dann logischweise in non-free (zumindest der unfreie Teil).
Ich werd das mal ausprobieren.

[...]aber solangs nicht gefordert wird würd ich auf echtzeifähigkeit getrost verzichten.

Na ja, ich arbeite mit teilweise Midi-Keyboard. Und das läuft eigentlich auch "latenzfrei" mit meinen Kerneln (soft realtime).
Hab aber noch nie einen Vergleichstest gemacht.

Es gibt für solche zwecke ein realtime suse und redhat, mit sicherheit auch andere,

Weiß ich, aber ich denke, aber ich möchte irgendwie keine spezielle Audiodistri, wie z.B. Jacklab verwenden.
Mein Debian gefällt mir halt so gut
Außerdem kann man den RT-Patch für den Linux-Kernel ja auch selbst anbringen. Für 2.6.25 ist der nur noch nicht raus.

Aber wenn du latenzen abbauen willst schau dir mal latencytop an.

Ich werd mal ein auge drauf werfen.

So..., dass ist jetzt hier alles ganz schön abgedriftet...
Aber vielen Dank erstmal für die hilfreichen Tipps.
Ich check mal die Nvidia-Treiber aus dem APT-Repository aus.

 

[wasserschlange]

Ich check mal die Nvidia-Treiber aus dem APT-Repository aus.

Pustekuchen... Im moment gibt's die entsprechenden Pakete in Testing nicht.
Und auf einen Testing/Unstable-Mix lass ich mich definitiv nicht ein.
Also doch wieder alles selber machen.

 

[marcellus]

Ich verwend zwar kein debian, aber die logik sagt mir doch das die treiber im non-free sein werden egal ob testing, unstable oä.

 

[wasserschlange]

Das Debian-Wiki sagt eindeutig, dass es die Pakete in Testing zur Zeit nicht gibt.
Na ja, ist jetzt kein Weltuntergang.