Hallo,
ich stehe gerade vor einem dummen Problem an meinem Powerbook. Wenn ich die ganzen "Input core support" Module als Module in den Kernel compiliere, ist weder die Maus, noch das Touchpad zu gebrauchen (sie reagieren überhaupt nicht), die USB Maus wird aber einwandfrei eingebunden. Wenn ich nun aber die aber fest in den Kernel compiliere, funktionieren Tastatur und Touchpad, die Maus ist aber von der Lösung nicht begeistert. Sprich hotplug versucht ein 'modprobe hid' oder 'modprobe usbmouse' auszuführen, das beschwert sich, aber dass kein Modul keybdev Modul geladen werden kann, dass er angeblich benötigt (klar, ist ja fix im Kernel). Weder in /etc/modules.conf, noch in /lib/modules/2.4.21/modules.dep ist 'keybdev' zu finden, depmod -a läuft ohne Fehler durch, kein unresolved oder sonstige Probleme.
Hat jemand ne Ahnung, wo depmod die angebliche Abhängigkeit her hat? Es nervt immer mit 'insmod /lib/modules/2.4.21/kernel/drivers/usb/hid.o' das Modul per Hand laden zu müssen, um die Maus zu nutzen.
Manfred Tremmel wrote:
ich stehe gerade vor einem dummen Problem an meinem Powerbook. Wenn ich die ganzen "Input core support" Module als Module in den Kernel compiliere, ist weder die Maus, noch das Touchpad zu gebrauchen (sie reagieren überhaupt nicht), die USB Maus wird aber einwandfrei eingebunden. Wenn ich nun aber die aber fest in den Kernel compiliere, funktionieren Tastatur und Touchpad, die Maus ist aber von der Lösung nicht begeistert. Sprich hotplug versucht ein 'modprobe hid' oder 'modprobe usbmouse' auszuführen, das beschwert sich, aber dass kein Modul keybdev Modul geladen werden kann, dass er angeblich benötigt (klar, ist ja fix im Kernel). Weder in /etc/modules.conf, noch in /lib/modules/2.4.21/modules.dep ist 'keybdev' zu finden, depmod -a läuft ohne Fehler durch, kein unresolved oder sonstige Probleme.
Hat jemand ne Ahnung, wo depmod die angebliche Abhängigkeit her hat? Es nervt immer mit 'insmod /lib/modules/2.4.21/kernel/drivers/usb/hid.o' das Modul per Hand laden zu müssen, um die Maus zu nutzen.
Versuch mal in modules.conf :
alias keybdev null
Dann wird der interne Befehl "modprobe keybdev" ausgeführt ohne irgendwas zu tun bekommt aber eine erfolgreich-quittung.
Am Dienstag, 1. Juli 2003 22:02 schrieb Andreas Winkelmann:
Versuch mal in modules.conf :
alias keybdev null
Gute Idee, hab ich aber schon versucht (hätte ich wohl dazuschreiben sollen). Der Fehler verschwindet damit tatsächlich, 'modprobe hid' läuft durch, aber die Maus läuft nicht und lsmod zeigt mir das Modul nicht als geladen an.
Manfred Tremmel wrote:
Versuch mal in modules.conf :
alias keybdev null
Gute Idee, hab ich aber schon versucht (hätte ich wohl dazuschreiben sollen). Der Fehler verschwindet damit tatsächlich, 'modprobe hid' läuft durch, aber die Maus läuft nicht und lsmod zeigt mir das Modul nicht als geladen an.
Hmm, habe es jetzt hier mal probiert, die einzigen Dateien die er aufmacht sind :
/etc/modules.conf /etc/modules.conf.local /lib/modules/xxxx/modules.dep
Schau die nochmal durch, sonst mach mal einen strace. Kannst Du ja schicken.
# strace modprobe xyz 2> modprobe.out
Am Mittwoch, 2. Juli 2003 15:20 schrieb Andreas Winkelmann:
Hmm, habe es jetzt hier mal probiert, die einzigen Dateien die er aufmacht sind :
/etc/modules.conf /etc/modules.conf.local /lib/modules/xxxx/modules.dep
Naja, in keiner der drei ist was brauchbares zu finden:
marvin:~ # grep hid /etc/modules.conf marvin:~ # grep keybdev /etc/modules.conf marvin:~ # grep hid /etc/modules.conf.local marvin:~ # grep keybdev /etc/modules.conf.local marvin:~ # grep hid /lib/modules/2.4.21/modules.dep /lib/modules/2.4.21/kernel/drivers/usb/hid.o: /lib/modules/2.4.21/kernel/drivers/usb/usbcore.o marvin:~ # grep keybdev /lib/modules/2.4.21/modules.dep
Sprich der einzige Treffer dist in der modules.dep das hid.o Modul, aber das ist laut der dortigen Ausgabe eben nur von usbcore.o abhängig (so find ich das dann auch ok, das gibts und das soll er auch laden).
Schau die nochmal durch, sonst mach mal einen strace. Kannst Du ja schicken.
# strace modprobe xyz 2> modprobe.out
Auch dieses, wird aber auch nicht helfen, ein grep open auf die Datei liefert:
marvin:~ # grep open /multimedia/modprobe.out open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libz.so.1", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/etc/modules.conf", O_RDONLY) = 3 open("/lib/modules/2.4.21/modules.dep", O_RDONLY) = 3
Wovon wohl nur die letzten beiden Zeilen von Interesse sein dürften, die wiederum, siehe oben. Ich kann gern die 10 KByte strace Ausgabe mitschicken, aber da wirst Du sicher auch nicht mehr drin finden, wie ich. Auch keybdev kommt nur einmal vor und zwar dort, wo die Fehlermeldung geschrieben wird:
marvin:~ # grep keybdev /multimedia/modprobe.out write(2, "Can't locate module keybdev whic"..., 51Can't locate module keybdev which is needed for hid) = 51
Die Abhängigkeit ist nicht in /etc/modules.conf und /lib/modules/2.4.21/modules.dep, die libs, die geöffnet werden, schliese ich jetzt auch mal aus. Nach Sherlock Holmes bleibt eigentlich nur noch eine Möglichkeit offen, die Abhängigkeit muß in modprobe selber stecken. Ok. modprobe ist nur ein Shell-Script, das ruft modprobe.old auf. Das hab ich jetzt mal ganz frech in den vi geladen und nach hid gesucht: "hid keybdev mousedev" die drei Wörter in einer Zeile? Verdächtig! Also mal das source-RPM zu modutils-2.4.22-33 installiert. Man glaubt es kaum, in utils/alias.h stosse ich dann auf diese hübsche Stelle:
/* * This is the list of pre-defined "above"s, * used for pull-in of additional modules * Each entry can be overridden by an entry in /etc/modules.conf */ char *above[] = { "hid keybdev mousedev", "usbmouse hid", "wacom evdev", NULL /* marks the end of the list! */ };
Ok, wenn man das in der /etc/modules.conf überschreiben kann, schnell eine Zeile eingefügt:
above hid usbcore
'depmod -a' ausgeführt und - man glaubt es kaum - es geht. Schnell die Module entladen, Maus abgezogen und wieder angesteckt, voila, hotplug bindet sie astrein ein.
Besten Dank Andreas, für die Denkanstösse.
Manfred Tremmel wrote:
Nach Sherlock Holmes bleibt eigentlich nur noch eine Möglichkeit offen, die Abhängigkeit muß in modprobe selber stecken. Ok. modprobe ist nur ein Shell-Script, das ruft modprobe.old auf. Das hab ich jetzt mal ganz frech in den vi geladen und nach hid gesucht: "hid keybdev mousedev" die drei Wörter in einer Zeile? Verdächtig! Also mal das source-RPM zu modutils-2.4.22-33 installiert. Man glaubt es kaum, in utils/alias.h stosse ich dann auf diese hübsche Stelle:
/*
- This is the list of pre-defined "above"s,
- used for pull-in of additional modules
- Each entry can be overridden by an entry in /etc/modules.conf
*/ char *above[] = { "hid keybdev mousedev", "usbmouse hid", "wacom evdev", NULL /* marks the end of the list! */ };
Ok, wenn man das in der /etc/modules.conf überschreiben kann, schnell eine Zeile eingefügt:
above hid usbcore
'depmod -a' ausgeführt und - man glaubt es kaum - es geht. Schnell die Module entladen, Maus abgezogen und wieder angesteckt, voila, hotplug bindet sie astrein ein.
Besten Dank Andreas, für die Denkanstösse.
Hmm, /sbin/modprobe ist bei mir kein Shellscript, sondern ein executable. Und solche komischen sachen wie "hid keybdev mousedev" stehen da auch nicht drin. Allerdings im modprobe.old. Die sind bei uns gleich. Merkwürden...
Naja, beim nächsten mal wissen wir's ;-))
Am Mittwoch, 2. Juli 2003 23:42 schrieb Andreas Winkelmann:
Hmm, /sbin/modprobe ist bei mir kein Shellscript, sondern ein executable. Und solche komischen sachen wie "hid keybdev mousedev"
Sorry, mein Fehler, hast natürlich recht. Allerdings ruft modprobe laut dem strace modprobe.old auf (das ist hier ein symlink auf insmod.old):
execve("/sbin/modprobe.old", ["modprobe", "hid"], [/* 63 vars */]) = 0
stehen da auch nicht drin. Allerdings im modprobe.old. Die sind bei uns gleich. Merkwürden...
Nö, nur ein Fehler meinerseits.
Naja, beim nächsten mal wissen wir's ;-))
Irgendwie glaub ich nicht, dass ich mir nochmal ne SuSE from Scratch auf dem PowerBook bau. Das Ding ist fünf Jahre alt und die SuSE 8.2 + Updates dürfte für die "Restlaufzeit" reichen. Die neue glibc 2.3.2 + gcc 3.3 haben für den nötigen Leistungsschub gesorgt, da macht KDE 3.1.2 gleich doppelt so viel Spaß. Nur das blöde IBM Java 1.4.1 Mistding läuft trotzdem nicht, ok bleib ich halt erstmal bei 1.3.1.
-
Andreas Winkelmann -
Manfred Tremmel