Hallo Guido, Guido Pinkernell wrote:

Tut mir leid, habe übersehen, dass die suse-linux eine deutschsprachige Mailingliste ist. Ich habe hier zwar schon gepostet, bin aber auch auf zweidrei anderen, englischsprachigen Mailinglisten zum Thema Linux. So habe ich glatt den Überblick verloren. [...]

konkret zu deinem Problem kann ich dir nicht weiterhelfen. Ich weiß nur, dass der "normale" Weg, die Kernelsourcen für die Kompilation eines Moduls tauglich zu machen, in /usr/src/linux/README.SUSE beschrieben wird: (1) Install kernel-source.$ARCH.rpm. (2) Change to the /usr/src/linux directory. Configure the kernel (for example, ``make oldconfig'' or ``make cloneconfig'', see HOW TO CONFIGURE THE KERNEL SOURCES). (3) Create files required for compiling external modules: ``make modules_prepare''. (4) Compile the module(s) by changing into the module source directory and typing ``make -C /usr/src/linux M=$(pwd)''. (5) Install the module(s) by typing ``make -C /usr/src/linux M=$(pwd) modules_install''. Damit konnte ich mein VMWare-Modul ohne Probleme kompilieren. Vielleicht hilft dir das! Gruß, Bernhard

On Tuesday 07 December 2004 21:42, Guido Pinkernell wrote:

...

(3) Create files required for compiling external modules: ``make modules_prepare''.

Fehlermeldung:

*** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you may run 'make bzImage', 'make bzdisk', or 'make install'.

jvc:/usr/src/linux # make modules_prepare make: *** No rule to make target `modules_prepare'. Stop. jvc:/usr/src/linux #

(2.4.20 auf SuSE 8.2)

Danke, leider nicht. Aber ich verstehe jetzt einiges mehr.

Zum Beispiel dies (nachfolgend zitiert). Guido ==== quote ======== From: Tuukka Toivonen Newsgroups: comp.os.linux.development.system Subject: Re: Linux kernel module programming... Date: Thu, 12 Aug 2004 09:13:13 +0000 (UTC) In article <2o0qb1F5d3taU1@uni-berlin.de>, Jens.Toerring@physik.fu-berlin.de wrote:

c) your kernel isn't set up correctly for compiling modules, you must have a valid configuration for your kernel and you must have run at least 'make dep' in order to create all of the required header files fitting your running kernel.

That's the usual problem when people try to compile modules. With 2.4.x and older kernels, make oldconfig && make dep With 2.6.x, make oldconfig && make modules_prepare And then modules should compile unless the source tree is messed up, in which case you should make backup of .config and extract a clean source tree.

On Wednesday 08 December 2004 15:10, Werner Flamme wrote:

Guido Pinkernell schrieb am 07.12.2004 21:42:

...

On Tuesday 30 November 2004 21:03, Bernhard Walle wrote:

[snip]

...

Fehlermeldung:

*** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you may run 'make bzImage', 'make bzdisk', or 'make install'.

Das möchte ich nicht als Fehler- sondern als Erfolgsmeldung bezeichnen.

...

jvc:/usr/src/linux # make modules_prepare make: *** No rule to make target `modules_prepare'. Stop. jvc:/usr/src/linux #

Warum tust Du Deinem Kernel nicht den Gefallen, mit 'make bzImage' oder so weiterzumachen, wie er es Dir vorschlägt?

Weils da zu einer anderen Fehlermeldung kommt. Die wird gerade in einem anderen Thread ("ACPIdeaktiviert ...") diskutiert. Außerdem will ich den Treiber nicht in den Kernel hineinkompilieren (um mit make bzImage ein Bootimage des Kernels zu erstellen), sondern als separates Modul lassen. Und meines Wissens macht man das nach make oldconfig mit make prepare für 2.6.x bzw. make dep für 2.4.x. Und make dep gibt hier ebenfalls eine Fehlermeldung, die was mit acpi zu tun hat. Ich bin deshalb hier so vage, weil ich mich wegen dieser zahlreichen Fehlermeldungen entschieden habe, meinen 2.4.20 Kernel auf 2.4.28 aufzurüsten. Guido

Hallo Sören, habe mich lange auf diese Mail nicht gemeldet. Jetzt konnte ich mich wieder um das Problem kümmern. Wie ich in einer anderen Mail in diesem Thread geschrieben habe, ist das Problem wohl nicht spezifisch auf den TI Treiber gemünzt. On Tuesday 30 November 2004 21:33, Sören Wengerowsky wrote:

Hallo,

...

Ich will für mein 2.4.20 auf SuSE 8.2 ein Treibermodul für den TI89-Titanium Rechner installieren, genauer gesagt für das zugehörige USB-Kabel.

Hast du einen Treiber für das Silverlink-Kabel gefunden? Oder für eines der anderen?

USB: http://lpg.ticalc.org/prj_usb/

Würde mich mal interessieren. Der Tilp-Entwickler meinte zu mir damals, dass mein ti-84+ nur mit dem anderen Kabel gehen wird, nicht mit dem usb-teil...

Hm. Im oben genannten Link ist ausdrücklich auch vom Ti-84+ die Rede.

...

Dazu muss der Kernel kompiliert werden. Ich habe also make menuconfig editiert, danach make dep laufen lassen und schließlich make clean bzImage modules modules_install.

Hm... ich hätte das anders gemacht. Da ist übrigens bei SuSE-Kerneln eine README im Source-Verzeichnis. Ansonsten würde ich selber das so machen: make irgendwasconfig make modules_prepare make (evtl mit -C den Pfad angeben) make modules_install (evtl mit -C den Pfad angeben)

Diese Befehle gelten nur für die Treiber, die man nicht in den Kernel hineinkompiliert, sondern nur bei Bedarf aufruft. So solls beim TIUSB Treiber auch sein. Habe das jetzt endlich auch gelernt. Nur was ich immer noch nicht weiss, und da geben mir auch Handbücher und README etc etc keine Auskunft: Wo gebe ich diese make und make modules etc etc an? Mal unter /usr/src/linux, und auch in dem Verzeichnis, wohin ich die heruntergeladenen Treiber ge-untared habe? Wann passiert wo was? Also: "Konfiguriere den Kernel", heisst /usr/src/linux/make menuconfig, hier die Änderungen (wenn überhaupt!) vornehmen, exit und save. Dann ... was?? Zuerst make modules_prepare? Oder in /downloads/tiglusb-1.07/make ? Wenn ich mache, gibts die Fehlermeldung jvc:/downloads/tiglusb-1.07 # make make -f Makefile.tiglusb KDIR=/usr/src/linux make[1]: Entering directory `/downloads/tiglusb-1.07' make[1]: *** No rule to make target `ticable.h', needed by `tiglusb.o'. Stop. make[1]: Leaving directory `/downloads/tiglusb-1.07' make: *** [tiglusb.o] Error 2 jvc:/downloads/tiglusb-1.07 # make clean rm -f Rules.make arch tiglusb.o rm -f *.o core *~ \#* out.log rm -f .tiglusb* jvc:/downloads/tiglusb-1.07 # make cp -pf /usr/src/linux/Rules.make . rm -f arch ln -s /usr/src/linux/arch . make -f Makefile.tiglusb KDIR=/usr/src/linux make[1]: Entering directory `/downloads/tiglusb-1.07' make[1]: *** No rule to make target `ticable.h', needed by `tiglusb.o'. Stop. make[1]: Leaving directory `/downloads/tiglusb-1.07' make: *** [tiglusb.o] Error 2 Oder alle make modules und make modules_install und unter /usr/src/linux? Aber woher weiss make in /usr/src/linux denn, dass da im Downloadverzeichnis ein Treiber auf seine Installation wartet? Fragen über Fragen ... Und ja: Ich habe Handbücher geguckt und ROTFL en masse ... ;) Aber erst mal weiter auf Deine Fragen:

...

Dabei gabs die folgende Errormeldung:

...

make[4]: Entering directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi/utilities' make[4]: Nothing to be done for `all_targets'. make[4]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi/utilities' make[3]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi/utilities' make all_targets make[3]: Entering directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi' gcc -D__KERNEL__ -I/usr/src/linux-2.4.20.SuSE/include -Wall -Wstrict-prototypes-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-sign-compare -finline-limit=2000 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -Os -nostdinc -iwithprefix include -DKBUILD_BASENAME=motherboard -c -o motherboard.o motherboard.c motherboard.c: In function `acpi_motherboard_init': motherboard.c:156: error: `acpi_disabled' undeclared (first use in this function)

Hast du das _ganze_ ACPI disabled?

Nein gar nicht. Lief enabled, und anfangs ganz passabel. Jetzt habe ich ihn ausgeschaltet, weil er das System ziemlich verlangsamt.

Ich hatte das mal teilweise in der .config drin und da kam auch eine ^^^ ähnliche Fehlermeldung..

"was" genau?

Oder hast du ACPI gar nicht disabled bzw. brauchst acpi?

Jetzt ja. Siehe meine andere Mail

...

...

motherboard.c:156: error: (Each undeclared identifier is reported only once motherboard.c:156: error: for each function it appears in.) make[3]: *** [motherboard.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi' make[1]: *** [_subdir_acpi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers' make: *** [_dir_drivers] Error 2

Was ist das für ein Kernel? Lief dieser Kernel schonmal auf deiner Kiste?

Das ist mein Kernel 2.4.20 (auf SuSE 8.2). Einen anderen gibts hier nicht. Guido

Hallo, Am Dienstag, 7. Dezember 2004 21:30 schrieb Guido Pinkernell:

Hallo Sören, habe mich lange auf diese Mail nicht gemeldet. Jetzt konnte ich mich wieder um das Problem kümmern. Wie ich in einer anderen Mail in diesem Thread geschrieben habe, ist das Problem wohl nicht spezifisch auf den TI Treiber gemünzt.

Ja.. es wird wohl eher an der .config liegen..

On Tuesday 30 November 2004 21:33, Sören Wengerowsky wrote:

...

Hallo,

...

Ich will für mein 2.4.20 auf SuSE 8.2 ein Treibermodul für den TI89-Titanium Rechner installieren, genauer gesagt für das zugehörige USB-Kabel.

Hast du einen Treiber für das Silverlink-Kabel gefunden? Oder für eines der anderen?

USB: http://lpg.ticalc.org/prj_usb/

Danke

...

Würde mich mal interessieren. Der Tilp-Entwickler meinte zu mir damals, dass mein ti-84+ nur mit dem anderen Kabel gehen wird, nicht mit dem usb-teil...

Juhuu. BTW: vielleicht solltest du einfach den 2.4.27 Vanilla -Kernel nehmen. Da wirst du diesen Treiber nicht mehr brauchen... _____________ You need this module in the following cases: - kernel 2.4 series < 2.4.27, - kernel 2.6 series < 2.6.6. In the other cases, you don't need it. You can go to the installation section. --------------------------

Hm. Im oben genannten Link ist ausdrücklich auch vom Ti-84+ die Rede.

Super!

...

...

Dazu muss der Kernel kompiliert werden. Ich habe also make menuconfig editiert, danach make dep laufen lassen und schließlich make clean bzImage modules modules_install.

Hm... ich hätte das anders gemacht. Da ist übrigens bei SuSE-Kerneln eine README im Source-Verzeichnis. Ansonsten würde ich selber das so machen: make irgendwasconfig make modules_prepare make (evtl mit -C den Pfad angeben) make modules_install (evtl mit -C den Pfad angeben)

Diese Befehle gelten nur für die Treiber, die man nicht in den Kernel hineinkompiliert, sondern nur bei Bedarf aufruft. So solls beim TIUSB Treiber auch sein. Habe das jetzt endlich auch gelernt. Nur was ich immer noch nicht weiss, und da geben mir auch Handbücher und README etc etc keine Auskunft:

Wo gebe ich diese make und make modules etc etc an? Mal unter /usr/src/linux, und auch in dem Verzeichnis, wohin ich die heruntergeladenen Treiber ge-untared habe? Wann passiert wo was?

Also diese Befehle, die ich oben geschrieben habe, solltest du in dem source-Verzeichnis von deinem Kernel absetzen... aber wie du schon sagtest, ist das wohl nicht nötig.

Also: "Konfiguriere den Kernel", heisst /usr/src/linux/make menuconfig, hier die Änderungen (wenn überhaupt!) vornehmen, exit und save. Dann ... was?? Zuerst make modules_prepare? Oder in /downloads/tiglusb-1.07/make ?

ne, alles in dem Source-Verzeichnis vom Kernel. Also bei SuSE-Kerneln ist das Standardmäßig auf /usr/src/linux gelinkt.

Wenn ich mache, gibts die Fehlermeldung

jvc:/downloads/tiglusb-1.07 # make make -f Makefile.tiglusb KDIR=/usr/src/linux make[1]: Entering directory `/downloads/tiglusb-1.07' make[1]: *** No rule to make target `ticable.h', needed by `tiglusb.o'. Stop. make[1]: Leaving directory `/downloads/tiglusb-1.07' make: *** [tiglusb.o] Error 2 jvc:/downloads/tiglusb-1.07 # make clean rm -f Rules.make arch tiglusb.o rm -f *.o core *~ \#* out.log rm -f .tiglusb* jvc:/downloads/tiglusb-1.07 # make cp -pf /usr/src/linux/Rules.make . rm -f arch ln -s /usr/src/linux/arch . make -f Makefile.tiglusb KDIR=/usr/src/linux make[1]: Entering directory `/downloads/tiglusb-1.07' make[1]: *** No rule to make target `ticable.h', needed by `tiglusb.o'. Stop. make[1]: Leaving directory `/downloads/tiglusb-1.07' make: *** [tiglusb.o] Error 2

Das ist wohl eine Paketabhängigkeit. Du weißt, dass du libticables und libticalc und so brauchst für dein Tilp? Meines Wissens nach gabs da mal RPMs für SuSE dafür. Die solltest du installieren. Ich hatte das auch schonmal alles installiert (aus den Sourcen nur das Tilp, für das andere hatte ich irgendwo RPMs). Bin dann aber leider am fehlenden Support für mein USB-Kabel gescheitert.

Oder alle make modules und make modules_install und unter /usr/src/linux? Aber woher weiss make in /usr/src/linux denn, dass da im Downloadverzeichnis ein Treiber auf seine Installation wartet?

Das hast du beim make irgendwasconfig angegeben. Dass es überhaupt auftaucht, hast du dem make install, das du vorher in dem source-Verzeichnis des usb-Treibers gemacht hast, zu verdanken. Du machst also zuerst in dem Verzeichnis mit den Sourcen von dem USB-Kabel-Treiber make und make install.

Fragen über Fragen ...

Und ja: Ich habe Handbücher geguckt und ROTFL en masse ... ;)

Aber erst mal weiter auf Deine Fragen:

...

...

Dabei gabs die folgende Errormeldung:

...

make[4]: Entering directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi/utilities' make[4]: Nothing to be done for `all_targets'. make[4]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi/utilities' make[3]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi/utilities' make all_targets make[3]: Entering directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi' gcc -D__KERNEL__ -I/usr/src/linux-2.4.20.SuSE/include -Wall -Wstrict-prototypes-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-sign-compare -finline-limit=2000 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -Os -nostdinc -iwithprefix include -DKBUILD_BASENAME=motherboard -c -o motherboard.o motherboard.c motherboard.c: In function `acpi_motherboard_init': motherboard.c:156: error: `acpi_disabled' undeclared (first use in this function)

Hast du das _ganze_ ACPI disabled?

Nein gar nicht. Lief enabled, und anfangs ganz passabel. Jetzt habe ich ihn ausgeschaltet, weil er das System ziemlich verlangsamt.

...

Ich hatte das mal teilweise in der .config drin und da kam auch eine

^^^

...

ähnliche Fehlermeldung..

"was" genau?

Ich weiß es nicht mehr genau. Ich habe es einfach so gelöst, dass ich acpi ganz rausgenommen habe. Das war auch etwas mit motherboard.c error `acpi_disabled` undeclared, AFAIR

...

Oder hast du ACPI gar nicht disabled bzw. brauchst acpi?

Jetzt ja. Siehe meine andere Mail

Ich hab schon gesehen.. und wie Andreas schreibt, liegt es an einem dieser komischen SuSE-Patches.. noch ein Grund mehr, der für einen Vanilla-Kernel spricht ;-)

...

...

...

motherboard.c:156: error: (Each undeclared identifier is reported only once motherboard.c:156: error: for each function it appears in.) make[3]: *** [motherboard.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers/acpi' make[1]: *** [_subdir_acpi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20.SuSE/drivers' make: *** [_dir_drivers] Error 2

Was ist das für ein Kernel? Lief dieser Kernel schonmal auf deiner Kiste?

Das ist mein Kernel 2.4.20 (auf SuSE 8.2). Einen anderen gibts hier nicht.

Wie gesagt, ich empfehle, solltest du das Problem hier nicht hinbekommen, einfach den 2.4.27-Vanilla-Kernel zu nehmen. Der sollte sich problemlos mit der .config von jetzt und der kleinen Änderung (tiusb) installieren lassen. Gruß Sören

Guido Pinkernell schrieb:

Es folgt jetzt ein Auszug aus der neuen Fehlermeldung, danach die alte:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.20.SuSE/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-sign-compare -finline-limit=2000-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -nostdinc -iwithprefix include -DKBUILD_BASENAME=dmi_scan -c -o dmi_scan.o dmi_scan.c dmi_scan.c:401: error: redefinition of `local_apic_kills_bios' dmi_scan.c:319: error: `local_apic_kills_bios' previously defined here

Das ist die eigentliche Fehlermeldung. Da ist irgendeine Funktion oder Konstante namens local_apic_kills_bios in der Datei dmi_scan.c definiert, die aber vorher schon mal woanders definiert wurde.

dmi_scan.c: In function `dmi_decode': dmi_scan.c:1103: warning: unused variable `data' dmi_scan.c: At top level: dmi_scan.c:319: warning: `local_apic_kills_bios' defined but not used dmi_scan.c:598: warning: `force_acpi_pci' defined but not used make[1]: *** [dmi_scan.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.20.SuSE/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 jvc:/usr/src/linux #

Das danach sind noch ein paar Warnungen, die aus derselben Datei stammen, aber im Grunde kein Problem darstellen müssen. In Bezug auf ACPI sehe ich da bloß, dass etwas namens force_acpi_pci definiert, aber nicht verwendet wird. Da du ACPI komplett gekillt hast,eigentlich auch nicht ungewöhnlich. Der Abruch wurde durch den Fehler oben verursacht, nicht durch diese Warnungen. Dass ACPI und APIC zwei ziemlich unterschiedliche Sachen sind, weisst du? APIC=Advanced Programmable Interrupt Controller, hat auch was mit der Interrupt-Verteilung zu tun. Wenn du Probleme mit der Interrupt-Verteilung hattest, kann man den APIC beim booten mit der Option "noapic" abschalten. Aber dazu müsste man den Kernel auch erst mal kompiliert kriegen :-) Schau mal mit einem grep -r local_apic_kills_bios /usr/src/linux-2.4.20.SuSE/* wo diese Definition noch auftaucht, vielleicht kommen wir so dem Verursacher näher. Bye, Andreas

Guido Pinkernell wrote:

Voila: jvc:/usr/src/linux # grep -r local_apic_kills_bios /usr/linux-2.4.20.SuSE/* grep: /usr/linux-2.4.20.SuSE/*: No such file or directory jvc:/usr/src/linux # grep -r local_apic_kills_bios /usr/src/linux-2.4.20.SuSE/* /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c:static int __init local_apic_kills_bios(struct dmi_blacklist *d) /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c:static int __init local_apic_kills_bios(struct dmi_blacklist *d) /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c: { local_apic_kills_bios, "Dell Inspiron", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c: { local_apic_kills_bios, "Dell Latitude", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c: { local_apic_kills_bios, "IBM Thinkpad T20", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.orig:static int __init local_apic_kills_bios(struct dmi_blacklist *d) /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.orig: { local_apic_kills_bios, "Dell Inspiron", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.orig: { local_apic_kills_bios, "Dell Latitude", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.orig: { local_apic_kills_bios, "IBM Thinkpad T20", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.rej:+ { local_apic_kills_bios, "Dell Inspiron", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.rej:+ { local_apic_kills_bios, "Dell Latitude", { /usr/src/linux-2.4.20.SuSE/arch/i386/kernel/dmi_scan.c.rej:+ { local_apic_kills_bios, "IBM Thinkpad T20", { jvc:/usr/src/linux #

Sieht so aus, als ob das im wesentlichen nur in der einen Datei dmi_scan.c sei. Beim nochmal nachlesen hab' ich auch gesehen, dass das auch in deiner ersten Fehlermeldung schon drinstand, wo die doppelte Definition ist. In dem hier erkenne ich allerdings, dass da offensichtlich ein Patch drübergelaufen ist, der nicht so astrein funktioniert hat. Daher kommt wohl die Datei dmi_scan.c.rej. Daraus kann ich allerdings noch nicht so viel erkennen, schick mir mal die drei Dateien dmi_scan.c, dmi_scan.c.orig und dmi_scan.c.rej, vielleicht kann ich durch Vergleiche rauskriegen, was da schiefgelaufen ist. Bye, Andreas

Sören Wengerowsky wrote:

Das Problem liegt nun nur in dieser einen Datei dmi_scan.c. Die vermutlich durch einen nicht ganz perfekten Patch kaputtgepatched wurde...

Ist das der neuste Kernel via YOU?

Oben konnte man aus einem Verzeichnis-Namen abelsen, dass es 2.4.20-SuSE ist...

Ansonsten glaube ich, dass dmi_scan etwas mit dieser Speed-Step-Technologie von den Intel-Prozessoren zu tun hat. Daher würde ich sagen, du solltest die .config nochmal auf soetwas hin durchforsten, wenn du Speedstep nicht brauchst..

Leider nicht, DMI = Desktop Management Interface. Damit lassen sich einige Informationen über die Hardware abrufen, also z.B. Hersteller und Revisionsnummern einzelner Komponenten wie Mainboard, BIOS, Netzwerkkarten usw. Vor allem für den Einsatz über's Netz (Remote-Management) gedacht, aber auch lokal verwendbar. Ein Teil der Meldungen, die Linux beim booten über BIOS und Hardware bringt, stammen m.E. daher. Ich glaube nicht, dass man das komplett loswerden kann. Bye, Andreas

On Wednesday 08 December 2004 15:45, Sören Wengerowsky wrote:

Hallo,

Am Mittwoch, 8. Dezember 2004 14:59 schrieb Andreas Heinlein:

...

Sören Wengerowsky wrote:

...

Das Problem liegt nun nur in dieser einen Datei dmi_scan.c. Die vermutlich durch einen nicht ganz perfekten Patch kaputtgepatched wurde...

Ist das der neuste Kernel via YOU?

Soweit ich mich erinnern kann, wurde mir per YOU bislang kein Kernelupdate angeboten. Und ich habe auch nicht "geupdated".

...

Oben konnte man aus einem Verzeichnis-Namen abelsen, dass es 2.4.20-SuSE ist...

Schon klar.. ich weiß aber nicht, ob Suse da nicht in der Version vorangeschritten ist mit den YOU-Kerneln.

Ich weiß nur, dass die 8.2 standardmäßig mit 2.4.20 daherkommt... Aber bei der 9.1 wurde ja auch von 2.6.4-52 bis 2.6.5-7-111 per YOU geupdatet. Da war ich mir nicht sicher, ob es für die 8.2 nicht vielleicht auch mal einen 2.4.21 oder so im YOU gab.

Laut Bootlog ist das ein 2.4.20 Kernel. Und wie gesagt, mehr gabs nicht.

Tjoa.. dann entweder da eine korrigierte Datei einsetzen, oder einen anderen Kernel verwenden..

Werde ich dann mal probieren. Aber nicht jetztgleich, habe noch andere wichtige Dinge zu tun. Guido