Ich habe SuSE 7.0 auf einem Notebook mit einem ES1980 PCI audio
controller, dieser wird vom Kernel (2.2.16) nicht erkannt. Ich habe
von ftp://ftp.suse.com/pub/people/tiwai die entsprechenden alsa-rpms
runtergeladen und nach den dortigen Anweisungen installiert, aber es
hat trotzdem nicht geklappt. Ich hoffe, dass jemand hier mir
weiterhelfen kann. Hier sind die Details:
Ich bin folgendermaßen vorgegangen (shell-Ausgaben nach =>):
rpm -Uvh alsa-0.5.11-74.i386.rpm =>
alsa
Updating etc/rc.config...
kann /usr/share/locale/ja nicht entfernen - Verzeichnis ist nicht leer
var/tmp/rpm-tmp.49535: sbin/insserv: Datei oder Verzeichnis nicht
gefunden
rpm -Uvh alsadev-0.5.11-74.i386.rpm =>
alsadev
Run SuSEconfig if you installed this package manually via rpm
rpm -Uvh alsa-driver-0.5.11_laptop-0.i386.rpm --force =>
alsa-driver
SuSEconfig
Tiwai folgend habe ich mit Yast2 eine Konfiguration versucht, aber
ohne Erfolg. Ich habe auch neugebootet, weil ich mal gelesen habe,
dass jemand so mit Alsa Erfolg gehabt hat; ich aber nicht. Dann habe
ich alsaconf aufgerufen: das hat jedenfalls die Karte erkannt und ich
konnte fortführen, aber geklappt hat es dann auch nicht; hier die
Ausgabe:
Loading driver:
Starting sound driver: maestro3/lib/modules/2.2.16/misc/snd-card-maestro3.o: init_module: Das Gerät oder die Ressource ist belegt
Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.2.16/misc/snd-card-maestro3.o: insmod /lib/modules/2.2.16/misc/snd-card-maestro3.o failed
/lib/modules/2.2.16/misc/snd-card-maestro3.o: insmod snd-card-maestro3 failed
Der vollständigkeit halber hier noch drei weitere einschlägige
Ausgaben, (i) von dmesg:
snd: unable to grab IRQ 0 for Maestro3
snd: maestro3: unable to grab IRQ 0
snd: Maestro3/Allegro soundcard not found or device busy
eth0: no IPv6 routers present
eth0: no IPv6 routers present
snd: unable to grab IRQ 0 for Maestro3
snd: maestro3: unable to grab IRQ 0
snd: Maestro3/Allegro soundcard not found or device busy
...usw....
kdeinit uses obsolete /proc/pci interface
snd: unable to grab IRQ 0 for Maestro3
snd: maestro3: unable to grab IRQ 0
snd: Maestro3/Allegro soundcard not found or device busy
snd: unable to grab IRQ 0 for Maestro3
snd: maestro3: unable to grab IRQ 0
snd: Maestro3/Allegro soundcard not found or device busy
snd: unable to grab IRQ 0 for Maestro3
snd: maestro3: unable to grab IRQ 0
snd: Maestro3/Allegro soundcard not found or device busy
isapnp: No Plug & Play device found
snd: unable to grab IRQ 0 for Maestro3
snd: maestro3: unable to grab IRQ 0
snd: Maestro3/Allegro soundcard not found or device busy
...usw....
(ii) von lspci -vv:
00:0c.0 Multimedia audio controller: ESS Technology: Unknown device 199a
Subsystem: Samsung Electronics Co Ltd: Unknown device 3260
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
Am Donnerstag, 18. Oktober 2001 16:14 schrieb Stephen Berman:
Ich bin folgendermaßen vorgegangen (shell-Ausgaben nach =>): rpm -Uvh alsa-0.5.11-74.i386.rpm => kann /usr/share/locale/ja nicht entfernen - Verzeichnis ist nicht leer
ist ok, du willst ja nicht alle ja-locale-files loeschen nur weil du dein altes alsa deinstallierst.
Der vollständigkeit halber hier noch drei weitere einschlägige Ausgaben, (i) von dmesg:
snd: unable to grab IRQ 0 for Maestro3 snd: maestro3: unable to grab IRQ 0
00:0c.0 Multimedia audio controller: ESS Technology: Unknown device 199a Subsystem: Samsung Electronics Co Ltd: Unknown device 3260 Interrupt: pin A routed to IRQ 0
Das sieht so aus, als ob dein BIOS auf PNP-Os: yes eingestellt ist. Stell das mal auf no. Wenns das nicht bringt, versuch mal unter Linux APCI in Betrieb zu nehmen. Damit sollte ein OS die IRQ-Routings veraendern koennen. Ist aber experimentell, daher nicht wirklich erst gemeint. Peter
Peter Wiersig
Am Donnerstag, 18. Oktober 2001 16:14 schrieb Stephen Berman:
Ich bin folgendermaßen vorgegangen (shell-Ausgaben nach =>): rpm -Uvh alsa-0.5.11-74.i386.rpm => kann /usr/share/locale/ja nicht entfernen - Verzeichnis ist nicht leer
ist ok, du willst ja nicht alle ja-locale-files loeschen nur weil du dein altes alsa deinstallierst.
Sind ja-locale-files nicht locale-Definition-files fürs Japanisch? Wenn ja, was ist da der Zusammenhang mit Alsa (d.h., warum nicht (auch) /usr/share/locale/de usw.)? (Hat zwar nichts mit meinem momentanen Anliegen zu tun, aber würde mich dennoch interessieren.)
Der vollständigkeit halber hier noch drei weitere einschlägige Ausgaben, (i) von dmesg:
snd: unable to grab IRQ 0 for Maestro3 snd: maestro3: unable to grab IRQ 0
00:0c.0 Multimedia audio controller: ESS Technology: Unknown device 199a Subsystem: Samsung Electronics Co Ltd: Unknown device 3260 Interrupt: pin A routed to IRQ 0
Das sieht so aus, als ob dein BIOS auf PNP-Os: yes eingestellt ist. Stell das auf no.
Vielleicht eine DAU-Frage, aber woran erkennt man das? Ist nicht PnP eine Art ISA-Karte (so habe ich es vom SuSE-Handbuch verstanden)? Da meine Maestro3 ja eine PCI-Karte ist, bedeutet das, dass diese Einstellung verhindert die Verwendung eines IRQ durch die PCI-Karte? Obwohl ich keine PnP-Karten habe: pnpdump -c ergibt "No boards found". Leider sehe ich in meinem BIOS gar nichts, was mit Plug-n-play zu tun hat. Ich habe ein Phoenix BIOS Version 4.0 R6 04UE. Die Dokumentation zum BIOS, die mit meinem Notebook kam, ist ziemlich mager und sagt nichts zu PnP. Von der Phoenix Website habe ich ein Benutzerhandbuch für Version 4.0 R6 runtergeladen; die dort beschrieben Funktionen sind umfangreicher als die in meinem BIOS, jedoch sehe ich auch keine direkte Einstellung für PnP (sondern einige Seiten über das Programmieren von PnP runtime services). Das Notebook kam mit Windows98 vorinstalliert, das soll nach der Phoenix-Website ein "voll PnP" OS sein; bedeutet das etwa, das PnP in meinem BIOS fest eingestellt ist? Bin ich dann aufgeschmissen? Oder könnte es was bringen, wenn ich einen nicht verwendeten Anschluss, z.B. den Infrarot-Port, im BIOS deaktiviere und damit dessen IRQ zur Verfügung stelle?
Wenns das nicht bringt, versuch mal unter Linux APCI in Betrieb zu nehmen. Damit sollte ein OS die IRQ-Routings veraendern koennen. Ist aber experimentell, daher nicht wirklich erst gemeint.
Damit kann ich nichts anfangen, kannst Du mehr dazu sagen oder mir einen Verweis zum Weiterlesen geben? (Ich nehme an, Du meinst was anders als ACPI (Advanced Configuration and Power Management Interface); in Google kommt diese Verwechslung APCI <=> ACPI vielfach vor. Jedenfalls ist in meinem BIOS ACPI aktiviert.) Danke für die Vorschläge, aber leider bin ich noch auf der Suche nach einer Lösung. --Steve Berman
On Fri, Oct 19, 2001 at 04:39:44PM +0200, Stephen Berman wrote:
Peter Wiersig
writes: Am Donnerstag, 18. Oktober 2001 16:14 schrieb Stephen Berman:
Ich bin folgendermaßen vorgegangen (shell-Ausgaben nach =>): rpm -Uvh alsa-0.5.11-74.i386.rpm => kann /usr/share/locale/ja nicht entfernen - Verzeichnis ist nicht leer
ist ok, du willst ja nicht alle ja-locale-files loeschen nur weil du dein altes alsa deinstallierst.
Sind ja-locale-files nicht locale-Definition-files fürs Japanisch? Wenn ja, was ist da der Zusammenhang mit Alsa (d.h., warum nicht (auch) /usr/share/locale/de usw.)? (Hat zwar nichts mit meinem momentanen Anliegen zu tun, aber würde mich dennoch interessieren.)
Im alsa-RPM sind sicherlich auch locale/de/-Dateien enthalten. Nur hat der Packager faelschlicherweise das ja/-Verzeichnis in der %files-Liste zusaetzlich aufgefuehrt und nicht nur die Dateien, die zum Paket gehoeren. Der RPM versucht beim deinstallaieren also ein "rmdir <verz>" und das schlaegt fehl, weil auch andere Pakete dort Dateien hineinkopiert haben.
Der vollständigkeit halber hier noch drei weitere einschlägige Ausgaben, (i) von dmesg:
snd: unable to grab IRQ 0 for Maestro3 snd: maestro3: unable to grab IRQ 0
00:0c.0 Multimedia audio controller: ESS Technology: Unknown device 199a Subsystem: Samsung Electronics Co Ltd: Unknown device 3260 Interrupt: pin A routed to IRQ 0
Das sieht so aus, als ob dein BIOS auf PNP-Os: yes eingestellt ist. Stell das auf no.
Vielleicht eine DAU-Frage, aber woran erkennt man das? Ist nicht PnP eine Art ISA-Karte (so habe ich es vom SuSE-Handbuch verstanden)? Da meine Maestro3 ja eine PCI-Karte ist, bedeutet das, dass diese Einstellung verhindert die Verwendung eines IRQ durch die PCI-Karte?
Dein Problem (so wie ich das sehe) hat nichts mit nicht verfuegbaren IRQs zu tun, sondern dein BIOS weist deiner PCI-Karte (und es ist sicher eine, weil lspci sie sonst nicht gelistet haette) keinen IRQ zu. Das sollte es als ACPI-Bios auch nicht tun. Versuch mal dein ACPI abzuschalten. Und PNP auf ISA-Karten ist meist abenteuerlich. Manchmal klappts, aber wenn da ein Problem auftritt hat man meist verloren.
Wenns das nicht bringt, versuch mal unter Linux APCI in Betrieb zu nehmen. Damit sollte ein OS die IRQ-Routings veraendern koennen. Ist aber experimentell, daher nicht wirklich erst gemeint.
Damit kann ich nichts anfangen, kannst Du mehr dazu sagen oder mir einen Verweis zum Weiterlesen geben? (Ich nehme an, Du meinst was
http://developer.intel.com/technology/iapc/acpi/faq.htm Peter
Peter Wiersig - Mailinglisten
On Fri, Oct 19, 2001 at 04:39:44PM +0200, Stephen Berman wrote:
Peter Wiersig
writes: Am Donnerstag, 18. Oktober 2001 16:14 schrieb Stephen Berman: [...]
Der vollständigkeit halber hier noch drei weitere einschlägige Ausgaben, (i) von dmesg:
snd: unable to grab IRQ 0 for Maestro3 snd: maestro3: unable to grab IRQ 0
00:0c.0 Multimedia audio controller: ESS Technology: Unknown device 199a Subsystem: Samsung Electronics Co Ltd: Unknown device 3260 Interrupt: pin A routed to IRQ 0
Das sieht so aus, als ob dein BIOS auf PNP-Os: yes eingestellt ist. Stell das auf no.
Vielleicht eine DAU-Frage, aber woran erkennt man das? Ist nicht PnP eine Art ISA-Karte (so habe ich es vom SuSE-Handbuch verstanden)? Da meine Maestro3 ja eine PCI-Karte ist, bedeutet das, dass diese Einstellung verhindert die Verwendung eines IRQ durch die PCI-Karte?
Dein Problem (so wie ich das sehe) hat nichts mit nicht verfuegbaren IRQs zu tun, sondern dein BIOS weist deiner PCI-Karte (und es ist sicher eine, weil lspci sie sonst nicht gelistet haette) keinen IRQ zu. Das sollte es als ACPI-Bios auch nicht tun.
Ich verstehe nicht, warum es das nicht tun sollte, aber Du brauchst mir das jetzt nicht erklären (es sei denn, du willst...), ich werde versuchen mir bei Gelegenheit darüber schlau(er) zu machen. Wenn Du hierzu einschlägige Links hättest, wäre ich Dir dankbar.
Versuch mal dein ACPI abzuschalten.
Das hat tatsächlich geklappt! In meinem BIOS gibt's unter "installiertes OS" eine Auswahl zwischen "Win95/Win98 APM", "Win98ACPI/Win2000" und "Other/WinNT4.0". Die ACPI-Einstellung war default und ich hab's immer so gelassen gehabt, damit hab ich auch unter Linux Suspend-to-disk aktivieren können. Aber nun habe ich die Einstellung auf "Other/WinNT4.0" gesetzt (im BIOS steht, dass dies zu benutzen ist, wenn man hauptsächlich nicht mit Windows 9x arbeitet, was ich auch tue; dennoch, weil es auch heißt, dass Änderung dieser Einstellung zu "unerwartetem Verhalten" führen könne und ich bisher kein Problem damit unter Linux hatte (so hatte ich jedenfalls geglaubt), hatte ich es nie geändert). Ich konnte also endlich meine Maestro3-Karte mit Alsa konfigurieren und kriege jetzt unter Linux Klänge aus der Kiste :-) . Darüber hinaus scheint Suspend-to-disk unter Linux nach wie vor zu tun, jedenfalls hab ich noch kein Problem erlebt (es gibt im BIOS extra eine Einstellung dafür und die habe ich so bestehen lassen). Also bin ich recht zufrieden. :-) (OT aber vielleicht denjenigen von Interesse, die das gleiche Problem haben wie ich es hatte: Ich habe nach der BIOS-Änderung Windows (98) gebootet und zunächst mussten sämtliche Treiber neu installiert (ging automatisch) und die Kiste (wie üblich) neu gebootet werden, aber danach schien alles wie gehabt zu laufen, mir ist jedenfalls nichts Ungewöhnliches aufgefallen. Nur, nachdem ich das System in Suspend-to-disk versetzt und dann wieder geweckt habe, hat es ziemlich gestockt und ich musste schließlich raus (was aber jedenfalls ohne den Schalter zu betätigen klappte); nach erneutem Booten war alles (scheinbar) wieder in Ordnung. Also scheint es, dass ich auf Suspend-to-disk unter Windows verzichten muss, wenn ich Sound unter Linux haben will, jedenfalls bei meiner jetzigen Konfiguration (SuSE 7.0, Kernel 2.2.16).)
Und PNP auf ISA-Karten ist meist abenteuerlich. Manchmal klappts, aber wenn da ein Problem auftritt hat man meist verloren.
Wenns das nicht bringt, versuch mal unter Linux APCI in Betrieb ^^^^ zu nehmen.
Damit sollte ein OS die IRQ-Routings veraendern koennen. Ist aber experimentell, daher nicht wirklich erst gemeint.
Damit kann ich nichts anfangen, kannst Du mehr dazu sagen oder mir einen Verweis zum Weiterlesen geben? (Ich nehme an, Du meinst was
Danke für den Link. Ist also doch ACPI und nicht APCI :-) . Aber wie oben erwähnt, ich kann nichtsdestrotrotz Suspend-to-disk doch noch unter Linux anscheinend ohne Problem verwenden -- oder war das bis jetzt nur Zufall und muss ich Böses erwarten, wenn ich es weiterhin benutze? Vielen Dank nochmal, Peter, für Deine Hilfe! --Steve Berman
participants (3)
-
Peter Wiersig
-
Peter Wiersig - Mailinglisten
-
Stephen Berman