Moin Liste, seit Wochen plage ich mich hier mit dem Kompilieren der neuesten Alsa-Treiber rum, in der Hoffnung, dass damit der Sound ueber mein onboard via686a endlich funktioniert. Das Problem ist, dass beim Kompilieren immer modules fuer den Kernel 2.2.16-hessi erzeugt werden, den ich in einem Anfall von Schwaeche mal erzeugt habe, aber schon laengst wieder zugunsten des Original-SuSE 7.0-Kernels aufgegeben habe. Es hat nichts geholfen, in /usr/src/linux/Makefile die Zeile EXTRAVERSION = -hessi zu loeschen und anschliessend sowohl in diesem Verzeichnis als auch in meinem alsa-Source-Verzeichnis ein make clean auszufuehren, so wie mir das von einem Bekannten geraten wurde: Die kompilierten Module sind immer noch fuer den Kernel -hessi. Also, wie bring ich meinem Computer endlich bei, dass er den Kernel -hessi vergessen kann?!? -- cu Hessi, der fuer Hilfe sehr dankbar waere...
Hallo Chris, Chris Hessmann schrieb:
seit Wochen plage ich mich hier mit dem Kompilieren der neuesten Alsa-Treiber rum, in der Hoffnung, dass damit der Sound ueber mein onboard via686a endlich funktioniert.
Funktioniert bei mir bestens ;) (aber nicht die 0.9er, oder?)
Das Problem ist, dass beim Kompilieren immer modules fuer den Kernel 2.2.16-hessi erzeugt werden, den ich in einem Anfall von Schwaeche mal erzeugt habe, aber schon laengst wieder zugunsten des Original-SuSE 7.0-Kernels aufgegeben habe.
Bin jetzt gerade nicht zu Hause... Legt ALSA bein _erstmaligen_ ./configure-Aufruf evtl. eine config.cache an, welche auch bei einem make clean nicht gelöscht wird? Wenn diese Datei existiert, lösche sie in jedem alsa-source-dir. Was passiert, wenn du die tarballs in neue Verzeichnisse entpackst und dort kompilierst?
Es hat nichts geholfen, in /usr/src/linux/Makefile die Zeile EXTRAVERSION = -hessi zu loeschen und anschliessend sowohl in diesem Verzeichnis als auch in meinem alsa-Source-Verzeichnis ein make clean auszufuehren, so wie mir das von einem Bekannten geraten wurde:
Ja ja, die Bekannten ;) SCNR
Die kompilierten Module sind immer noch fuer den Kernel -hessi.
Du meinst nun nur noch die ALSA-Module und nicht mehr den Kernel, oder?
Also, wie bring ich meinem Computer endlich bei, dass er den Kernel -hessi vergessen kann?!? ... cu Hessi, der fuer Hilfe sehr dankbar waere...
Vielleicht hilfts ja. Falls nicht, bitte CC: an tschuer@elchs-kramkiste.de Gruß Thomas -- ./no_signature
Moin Thomas,
onboard via686a endlich funktioniert. Funktioniert bei mir bestens ;) (aber nicht die 0.9er, oder?)
Ehrlich gesagt, weiss ich garnicht genau, was ich bis jetzt fuer Treiber habe, seit Wochen hat er die falsch kompilierten Module im /lib/dingsbums, frueher waren's halt die normalen SuSE 7.0, jetzt sind's die 0.5.10b.
Bin jetzt gerade nicht zu Hause... Legt ALSA bein _erstmaligen_ ./configure-Aufruf evtl. eine config.cache an, welche auch bei einem make clean nicht gelöscht wird? Wenn diese Datei existiert, lösche sie in jedem alsa-source-dir.
Jawoll, die config.cache war da, und sie war wirklich schon ziemlich alt. Nur leider hat loeschen nichts gebracht.
Was passiert, wenn du die tarballs in neue Verzeichnisse entpackst und dort kompilierst?
Gerade ausprobiert, leider keine Aenderung. Daraus schlussfolgere ich jetzt einfach mal, dass sich make die Informationen ueber den aktuellen Kernel nicht aus dem alsa-Source-Dir zieht...nur woher denn sonst?!?
Die kompilierten Module sind immer noch fuer den Kernel -hessi. Du meinst nun nur noch die ALSA-Module und nicht mehr den Kernel, oder?
Natuerlich. Ich kompiliere ja auch nur die alsa-module, der gesamte Kernel mit allen anderen Modulen ist (und soll bleiben) der 2.2.16, der bei SuSE 7.0 dabei ist. -- cu Hessi
Mhh, also da gibt es noch eine include/linux/include/version.h in der auch nochmal die Kernelversion hardcoded drin steht. ;-/ Matthias On Tue, 13 Mar 2001, Chris Hessmann wrote:
Moin Thomas,
onboard via686a endlich funktioniert. Funktioniert bei mir bestens ;) (aber nicht die 0.9er, oder?)
Ehrlich gesagt, weiss ich garnicht genau, was ich bis jetzt fuer Treiber habe, seit Wochen hat er die falsch kompilierten Module im /lib/dingsbums, frueher waren's halt die normalen SuSE 7.0, jetzt sind's die 0.5.10b.
Bin jetzt gerade nicht zu Hause... Legt ALSA bein _erstmaligen_ ./configure-Aufruf evtl. eine config.cache an, welche auch bei einem make clean nicht gelöscht wird? Wenn diese Datei existiert, lösche sie in jedem alsa-source-dir.
Jawoll, die config.cache war da, und sie war wirklich schon ziemlich alt. Nur leider hat loeschen nichts gebracht.
Was passiert, wenn du die tarballs in neue Verzeichnisse entpackst und dort kompilierst?
Gerade ausprobiert, leider keine Aenderung. Daraus schlussfolgere ich jetzt einfach mal, dass sich make die Informationen ueber den aktuellen Kernel nicht aus dem alsa-Source-Dir zieht...nur woher denn sonst?!?
Die kompilierten Module sind immer noch fuer den Kernel -hessi. Du meinst nun nur noch die ALSA-Module und nicht mehr den Kernel, oder?
Natuerlich. Ich kompiliere ja auch nur die alsa-module, der gesamte Kernel mit allen anderen Modulen ist (und soll bleiben) der 2.2.16, der bei SuSE 7.0 dabei ist.
-- cu Hessi
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin Matthias,
Mhh, also da gibt es noch eine include/linux/include/version.h in der auch nochmal die Kernelversion hardcoded drin steht. ;-/
Ich hab zwar keinen Tree /include/linux/include auf meiner Platte, aber unter /usr/src/linux/include/linux gibt es eine version.h, in der folgendes steht: #define UTS_RELEASE "2.2.16" #define LINUX_VERSION_CODE 131600 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) Das sieht eigentlich ganz gut aus und scheint auch nicht mein Problem zu sein... Gibt's denn hier wirklich niemanden, der Linux so gut kennt? Oder ist mein Linux so viel anders als alle anderen? Das muss doch ein simples Problem sein, oder nicht?!? -- cu Hessi
* Chris Hessmann
Moin Thomas,
onboard via686a endlich funktioniert. Funktioniert bei mir bestens ;) (aber nicht die 0.9er, oder?)
Ehrlich gesagt, weiss ich garnicht genau, was ich bis jetzt fuer Treiber habe, seit Wochen hat er die falsch kompilierten Module im /lib/dingsbums, frueher waren's halt die normalen SuSE 7.0, jetzt sind's die 0.5.10b.
Bin jetzt gerade nicht zu Hause... Legt ALSA bein _erstmaligen_ ./configure-Aufruf evtl. eine config.cache an, welche auch bei einem make clean nicht gelöscht wird? Wenn diese Datei existiert, lösche sie in jedem alsa-source-dir.
Jawoll, die config.cache war da, und sie war wirklich schon ziemlich alt. Nur leider hat loeschen nichts gebracht.
Was passiert, wenn du die tarballs in neue Verzeichnisse entpackst und dort kompilierst?
Gerade ausprobiert, leider keine Aenderung. Daraus schlussfolgere ich jetzt einfach mal, dass sich make die Informationen ueber den aktuellen Kernel nicht aus dem alsa-Source-Dir zieht...nur woher denn sonst?!? Vielleich holt sich Alsa Version des laufenden Kernels. Was sagt den #uname -r Hast Du schon mal probiert die Kernel Sourcen neu zu installieren?
Die kompilierten Module sind immer noch fuer den Kernel -hessi. Du meinst nun nur noch die ALSA-Module und nicht mehr den Kernel, oder?
Natuerlich. Ich kompiliere ja auch nur die alsa-module, der gesamte Kernel mit allen anderen Modulen ist (und soll bleiben) der 2.2.16, der bei SuSE 7.0 dabei ist.
Ich wuerden den 2.2.16er nicht nehmen, der hat viele Bugs. Am besten gleich 2.2.18, oder gleich 2.4.2. bye Bruno
* Chris Hessmann schrieb am 13.03.01 um 14:56 Uhr:
Moin Liste,
seit Wochen plage ich mich hier mit dem Kompilieren der neuesten Alsa-Treiber rum, in der Hoffnung, dass damit der Sound ueber mein onboard via686a endlich funktioniert.
Das Problem ist, dass beim Kompilieren immer modules fuer den Kernel 2.2.16-hessi erzeugt werden, den ich in einem Anfall von Schwaeche mal erzeugt habe, aber schon laengst wieder zugunsten des Original-SuSE 7.0-Kernels aufgegeben habe.
Es hat nichts geholfen, in /usr/src/linux/Makefile die Zeile EXTRAVERSION = -hessi zu loeschen und anschliessend sowohl in diesem Verzeichnis als auch in meinem alsa-Source-Verzeichnis ein make clean auszufuehren, so wie mir das von einem Bekannten geraten wurde: Die kompilierten Module sind immer noch fuer den Kernel -hessi.
Also, wie bring ich meinem Computer endlich bei, dass er den Kernel -hessi vergessen kann?!?
Hi Hessi, mach in /usr/src/linux mal ein make mrproper (und vorher die .config sichern!). Dann die .config zurueckkopieren. Noch ein make oldconfig hinterher.. Gruss -Marc -- | ...and don't forget: Linux rulez! | | | | http://www.links2linux.de <-- Von Linux-Usern fuer Linux-User |
Moin Marc,
mach in /usr/src/linux mal ein make mrproper (und vorher die .config sichern!). Dann die .config zurueckkopieren. Noch ein make oldconfig hinterher..
Genau so gemacht, jetzt steh ich da: ./configure im alsa-src sagt mir, dass er meine Kernel-Version nicht herausfinden koennte, evtl. wuerde mir die version.h fehlen (ist tatsaechlich weg). Muss ich jetzt den ganzen Kernel nochmal neu kompilieren (make oldconfig hat mir ja schon angedeutet, dass ich jetzt bitte einen make dep machen soll)? Update: Ich habe mal einfach nen make dep gestartet, danach war die version.h wieder da, jetzt ist make install mit /usr/src/linux/include/linux/module.h:19 linux/modversions.h: Datei oder Verzeichnis nicht gefunden ausgestiegen. Nunja, im Nebenfenster laeuft grad make clean und make bzImage, was anderes bleibt mir jetzt wohl nicht mehr uebrig (oder hab ich jetzt alles vergeigt?!?), hoffentlich funktioniert's dann endlich... -- cu Hessi
Moin,
Nunja, im Nebenfenster laeuft grad make clean und make bzImage, was anderes bleibt mir jetzt wohl nicht mehr uebrig (oder hab ich jetzt alles vergeigt?!?), hoffentlich funktioniert's dann endlich...
buaeh,
On Die, 13 Mär 2001, Chris Hessmann wrote:
Jetzt mag ich nicht mehr.
Kontrolliere, ob der link /usr/src/linux auf das richtige Verzeichnis
zeigt. Dann:
cd /usr/src/linux
cp .config ../.config-<Kernelversion>
make mrproper
cp ../.config-<Kernelversion> .
make dep
$EDITOR Makefile
#
Moin, On Dienstag, 13. M�rz 2001 19:23 Chris Hessmann wrote:
Moin,
Nunja, im Nebenfenster laeuft grad make clean und make bzImage, was anderes bleibt mir jetzt wohl nicht mehr uebrig (oder hab ich jetzt alles vergeigt?!?), hoffentlich funktioniert's dann endlich...
buaeh,
. Jetzt mag ich nicht mehr. Ich hab mit make dep, make clean und make bzImage ein neues Kernel-File erstellt, ihn aber nicht installiert, in der Hoffnung, dass mein System dann endlich akzeptiert, dass 2.2.16 mein Kernel ist: Pustekuchen. Beim ersten Kompilieren zeigt er mir gleich wieder "blabla, module was made for 2.2.16-hessi". zu huelf!! ;(
er eilet, eilet. ;-) Sag mal, was hast Du eigentlich mit den Modulen gemacht, die der letzten Kernel�bersetzung entstammen (Du hast doch bestimmt auch ein make modules modules_install gemacht)? Mach doch mal ein backup von dem entsprechenden Unterverzeichnis unter /lib und sto� die ganze Geschichte nochmal an. Ich bin auch schonmal im Dreieck geh�pft, als depmod -a immer von unaufgel�sten Bez�gen erz�hlt hat, bis ich gemerkt habe, dass es an den alten Modulen lag. Ein Versuch isses wert. :-) Gru� und viel Erfolg, Stephan -- Stephan Hakuli | mailto: stephan@hakuli.de | * GnuPG/PGP-Key * | callto: 01 71 - 651 89 43 | available, please | surfto: http://www.hakuli.de | visit my homepage *Homepage updated: Short survey on SSH-login with 'authorized_keys'*
Am Dienstag, 13. März 2001 14:56 schrieb Chris Hessmann:
Es hat nichts geholfen, in /usr/src/linux/Makefile die Zeile EXTRAVERSION = -hessi zu loeschen und anschliessend sowohl in diesem Verzeichnis als auch in meinem alsa-Source-Verzeichnis ein make clean auszufuehren, so wie mir das von einem Bekannten geraten wurde: Die kompilierten Module sind immer noch fuer den Kernel -hessi.
Im Fall der Fälle würd ich einfach mal die Source-Verzeichnisse des Kernels und der Alsa-Module löschen, beides neue aufspielen und nochmal versuchen. Damit solltest Du in jedem Fall alle Cache-Files und generierten Includes liquidiert haben. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
participants (8)
-
Bruno Semrau
-
Chris Hessmann
-
David Haller
-
Manfred Tremmel
-
Marc Schiffbauer
-
Matthias Weingart
-
Stephan Hakuli
-
Thomas Schürmann