Re: Probleme mit externer USB 2 Platte -- Problem behoben??
duneldaion@web.de wrote:
Hallo,
ich habe ein aehnliches Problem: Externe Festplatte in USB-Gehaeuse (von Gensyslogic). Kernel ist 2.6.5-7.75-default (aus online-update). Das Geraet wird erstmal erkannt und unter /media/usb-storage-odd-Genesyslogic-USBMassStorageDevice:0:0:0p1 ein Verzeichnis angelegt.
Wenn ich das richtig verstehe, muss nur die Zeile mit "+ udelay(300)" einegfuegt werden, oder? Was ist mit dem Rest, wo muss der hin??
Richtig (aber ohne das "+" natürlich)
Das hatte ich nauterlich gleich mal stehen gelassen...
Danach den Kernel bzw. das Module neu kompilieren.
Am liebsten nur das eine Modul einzeln - wie mach ich das nochmal?
Gehe nach /usr/src/linux bzw. in das Verzeichnis, wo deine Kernel Sourcen liegen, dann: #make modules && make modules_install Das sollte reichen.
Das hat bei mir geholfen. Ich habe es allerdings nicht mit einem Suse Kernel gemacht sonder mit einem 'normalem' Kernel, sollte aber im Prinzip genau gleich funktionieren.
Danach hatte ich, bislang, keine weiteren Probleme. Durchsatz liegt bei ca. 13Mb/s. Ist nicht toll aber auch nicht schlecht.
Wenn das auch nicht hilft, versuch mal ein Downgrade auf USB 1 (wenn die Geschwindigkeit nicht problematisch ist).
Ist schon ein wenig unpraktisch - es geht um eine Backupplatte (Level 0 ca. 50 GB, inkrementell 1-2 GB).
Besten Dank schonmal,
Mathias
Hallo,
ich habe ein aehnliches Problem: Externe Festplatte in USB-Gehaeuse (von Gensyslogic). Kernel ist 2.6.5-7.75-default (aus online-update). Das Geraet wird erstmal erkannt und unter /media/usb-storage-odd-Genesyslogic-USBMassStorageDevice:0:0:0p1 ein Verzeichnis angelegt.
Wenn ich das richtig verstehe, muss nur die Zeile mit "+ udelay(300)" einegfuegt werden, oder? Was ist mit dem Rest, wo muss der hin??
Richtig (aber ohne das "+" natürlich)
Folgendes getan: Unline-Update auf Kernel 2.6.5-7.95-default cd /usr/src/linux make modules: Ging nicht (meldet "Makefile:438: .config: No such file or directory"). Also: make config make modules make modules_install Das war aber nicht das richtige: Beim booten bzw. Laden der Module bekomme ich jede Menge Fehlermeldungen "tainting Kernel"! Und das USB-Problem tritt leider auch noch auf, obwohl ich usb.c entsprechend modifiziert habe. Habe ich falsche Module installiert? Was habe ich falsch gemacht? Was haette ich statt make config machen muessen, um die richtige Konfiguration zu finden? Wie haette es richtig laufen muessen? Und, genauso wichtig, wie kann ich das ganze rueckgaengig machen?? Besten Dank, Mathias
Hallo Mathias, hallo Leute, Am Donnerstag, 8. Juli 2004 11:45 schrieb duneldaion@web.de: ^^^^^^^^^^^^^^^^^ Bitte trage Deinen Namen im Absender ein. [...]
Folgendes getan: Unline-Update auf Kernel 2.6.5-7.95-default
cd /usr/src/linux [...] make config make modules make modules_install
Das war aber nicht das richtige: Beim booten bzw. Laden der Module bekomme ich jede Menge Fehlermeldungen "tainting Kernel"! Und das USB-Problem tritt leider auch noch auf, obwohl ich usb.c entsprechend modifiziert habe.
Habe ich falsche Module installiert?
Was habe ich falsch gemacht? Was haette ich statt make config machen muessen, um die richtige Konfiguration zu finden?
Kurzfassung: - den Kernel nochmal per rpm installieren, damit Du wieder einen weitgehend funktionierenden Kernel hast - lies 3.3. Kernel-Update http://suse-linux-faq.koehntopp.de/q/q-install-kernel_update.html und die darin verlinkten Texte. - wenn Du das gelesen hast: make mrproper (Achtung: das löscht u. a. die .config) make oldconfig (Konfiguration des SuSE-Kernels nach .config schreiben) make config (Versionsnummer-Suffix ändern) und dann den Kernel mitsamt Modulen installieren. Gruß Christian Boltz -- Lass Dir kein X für ein U vormachen, sei auf der Hxt!
Christian Boltz wrote:
[...] Kurzfassung: [...] - wenn Du das gelesen hast: make mrproper (Achtung: das löscht u. a. die .config) make oldconfig (Konfiguration des SuSE-Kernels nach .config schreiben)
Das wird so nicht gehen: nach einem "make mrproper" ist keine .config mehr vorhanden, wie Du auch selbst geschrieben hast. Ein "make oldconfig" erwartet aber eine existierende .config Datei, die dann fuer den neuen Kernel angepasst wird. Nach einem "make mrproper" muss man also entweder eine alte Konfigurationsdatei von Hand nach .config kopieren und danach "make oldconfig" ausfuehren, oder aber man benutzt "make cloneconfig" (geht nicht bei Vanilla-Kerneln), das uebernimmt die noetigen Schritte alle gleich mit. CU, Th.
Hallo Thomas Am Mittwoch, 14. Juli 2004 08:36 schrieb Thomas Hertweck:
Das wird so nicht gehen: nach einem "make mrproper" ist keine .config mehr vorhanden, wie Du auch selbst geschrieben hast. Ein "make oldconfig" erwartet aber eine existierende .config Datei, die dann fuer den neuen Kernel angepasst wird. Nach einem "make mrproper" muss man also entweder eine alte Konfigurationsdatei von Hand nach .config kopieren und danach "make oldconfig" ausfuehren, oder aber man benutzt "make cloneconfig" (geht nicht bei Vanilla-Kerneln), das uebernimmt die noetigen Schritte alle gleich mit.
Ups.... Ich bin gerade dabei mir einen Kernel zu kompilieren. Dass make mrproper die .config löscht habe ich nach ein paar versuchen rausgefunden. Aber: Ein make oldconfig erstellt bei mir eine .config Was ist der Unterschied zwischen cloneconfig und oldconfig? Danke Gruss Karl
CU, Th.
Karl Sinn wrote:
Am Mittwoch, 14. Juli 2004 08:36 schrieb Thomas Hertweck:
Das wird so nicht gehen: nach einem "make mrproper" ist keine .config mehr vorhanden, wie Du auch selbst geschrieben hast. Ein "make oldconfig" erwartet aber eine existierende .config Datei, die dann fuer den neuen Kernel angepasst wird. Nach einem "make mrproper" muss man also entweder eine alte Konfigurationsdatei von Hand nach .config kopieren und danach "make oldconfig" ausfuehren, oder aber man benutzt "make cloneconfig" (geht nicht bei Vanilla-Kerneln), das uebernimmt die noetigen Schritte alle gleich mit.
Ups....
Ich bin gerade dabei mir einen Kernel zu kompilieren. Dass make mrproper die .config löscht habe ich nach ein paar versuchen rausgefunden. Aber: Ein make oldconfig erstellt bei mir eine .config
Das ist korrekt. Ich habe mich oben nicht praezise genug ausgedrueckt. Lass es mich so formulieren: Wenn Du nach einem "make mrproper" ein- fach ein "make oldconfig" ausfuehrst, dann ist die Konfiguration evtl. nicht wie Du erwarten wuerdest. Existiert keine .config Datei und es wird "make oldconfig" aufgerufen, so wird als Grundlage fuer die Kon- figuration die Datei arch/$ARCH/defconfig verwendet (bei Dir duerfte $ARCH vermutlich i386 entsprechen). Existiert eine .config und es wird "make oldconfig" aufgerufen, so wird die bereits existierende .config als Grundlage fuer die Konfiguration des neuen Kernels verwendet. Das kann ein _grosser_ Unterschied sein und ob die Grundlage aus defconfig fuer Dein System passt, ist fraglich. Es ist vermutlich besser, eine fuer sein System bereits als funktionierend bekannte Konfiguration her- zunehmen, diese nach .config zu kopieren und dann "make oldconfig" auf- zurufen statt auf die Default-Konfiguration zu vertrauen. Deswegen mein erster Hinweis, den ich allerdings etwas ungluecklich bzw. unpraezise formuliert habe. Ein "make cloneconfig" kopiert bei einem SuSE-Kernel exakt die Konfi- guration des laufenden Kernels. Hast Du also einen funktionierenden Kernel am Laufen, so sollte dann auch die neue Konfiguration im Prinzip funktionieren (wenn Du bei zusaetzlichen Fragen, die gestellt werden, da ja evtl. neue Features im neuen Kernel sind, keinen Unsinn antwor- test). Nochmal zur Verdeutlichung der Unterschide: o Ein "make cloneconfig" entspricht einem "zcat /proc/config.gz > .config && make oldconfig". Hier wird exakt die Konfiguration des laufenden Kernels auf die neuen Quellen uebertragen. o Ein "make oldconfig" bei einer _fehlenden_ .config entspricht auf einem i386 System einem "cp arch/i386/defconfig .config && make oldconfig". Hier wird exakt die Default-Konfiguration auf die Quellen uebertragen. o Bei einem "cp /irgendeine/Konfiguration .config && make oldconfig" uebertraegt man genau die von irgendwoher kopierte Konfiguration auf die Kernel-Quellen. In den allermeisten Faellen schafft ein "make cloneconfig" (gibt es nur bei SuSE-Kernelquellen) bzw. ein "zcat /proc/config.gz > .config && make oldconfig" (geht auch bei Vanilla-Kernelquellen, solange es die config.gz in /proc gibt) eine gute Grundlage fuer eigene Versuche zum Kernelerstellen. HTH, Thomson
Hallo, Super, und Danke. Das habe ich kapiert. Da habe ich ja scheinbar ziemliches Glueck gehabt, denn mein make mrproper oldconfig ... hat zu einem funktionierenden Kernel geführt. Allerdings habe ich den Kernel mit YOU von SuSE geholt. Ist bei diesen SuSE-Kernel-Sources die /$ARCH/defconfig == der SuSE Defaultkonfiguration? Und noch eine Frage. Wenn ich nur im Makefile die EXTRAVERSION ändere, reicht es dann ein make modules_install zu machen? Oder muss ich dann wieder make dep bzImage modules machen? Gruss Karl
Karl Sinn wrote:
Da habe ich ja scheinbar ziemliches Glueck gehabt, denn mein make mrproper oldconfig ... hat zu einem funktionierenden Kernel geführt. Allerdings habe ich den Kernel mit YOU von SuSE geholt. Ist bei diesen SuSE-Kernel-Sources die /$ARCH/defconfig == der SuSE Defaultkonfiguration?
Kann ich Dir nicht genau sagen. Mit einem Vanilla-Kernel hatte ich mit der Default-Konfiguration defconfig allerdings so meine Probleme. Du kannst die SuSE-Konfiguration zum Kernel (findest Du z.B. in /boot oder kannst sie bei laufendem SuSE-Defaultkernel aus /proc/config.gz auslesen) ja mal mit der defconfig Datei vergleichen. Dann muesstest Du schon feststellen, ob sie passen oder doch unterschiedlich sind.
Und noch eine Frage. Wenn ich nur im Makefile die EXTRAVERSION ändere, reicht es dann ein make modules_install zu machen? Oder muss ich dann wieder make dep bzImage modules machen?
Einige Anmerkungen vorweg: Die Variable EXTRAVERSION solltest Du nur bei alten SuSE-Kerneln oder bei Vanilla-Kerneln setzen. Neue SuSE-Kernel koennen waehrend der Konfiguration unter "Build Options" angepasst werden und bekommen dort einen Konfigurationsnamen und eine Release-Nummer. Deine Vorgehensweise spricht fuer Kernel 2.4, weil es ja bei Kernel 2.6 kein "make dep" mehr gibt. Ich gehe davon aus, dass dies Absicht war von Dir, wir hier also wirklich ueber 2.4er Kernel sprechen. Zu Deiner eigentlichen Frage: Ich moechte sie Dir nun ungern einfach so beantworten, sondern moechte Dich dazu animieren, mal selbst ueber die Antwort zu gruebeln. Die Antwort ist eigentlich ganz leicht. Ein Modul muss im Prinzip zum laufenden Kernel passen, wenn es geladen werden soll. Die Versionsangabe beim Kernel kannst Du einfach per z.B. "uname -r" herausfinden. Bei einem Modul ist die Versionsangabe ebenfalls eincompiliert, nimm ein beliebiges Modul und schau Dir mal od -s /lib/modules/<pfad>/<name>.o | grep version an, wobei Du hier natuerlich <pfad> und <name> durch ein existierendes Modul ersetzen musst. Du wirst sehen, dass dort die Versionsangabe erscheint. Passt sie nun nicht zum laufenden Kernel, so will modprobe das Modul erst einmal nicht laden. Nun musst Du nur noch ueberlegen, was die von Dir vorgeschlagene Vorgehensweise fuer eine Konsequenz hat, also EXTRAVERSION aendern und dann "make modules_install" aufrufen. Was willst Du damit ueberhaupt bewirken? Ich wage zu behaupten, das wird nicht das machen, was Du Dir vielleicht erhoffst. Gruesse, Th.
Hallo, Am Mittwoch, 14. Juli 2004 13:03 schrieb Thomas Hertweck:
Die Variable EXTRAVERSION solltest Du nur bei alten SuSE-Kerneln oder bei Vanilla-Kerneln setzen. Neue SuSE-Kernel koennen waehrend der Konfiguration unter "Build Options" angepasst werden und bekommen dort einen Konfigurationsnamen und eine Release-Nummer.
Deine Vorgehensweise spricht fuer Kernel 2.4, weil es ja bei Kernel 2.6 kein "make dep" mehr gibt. Ich gehe davon aus, dass dies Absicht war von Dir, wir hier also wirklich ueber 2.4er Kernel sprechen.
Ja, an den 2.6 habe ich mich noch nicht herangewagt. Probiere ich aber bestimmt auch bald :-)
Zu Deiner eigentlichen Frage: Ich moechte sie Dir nun ungern einfach so beantworten, sondern moechte Dich dazu animieren, mal selbst ueber die Antwort zu gruebeln. Die Antwort ist eigentlich ganz leicht. Ein Modul muss im Prinzip zum laufenden Kernel passen, wenn es geladen werden soll. Die Versionsangabe beim Kernel kannst Du einfach per z.B. "uname -r" herausfinden. Bei einem Modul ist die Versionsangabe ebenfalls eincompiliert, nimm ein beliebiges Modul und schau Dir mal
Soweit war mir das klar.
od -s /lib/modules/<pfad>/<name>.o | grep version
OK. Das Ergebnis hier ist das gleiche wie uname -r
an, wobei Du hier natuerlich <pfad> und <name> durch ein existierendes Modul ersetzen musst. Du wirst sehen, dass dort die Versionsangabe erscheint. Passt sie nun nicht zum laufenden Kernel, so will modprobe das Modul erst einmal nicht laden. Nun musst Du nur noch ueberlegen, was die von Dir vorgeschlagene Vorgehensweise fuer eine Konsequenz hat, also EXTRAVERSION aendern und dann "make modules_install" aufrufen. Was willst Du damit ueberhaupt bewirken? Ich wage zu behaupten, das wird nicht das machen, was Du Dir vielleicht erhoffst.
OK. Das war die Information die mir fehlte. Die Kernelversion wird in die Module mit eincompiliert. Dann ist alles klar. Ich habe das bisher auch automatisch richtig gemacht. Noch ein Glückstreffer :-) Ich setze die Extraversion, weil es in Deinem Multi-Kernel HowTo so beschrieben ist, und um den aktuellen funktionierenden Kernel nicht zu zerstören. Ich spiele jetzt ein wenig mit den Kernel-Optionen rum, um einen Kernel der so schlank wie moeglich ist zu haben. Danke Gruss Karl
Karl Sinn wrote:
[...] Ich setze die Extraversion, weil es in Deinem Multi-Kernel HowTo so beschrieben ist, und um den aktuellen funktionierenden Kernel nicht zu zerstören.
1. Das Multikernel-Howto ist von David! Ehre, wem Ehre gebuehrt. Von mir ist nur das Kernel-Howto. 2. Dein Vorgehen ist prinzipiell richtig. Nochmal zur Klarstellung der Umstaende: - Bei einem Vanilla-Kernel muss man die EXTRAVERSION im Makefile der Kernel-Quellen anpassen. - Bei alten SuSE Kernel-Quellen muss man ebenfalls die EXTRAVERSION im Makefile der Kernel-Quellen anpassen. - Bei aktuellen SuSE Kernel-Quellen der 2.4er und 2.6er Versionen sollte man EXTRAVERSION im Makefile nicht anpassen, sondern stattdessen bei der Kernel-Konfiguration im Register "Build options" die Variablen "Configuration name" und "Release number" setzen. Aus diesen beiden Angaben entsteht dann das Kernel-Release, es wird nach folgendem Muster gebildet: "major_version"-"release_number"-"configuration_name" Ich weiss jetzt gar nicht, ob das 2.4er Kernel Howto in diesem Punkt aktuell ist, muss ich mal schauen, habe in letzter Zeit nur das Kernel 2.6 Howto geaendert. Beim 2.6er Howto ist das jedenfalls erklaert. Gruesse, Th.
Am Mittwoch, 14. Juli 2004 18:07 schrieb Thomas Hertweck:
- Bei aktuellen SuSE Kernel-Quellen der 2.4er und 2.6er Versionen sollte man EXTRAVERSION im Makefile nicht anpassen, sondern stattdessen bei der Kernel-Konfiguration im Register "Build options" die Variablen "Configuration name" und "Release number" setzen. Aus diesen beiden Angaben entsteht dann das Kernel-Release, es wird nach folgendem Muster gebildet: "major_version"-"release_number"-"configuration_name"
ok. Ich habe den gesamten 'Salat' der da drin stand natürlich gelöscht... :-) Kannst Du mir die Zeile mit der EXTRAVERSION aus dem Makefile bitte zumailen, damit ich das wieder richtig stellen kann? Danke Gruss Karl
Karl Sinn wrote:
Ich habe den gesamten 'Salat' der da drin stand natürlich gelöscht... :-) Kannst Du mir die Zeile mit der EXTRAVERSION aus dem Makefile bitte zumailen, damit ich das wieder richtig stellen kann?
Extrahiere doch einfach das Makefile nochmal aus SuSEs kernel-source.rpm. Das sollte machbar sein. Ansonsten muesste die folgende Zeile den urspruenglichen Zustand (sofern Du nicht noch mehr geaendert hast) wieder herstellen: EXTRAVERSION = -$(shell echo $(CONFIG_RELEASE)-$(CONFIG_CFGNAME)) Prinzipiell kannst Du natuerlich auch bei aktuellen SuSE Kernelquellen die EXTRAVERSION im Makefile direkt setzen, es war also nicht falsch, was Du gemacht hast. Ueber die Konfiguration ist es vielleicht aber geschickter, weil Du so das Makefile bei verschiedenen (Compilier-)Versuchen nicht jedesmal aendern musst, sondern einfach nur unterschiedliche Konfig-Dateien abspeichern bzw. kreieren musst. CU, Th.
participants (5)
-
Christian Boltz -
duneldaion＠web.de -
Hans Galic -
Karl Sinn -
Thomas Hertweck