Hallo, ich habe mir das Debian Paket der Kernel Sourcen 2.4.20-5 installiert. Konfiguration und Übersetzung des Kernels laufen durch. Nach dem aufruf 'depmod -a' bringt er mir allerdings unresolved Symbols in allen (glaub ich) Modulen. Hab ich da etwas in der Kernelkonfiguration übersehen? Oder woher könnte dieser Effekt kommen?
achso... System: Woody / auf unstable geupgraded..
Beste Grüße
Thomas Noßmann
Hallo! Am 20. Februar 2003 schrieb Thomas Nossmann:
'depmod -a' bringt er mir allerdings unresolved Symbols in allen (glaub ich)
Hast du auch die Datei System.map in Verzeichnis /boot aktualisiert bzw. "make bzlilo" ausgeführt?
Freundlich grüßend,
Erik
Hallo, > > 'depmod -a' bringt er mir allerdings unresolved Symbols in > allen (glaub ich) > Hast du auch die Datei System.map in Verzeichnis /boot > aktualisiert bzw. > "make bzlilo" ausgeführt?
ich habe ein "make bzImage" gemacht und anschließend
cp -uv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.20 cp -uv /usr/src/linux/System.map /boot/System.map-2.4.20
damit sollte auch die aktuelle System.map in /boot liegen.
Beste Grüße, Thomas Noßmann
On 21.02.03 Erik Schanze (schanzi_@gmx.de) wrote:
Am 20. Februar 2003 schrieb Thomas Nossmann:
Hallo!
'depmod -a' bringt er mir allerdings unresolved Symbols in allen (glaub ich)
Hast du auch die Datei System.map in Verzeichnis /boot aktualisiert bzw. "make bzlilo" ausgeführt?
System.map ist nur notwendig, wenn ich den Kernel debuggen will und also Symbole brauche. Direkt aus dem Kernel kann man die nicht auslesen, da der komprimiert ist. Aus den Modulen hingegen kann ich die Debugging-Symbole direkt auslesen.
H.
On 20.02.03 Thomas Nossmann (t.nossmann@web.de) wrote:
Hallo,
ich habe mir das Debian Paket der Kernel Sourcen 2.4.20-5 installiert. Konfiguration und Übersetzung des Kernels laufen durch. Nach dem aufruf 'depmod -a' bringt er mir allerdings unresolved Symbols in allen (glaub ich) Modulen.
Wie und wann rufst Du das genau auf? IIRC wird beim Aufruf von "make modules_install" auch depmod mit den passenden Parameter. aufgerufen. Siehst Du die da auch schon?
Hab ich da etwas in der Kernelkonfiguration übersehen? Oder woher könnte dieser Effekt kommen?
Daß er in den falschen Pfaden nach den Modulen sucht, die die Sysbole bereitstellen sollten.
Hilmar, der hofft, daß seine Mails bald durch den Virenscanner kommen
Hallo, Hat aber wiedermal lange gedauert, eh die Mails durch waren :-)
> dem aufruf > 'depmod -a' bringt er mir allerdings unresolved Symbols in > allen (glaub ich) > Modulen. > Hab ich da etwas in der Kernelkonfiguration übersehen? Oder > woher könnte > dieser Effekt kommen? > hab inzwischen rausgefunden, das nur das Symbol __mmx_memcpy nicht gefunden wird. zu welcher Kerneloption gehört das? Mein Kernel ist für den K7/Athlon optimiert. Auch eine Optimierung auf i386 brachte das selbe Ergebnis...
Beste Grüße, Thomas Noßmann
On Tue, Feb 25, 2003 at 02:17:36PM +0100, Thomas Nossmann wrote:
Hallo,
Hi Thomas,
Hat aber wiedermal lange gedauert, eh die Mails durch waren :-)
> dem aufruf > 'depmod -a' bringt er mir allerdings unresolved Symbols in > allen (glaub ich) > Modulen. > Hab ich da etwas in der Kernelkonfiguration übersehen? Oder > woher könnte > dieser Effekt kommen? >hab inzwischen rausgefunden, das nur das Symbol __mmx_memcpy nicht gefunden wird. zu welcher Kerneloption gehört das? Mein Kernel ist für den K7/Athlon optimiert. Auch eine Optimierung auf i386 brachte das selbe Ergebnis...
_mmx_memcpy wird verwendet, wenn CONFIG_USE_3DNOW gesetzt ist... Frag mich aber bitte nicht, hinter welchem Eintrag bei make menuconfig sich der versteckt.
Ciao, Tobias
Hallo Thomas,
On Tue, Feb 25, 2003 at 03:32:01PM +0100, Tobias Koenig wrote:
On Tue, Feb 25, 2003 at 02:17:36PM +0100, Thomas Nossmann wrote:
Hallo,
Hi Thomas,
hab inzwischen rausgefunden, das nur das Symbol __mmx_memcpy nicht gefunden wird. zu welcher Kerneloption geh?rt das? Mein Kernel ist f?r den K7/Athlon optimiert. Auch eine Optimierung auf i386 brachte das selbe Ergebnis...
_mmx_memcpy wird verwendet, wenn CONFIG_USE_3DNOW gesetzt ist... Frag mich aber bitte nicht, hinter welchem Eintrag bei make menuconfig sich der versteckt.
Bei der CPU-Auswahl werden einige dieser CONFIG_USE_* - Optionen gesetzt - je nachdem, was die CPU laut Datenblatt kann.
Ein Verweis auf mmx_* sollte aber nicht reinkommen, wenn Du fuer 386 baust; hast Du auch alle Module neu uebersetzt?
Holger
Hallo, > Bei der CPU-Auswahl werden einige dieser CONFIG_USE_* - > Optionen gesetzt > - je nachdem, was die CPU laut Datenblatt kann. > > Ein Verweis auf mmx_* sollte aber nicht reinkommen, wenn Du fuer 386 > baust; hast Du auch alle Module neu uebersetzt?
Alle Module habe ich neu ubersetzt. Vor dem make modules_install habe ich auch das Modulverzeichnis geloscht und das ganze neu gebootet. Danach bringt depmod -a jedoch immer noch die Meldung, das das Symbol namens _mmx_memcpy nicht aufgelost werden kann. Eine Ubersetzung des 2.4.20 Kernels auf einer zweiten Maschine (dort mit K6-2) bringt diese Fehler nicht. Selbst mit identischer .config kommt auf der einen Maschine der Fehler, auf der anderen nicht. Konnte dieses Problem eventuell an der Compilerversion liegen? Einmal verwende ich 2.95 (ohne Fehlermeldung) und einmal 3.2 (mit Fehlermeldung).
Beste Gru?e, Thomas No?mann
On 26.02.03 Thomas Nossmann (t.nossmann@web.de) wrote:
Hallo,
Eine Ubersetzung des 2.4.20 Kernels auf einer zweiten Maschine (dort mit K6-2) bringt diese Fehler nicht. Selbst mit identischer .config kommt auf der einen Maschine der Fehler, auf der anderen nicht. Konnte dieses Problem eventuell an der Compilerversion liegen? Einmal verwende ich 2.95 (ohne Fehlermeldung) und einmal 3.2 (mit Fehlermeldung).
Du verwendest dieselbe .config auf anderer CPU? Hmm, sollte nicht so das Problem darstellen, wenn der Kernel dann nicht auf der Maschine laufen soll. Bloß sollte depmod davon erstmal nichts merken... Weiter: gcc 2.95.x immer noch der offizielle Kernelcompiler ist (also der, der vom Kernelentwicklerteam verwendet wird). Wenn Du nicht unfreiwillig Beta-Tester spielen willst, verwendest Du den.
Beste Gru?e,
Versuch mal, Deine Umlaute korrekt zu kodieren.
H.
lug-dd@mailman.schlittermann.de
-
Erik Schanze -
Hilmar Preusse -
Holger Dietze -
Thomas Nossmann -
Tobias Koenig