Hallo, ich habe bei mir einmal das Problem gehabt, dass bei der Einrichtung der emu10k1-Soundkarte ein IRQ-Fehler auftrat. Parallel dazu funktionierte mein Paralleldrucker nicht. Yast spuckte bei dem Versuch, die SK einzurichten folgende Fehlermeldung aus: Das Kernelmodul emu10k1 für die soundunterstützung konnte nicht geladen werden. Ein möglicher Grund dafür können falsche Modulparameter sein, sowie ungültige IO- oder IRQ-Parameter Jan hat mir damals den Tipp gegeben, die Soundkarte einfach in einen anderen Pci-Steckplatz zu stecken, weil cat /proc/interrupts zeigte, dass sich die Soundkarte und der Parallelport einen IRQ teilen. Das hat das Problem behoben, auch der Drucker wurde von Yast wieder erkannt. Da das bei Suse 9.1 anscheinend ein landläufiger Fehler (nicht nur bei emu10k1) zu sein scheint, und bei zwei meiner Freunde das gleiche Problem ist/war, wollte ich fragen, ob man die IRQs auch irgendwie anders als durch umstecken zuweisen kann. Das würde vielleicht etwas Arbeit sparen. für jede Anregung bzw. Hilfe bin ich dankbar Gruß Sören
Hallo, Am Mon, 30 Aug 2004, Sören Wengerowsky schrieb:
Da das bei Suse 9.1 anscheinend ein landläufiger Fehler (nicht nur bei emu10k1) zu sein scheint, und bei zwei meiner Freunde das gleiche Problem ist/war, wollte ich fragen, ob man die IRQs auch irgendwie anders als durch umstecken zuweisen kann. Das würde vielleicht etwas Arbeit sparen.
für jede Anregung bzw. Hilfe bin ich dankbar
less /usr/src/linux/Documentation/kernel-parameters.txt Weiters kennen u.U. manche Module auch (IRQ-)Parameter, die nicht in o.g. Datei dokumentiert sind. Da muss man ggfs. die Doku zu dem Modul lesen. Und zur Not kann man auch noch die Kernelquellen nach dem magischen Makro 'MODULE_PARM' (2.4.x) durchgreppen (per find oder mc o.ae.)... Und wenn ein Modul einen irq-Parameter kennt reicht das ja schon, z.B.: parport=0x278,5,auto Den ioport/IRQ musst du ggfs. per 'cat /proc/ioports /proc/interrupts' bzw. aus den BIOS-Einstellungen raussuchen und oder auch die BIOS-Einstellungen anpassen. ACHTUNG: Manche Module / Treiber / Hardware ist empfindlich gegen "falsche" Parameter, meine billig ISA-SCSI-Karte (DMX / DTC 3181E mit DMX/DTC-436 Chip) haengt hier mit dem flaschen IO-Port (alles ausser 0x280) zuverlaessig die Kiste auf. Sysrq-s Sysrq-u Sysrq-b bzw. Reset-Taster, und naechster Versuch ;) Ja, das ist "veraltet", unelegant usw. aber wirksam(!). Zumal, wenn man bei solcher HW dann per Google doch noch den magischen IO-Port findet ;) Und wenn es einmal laeuft, dann laeufts. Da wirft einem kein hotplug o.ae. noch die IRQs und Ports durcheinander. Also bei Experimenten moeglichst nur in Runlevel S oder 1 booten, und mit 'modprobe modulname option=value' die Parameter testen usw... Die "richtigen" Optionen kann man dann in der /etc/{modules,modprobe}.conf festhalten. Fuer fest einkompiliertes muss man wohl jedesmal rebooten und bei GRUB die Kommandozeile editieren... Mit LILO muss man jedesmal die /etc/lilo.conf editieren, lilo aufrufen und rebooten... Die richtigen Daten haelt man dann in den Configdateien des Bootloaders fest. Bei LILO mittels 'append="option=value"', bei GRUB mittels 'kernel IMAGE option=value'. -dnh, der lieber Jumper/Dip-Schalter hat als von Plug'n'Pray abhaengig zu sein. Und der auch lieber IRQs usw. im BIOS einstellt / jumpert usw. als dass er dann auf Slot-Tausch-Orgien angewiesen ist, zumal wenn die IRQ-Verdrahtung der Slots nicht mal im Handbuch dokumentiert ist. Und ja, bei mir ist kein IRQ doppelt belegt -- und das mit den 15 XT-PIC Standard-IRQs. Auch unter Win95 nicht. Ok, ich hab weder USB noch IEEE1394. Aber noch 2 freie IRQs. -- Hochwertige Dokumente muessen in der heutigen Zeit auf auf preiswerter Hardware zu Erstellen sein. Nicht jeder kann sich einen teueren Rechner fuer 100 Euro oder mehr leisten. -- Uwe Borchert in dctt
Hallo, vielen Dank für deine Umfassende Antwort. Du lässt ja kaum Fragen offen :-) Am Dienstag, 31. August 2004 04:20 schrieb David Haller:
less /usr/src/linux/Documentation/kernel-parameters.txt
Ich sehe schon, da gibt es eine Menge Parameter..
Weiters kennen u.U. manche Module auch (IRQ-)Parameter, die nicht in o.g. Datei dokumentiert sind. Da muss man ggfs. die Doku zu dem Modul lesen. Und zur Not kann man auch noch die Kernelquellen nach dem magischen Makro 'MODULE_PARM' (2.4.x) durchgreppen (per find oder mc o.ae.)...
OK
Und wenn ein Modul einen irq-Parameter kennt reicht das ja schon, z.B.:
parport=0x278,5,auto
Davon hatte ich auch schon gehört, aber immer nur im Zusammenhang mit NICs, deswegen habe ich mich damit erstmal etwas zurückgehalten.
ACHTUNG: Manche Module / Treiber / Hardware ist empfindlich gegen "falsche" Parameter, meine billig ISA-SCSI-Karte (DMX / DTC 3181E mit DMX/DTC-436 Chip) haengt hier mit dem flaschen IO-Port (alles ausser 0x280) zuverlaessig die Kiste auf. Sysrq-s Sysrq-u Sysrq-b bzw. Reset-Taster,
Gut, dass du diese Tasten mal erwähnt hast. Ich habe mich schon länger gefragt, was diese Option "Magic Sys RQ-Keys aktivieren" in den Sicherheitseinstellungen von Yast bringt. Jetzt habe ich mich mal etwas informiert: /usr/src/linux/Documentation/sysrq.txt Sysrq-s, Sysrq-u und Sysrq-b Synchronisieren das Dateisystem, Umounten es, mounten es RO und Rebooten dann? Ist das nicht wesentlich freundlicher als der Reset-Knopf?
und naechster Versuch ;) Ja, das ist "veraltet", unelegant usw. aber wirksam(!). Zumal, wenn man bei solcher HW dann per Google doch noch den magischen IO-Port findet ;) Und wenn es einmal laeuft, dann laeufts. Da wirft einem kein hotplug o.ae. noch die IRQs und Ports durcheinander.
Ich schätze mal, es
Also bei Experimenten moeglichst nur in Runlevel S oder 1 booten, und mit 'modprobe modulname option=value' die Parameter testen usw... Die "richtigen" Optionen kann man dann in der /etc/{modules,modprobe}.conf festhalten.
Guter Tipp. Ich hätte wahrscheinlich versucht, das System bis in Runlevel 3 zu booten.
-dnh, der lieber Jumper/Dip-Schalter hat als von Plug'n'Pray abhaengig zu sein. Und der auch lieber IRQs usw. im BIOS einstellt / jumpert usw. als dass er dann auf Slot-Tausch-Orgien angewiesen ist, zumal wenn die IRQ-Verdrahtung der Slots nicht mal im Handbuch dokumentiert ist. Und ja, bei mir ist kein IRQ doppelt belegt -- und das mit den 15 XT-PIC Standard-IRQs. Auch unter Win95 nicht. Ok, ich hab weder USB noch IEEE1394. Aber noch 2 freie IRQs. Ich glaube, ich habe nur 7 IRQs (billiges Mobo). Zumindest habe ich das letztens irgendwo im BIOS gelesen.
Da scheint es wohl unvermeidlich, dass IRQS geteilt werden: soeren@linux:~> cat /proc/interrupts CPU0 0: 23785098 XT-PIC timer 1: 45923 XT-PIC i8042 2: 0 XT-PIC cascade 5: 1421826 XT-PIC ohci_hcd, radeon@PCI:1:0:0 9: 0 XT-PIC acpi 11: 488086 XT-PIC eth0, ohci_hcd, EMU10K1 12: 1161535 XT-PIC i8042 14: 349097 XT-PIC ide0 15: 2610 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 75 MIS: 0 Wobei ich jetzt wieder nicht weiß, was NMI, LOC, ERR und MIS sind... BTW: ERR = Errors? Ist das irgendwie schlimm, dass dort 75 steht? Vielen Dank für die ausführliche Antwort! Gruß Sören
Hallo, Am Tue, 31 Aug 2004, Sören Wengerowsky schrieb:
vielen Dank für deine Umfassende Antwort. Du lässt ja kaum Fragen offen :-)
:)
Am Dienstag, 31. August 2004 04:20 schrieb David Haller:
less /usr/src/linux/Documentation/kernel-parameters.txt
Ich sehe schon, da gibt es eine Menge Parameter..
Jup. [..]
Und wenn ein Modul einen irq-Parameter kennt reicht das ja schon, z.B.:
parport=0x278,5,auto
Davon hatte ich auch schon gehört, aber immer nur im Zusammenhang mit NICs, deswegen habe ich mich damit erstmal etwas zurückgehalten.
Man muss halt schauen, welche Module man verwendet... ;)
ACHTUNG: Manche Module / Treiber / Hardware ist empfindlich gegen "falsche" Parameter, meine billig ISA-SCSI-Karte (DMX / DTC 3181E mit DMX/DTC-436 Chip) haengt hier mit dem flaschen IO-Port (alles ausser 0x280) zuverlaessig die Kiste auf. Sysrq-s Sysrq-u Sysrq-b bzw. Reset-Taster,
Gut, dass du diese Tasten mal erwähnt hast. Ich habe mich schon länger gefragt, was diese Option "Magic Sys RQ-Keys aktivieren" in den Sicherheitseinstellungen von Yast bringt. Jetzt habe ich mich mal etwas informiert: /usr/src/linux/Documentation/sysrq.txt
*g*
Sysrq-s, Sysrq-u und Sysrq-b Synchronisieren das Dateisystem, Umounten es, mounten es RO und Rebooten dann? Ist das nicht wesentlich freundlicher als der Reset-Knopf?
Ja. Zumindest was die Dateisysteme angeht. Voraussetzung ist natuerlich, dass die Tastendruecke noch beim Kernel ankommen, wenn X sich mal verheddert, dann ist ja leider oefters die Tastatur gestoert, dann geht das nicht mehr. Dann kommt man aber evtl. noch per Netz oder mit nem Joystick ran. Hm. Auf welche Joystick-Kombi hab ich das nochmal gelegt? Und joyd koennte ich auch per default starten. Und die Config nochmal anschauen ;)
und naechster Versuch ;) Ja, das ist "veraltet", unelegant usw. aber wirksam(!). Zumal, wenn man bei solcher HW dann per Google doch noch den magischen IO-Port findet ;) Und wenn es einmal laeuft, dann laeufts. Da wirft einem kein hotplug o.ae. noch die IRQs und Ports durcheinander.
Ich schätze mal, es
?
Also bei Experimenten moeglichst nur in Runlevel S oder 1 booten, und mit 'modprobe modulname option=value' die Parameter testen usw... Die "richtigen" Optionen kann man dann in der /etc/{modules,modprobe}.conf festhalten.
Guter Tipp. Ich hätte wahrscheinlich versucht, das System bis in Runlevel 3 zu booten.
*g* Wenn du aus hoeheren Runleveln kommst, solltest du moeglichst viel unmounten, 2 mal syncen, und den Rest dann ro-remounten. Dann schadet auch der Reset-Taster den Dateisystemen nicht, falls sich die Tastatur weghaengt. Das ist also aehnlich wie Sysrq-s, Sysrq-u.
-dnh, der lieber Jumper/Dip-Schalter hat als von Plug'n'Pray abhaengig zu sein. Und der auch lieber IRQs usw. im BIOS einstellt / jumpert usw. als dass er dann auf Slot-Tausch-Orgien angewiesen ist, zumal wenn die IRQ-Verdrahtung der Slots nicht mal im Handbuch dokumentiert ist. Und ja, bei mir ist kein IRQ doppelt belegt -- und das mit den 15 XT-PIC Standard-IRQs. Auch unter Win95 nicht. Ok, ich hab weder USB noch IEEE1394. Aber noch 2 freie IRQs. Ich glaube, ich habe nur 7 IRQs (billiges Mobo). Zumindest habe ich das letztens irgendwo im BIOS gelesen.
Aeh, das im BIOS bezieht sich nur auf die IRQs die du evtl. auf die PCI-IRQs (INT A - INT D) verteilen kannst. Du hast aber schon die normalen 16 IRQs, die man ohne APIC (Advanced Programmable Interrupt Controller) eben hat.
Da scheint es wohl unvermeidlich, dass IRQS geteilt werden: soeren@linux:~> cat /proc/interrupts CPU0 0: 23785098 XT-PIC timer 1: 45923 XT-PIC i8042 2: 0 XT-PIC cascade 5: 1421826 XT-PIC ohci_hcd, radeon@PCI:1:0:0 9: 0 XT-PIC acpi 11: 488086 XT-PIC eth0, ohci_hcd, EMU10K1 12: 1161535 XT-PIC i8042 14: 349097 XT-PIC ide0 15: 2610 XT-PIC ide1
Wie man sieht verwendest du kein APIC, sondern den normalen PIC. Und hast die IRQs 0-15, wobei 3,4,7,10 und 13 frei sind. 6 und 8 sind prinzipiell "fest" vom Chipsatz / der CPU belegt (IRQ 8 = rtc, IRQ 6 weiss ich grad nicht mehr) und koennen nicht durch normale HW verwendet werden. An deiner Stelle wuerde ich mal in den Optionen von EMU10K1 kruschteln, ob du das nicht auf IRQ7 legen kannst (das ist seit dem UR-Soundblaster der klassische IRQ fuer die Soundkarte ;), und USB (ohci_hcd) und die Graka (radeon) und Ethernet (eth0) solltest du auch auseinander bringen koennen... Ob und wie du da aber einen IRQ angeben kannst weiss ich nicht. Zumindest bei der Grafikkarte solltest du auch im BIOS schauen (bzw. auf dem Schirm, der vor dem Bootmanager kommt -- achso, Mist, mit nem grafischen LILO oder Grub sieht man das ja nicht mehr :-(()
NMI: 0 LOC: 0 ERR: 75 MIS: 0
Wobei ich jetzt wieder nicht weiß, was NMI, LOC, ERR und MIS sind...
less /usr/src/linux/Documentation/filesystems/proc.txt NMI ist "Non Maskable Interrupt", das sind IRQs, die nicht "abgefangen" werden koennen und immer direkt an die CPU gehen. "LOC is the local interrupt counter of the internal APIC of every CPU." Da du kein APIC verwendest... ==== ERR is incremented in the case of errors in the IO-APIC bus (the bus that connects the CPUs in a SMP system). This means that an error has been detected, the IO-APIC automatically retry the transmission, so it should not be a big problem, but you should read the SMP-FAQ. ==== Im Beispiel in o.g. Datei steht 'ERR' bei 2155 ;) Wofuer "MIS" steht weiss ich jetzt auch nicht, da's in obiger Datei nicht erklaert wird. Ich vermute jetzt einfach mal, dass das fuer "missed" steht. Was jetzt ein "missed IRQ" ist? Da muesste ich mal die (verdaechtigen Teile der) Kernelquellen durchgreppen, vielleicht gibt's da interessante Kommentare ;)
BTW: ERR = Errors? Ist das irgendwie schlimm, dass dort 75 steht?
s.o. Bei mir[1] hab ich bisher immer nur 0 fuer alle 4 Werte gesehen. Ich schau aber auch nicht oft nach ;) Koennte auch daran liegen, dass bei mir kein IRQ doppelt belegt ist. Apropos... Sorry... <rant type="bitter" type="cynical" type="disillusioned"> Ich hab seit '95 Erfahrung mit PnP und sonstigen "IRQs automatisch verteilen" Automatismen unter Win95, Win98 und unter Linux seit 2.0.35. Mit diversen BIOSen. *Kein* mir untergekommener Automatismus hat die IRQs optimal, und oft nicht einmal funktional, auf die Geraete verteilt. Zumal, dass "IRQ-Sharing funktioniert", ist bis heute oft eine Maer... Manches vertraegt sich, vieles nicht... Und dann die IRQs an den Automatismen vorbei manuell zuzuweisen war und ist oft schwieriger, als das ganze von vorherein per Hand im BIOS, im OS (irq-Parameter, Geraetemanager bzw. bei der Installation) oder auch per Jumper auf der Hardware zu erledigen. "PnP OS = no" im BIOS ist Pflicht... Mit APIC -- sofern es denn funktioniert -- hat man mehr IRQs, aber AFAIK verteilen die Automatismen dann trotzdem munter den gleichen IRQ (9 scheint sehr beliebt) an $zuviele Geraete... In der Beziehung war man anno 96 besser dran, da hat die HW dann normalerweise entweder ganz oder garnicht funktioniert. Heute hat man nicht reproduzierbare Aussetzer usw. usf. die u.U. durch geteilte IRQs verursacht sein koennen... Und statt das im BIOS oder OS einstellen zu koennen, darf man oft Karten jonglieren (wie fortschrittlich, "Plug'n'Play indeed!" -- wir spielen Karten umstoepseln), was besonders Spass macht, wenn von den 4 Karten 2 nur in 2 von 5 Slots und eine der anderen 2 Karten nur in genau einen Slot passen, was andererseits die moeglichen Kombinationen reduziert... Na danke... AHS. ASS. </rant>
Vielen Dank für die ausführliche Antwort!
Bitte. Wenn ich mag, dann kann ich mehr als "RTFM" und "RTFFAQ" ;) -dnh [1] AMD Athlon 500 (fam: 6, model 1, stepping 2); MSI MS-6167 mit AMD-751 "Irongate" North- und AMD-756 "Viper" Southbridge (keine VIA Southbridge, wie fast alle anderen Slot-A MoBos ;) Der AMD-756 war jedenfalls ausgereifter, als die damaligen passenden VIA Southbridges (686[AB]?) ;) -- 75: Plattencrash Ausrede für fehlerhafte Systemadministration jeglicher Art (Johann H. Addicks)
Hallo, Am Mittwoch, 1. September 2004 02:51 schrieb David Haller:
Ich schätze mal, es
?
Ka, was ich da eigentlich für einen Satz anfangen wollte. muss ich dann wohl übersprungen und vergessen haben...
*g* Wenn du aus hoeheren Runleveln kommst, solltest du moeglichst viel unmounten, 2 mal syncen, und den Rest dann ro-remounten. Dann schadet auch der Reset-Taster den Dateisystemen nicht, falls sich die Tastatur weghaengt. Das ist also aehnlich wie Sysrq-s, Sysrq-u.
Der Reset Schalter ist bei mir aufgrund der Windows-Vorzeit meines Rechners sowieso kaum noch gebrauchbar.. ;-)) Daher suche ich nach Alternativen.
Aeh, das im BIOS bezieht sich nur auf die IRQs die du evtl. auf die PCI-IRQs (INT A - INT D) verteilen kannst. Du hast aber schon die normalen 16 IRQs, die man ohne APIC (Advanced Programmable Interrupt Controller) eben hat.
Achso.. dann macht das alles Sinn. Ich habe mich schon gewundert, dass in /proc/interrupts so viele IRQs stehen.
Wie man sieht verwendest du kein APIC, sondern den normalen PIC. Und hast die IRQs 0-15, wobei 3,4,7,10 und 13 frei sind. 6 und 8 sind prinzipiell "fest" vom Chipsatz / der CPU belegt (IRQ 8 = rtc, IRQ 6 weiss ich grad nicht mehr) und koennen nicht durch normale HW verwendet werden.
An deiner Stelle wuerde ich mal in den Optionen von EMU10K1 kruschteln, ob du das nicht auf IRQ7 legen kannst (das ist seit dem UR-Soundblaster der klassische IRQ fuer die Soundkarte ;),
Ganz blöde Frage: Wo finde ich die Optionen von dem Modul? In /etc/modules.conf habe ich nichts gefunden. Auch in /usr/src/linux/Documentation/sound/alsa und /usr/src/linux/Documentation/sound/oss konnte ich nichts finden. Google scheint mir auch nicht so das richtige dazu auszuspucken. Stichwörter: emu10k1 modul optionen
und USB (ohci_hcd) und die Graka (radeon) und Ethernet (eth0) solltest du auch auseinander bringen koennen... Ob und wie du da aber einen IRQ angeben kannst weiss ich nicht. Zumindest bei der Grafikkarte solltest du auch im BIOS schauen (bzw. auf dem Schirm, der vor dem Bootmanager kommt -- achso, Mist, mit nem grafischen LILO oder Grub sieht man das ja nicht mehr :-(()
Im BIOS werde ich mal nachsehen. Aber IIRC war dort nur die Auswahl zwischen 5 IRQs und 7 IRQs für PCI. Aber das werde ich nochmal genauer ansehen. Vielleicht gibt es ja auch noch etwas zu jumpern.
less /usr/src/linux/Documentation/filesystems/proc.txt
Wieder eine sehr schöne Doku.
NMI ist "Non Maskable Interrupt", das sind IRQs, die nicht "abgefangen" werden koennen und immer direkt an die CPU gehen.
Apropos... Sorry...
<rant type="bitter" type="cynical" type="disillusioned">
Ich hab seit '95 Erfahrung mit PnP und sonstigen "IRQs automatisch verteilen" Automatismen unter Win95, Win98 und unter Linux seit 2.0.35. Mit diversen BIOSen. *Kein* mir untergekommener Automatismus hat die IRQs optimal, und oft nicht einmal funktional, auf die Geraete verteilt. Zumal, dass "IRQ-Sharing funktioniert", ist bis heute oft eine Maer... Manches vertraegt sich, vieles nicht...
Tja.. wie gesagt, ich habe mich fast schon an diese Slot-Tausch-Orgien, wie du es nennst, gewöhnt. Allerdings will ich es natürlich auch mal per Hand versuchen, wenn es Vorteile bezüglich der Stabilität usw. bringt.
Und dann die IRQs an den Automatismen vorbei manuell zuzuweisen war und ist oft schwieriger, als das ganze von vorherein per Hand im BIOS, im OS (irq-Parameter, Geraetemanager bzw. bei der Installation) oder auch per Jumper auf der Hardware zu erledigen. "PnP OS = no" im BIOS ist Pflicht...
Ich werde es am Wochenende einmal ausprobieren, was dann passiert, wenn ich das ausschalte. *g*.
Mit APIC -- sofern es denn funktioniert -- hat man mehr IRQs, aber AFAIK verteilen die Automatismen dann trotzdem munter den gleichen IRQ (9 scheint sehr beliebt) an $zuviele Geraete... In der Beziehung war man anno 96 besser dran, da hat die HW dann normalerweise entweder ganz oder garnicht funktioniert. Heute hat man nicht reproduzierbare Aussetzer usw. usf. die u.U. durch geteilte IRQs verursacht sein koennen...
Also bei mir läuft momentan eigentlich alles Recht gut. Ich kann natürlich nicht wissen, ob es nicht alles viel besser wäre, wenn jedes Gerät einen eigenen IRQ hätte. Meine Graka z.B. sollte eigentlich über 500 fps schaffen (glaube ich). Doch bei glxgears schafft sie nur 450 oder so.. Aber das stört mich eigentlich nicht, da ich meine Graka nur für Desktop-Anwendungen und terminal verwende. Da könnte ich mir einen Zusammenhang vorstellen. Ist es eigentlich für die Hardware schonender, wenn jedes Gerät einen eigenen IRQ zugewiesen hat, als wenn sie sich einen teilen müssen? Wäre eine Leistungssteigerung bezüglich der Performance zu erwarten?
Und statt das im BIOS oder OS einstellen zu koennen, darf man oft Karten jonglieren (wie fortschrittlich, "Plug'n'Play indeed!" -- wir spielen Karten umstoepseln), was besonders Spass macht, wenn von den 4 Karten 2 nur in 2 von 5 Slots und eine der anderen 2 Karten nur in genau einen Slot passen, was andererseits die moeglichen Kombinationen reduziert... Na danke...
Es werden dem User aber fast in allen Richtungen die Freiheiten mehr und mehr genommen. Da wird leider auch vor dem BIOS kein Halt gemacht. Gruß Sören
Hallo, Am Thu, 02 Sep 2004, Sören Wengerowsky schrieb:
Am Mittwoch, 1. September 2004 02:51 schrieb David Haller:
Ich schätze mal, es
?
Ka, was ich da eigentlich für einen Satz anfangen wollte. muss ich dann wohl übersprungen und vergessen haben...
*g*
Ganz blöde Frage: Wo finde ich die Optionen von dem Modul? In /etc/modules.conf habe ich nichts gefunden.
Auch in
/usr/src/linux/Documentation/sound/alsa und /usr/src/linux/Documentation/sound/oss konnte ich nichts finden.
Ich jetzt auch nicht. Die passende Doku scheint Documentation/sound/alsa/ALSA-Configuration.txt zu sein. Normalerweise spuckt ein 'modinfo' die Parameter aus, aber das scheint auch nicht der Fall zu sein. Also hab ich mal im 2.6.1 den ich hier rumfahren habe in die authoritative Doku geschaut: linux-2.6.1/sound/pci/emu10k1 (0)$ grep MODULE_PARM emu10k1.c Das ergibt tatsaechlich nur die in ALSA-Configuration.txt dokumentierten Parameter. [..]
Im BIOS werde ich mal nachsehen. Aber IIRC war dort nur die Auswahl zwischen 5 IRQs und 7 IRQs für PCI. Aber das werde ich nochmal genauer ansehen.
Das wuerde ich versuchen.
Vielleicht gibt es ja auch noch etwas zu jumpern.
Kaum ;(
less /usr/src/linux/Documentation/filesystems/proc.txt
Wieder eine sehr schöne Doku.
*g* [..]
Tja.. wie gesagt, ich habe mich fast schon an diese Slot-Tausch-Orgien, wie du es nennst, gewöhnt.
Ich habe hier bisher Karten nur aus mechanischen Gruenden getauscht. *hehe*
Allerdings will ich es natürlich auch mal per Hand versuchen, wenn es Vorteile bezüglich der Stabilität usw. bringt.
Generell gab's ja, gerade mit SB-Karten, gerne Mal komische Probleme, wenn da ein IRQ geteilt wurde... Im grossen und ganzen ist es wohl vorteilhaft, von vornherein dafuer zu sorgen, dass die IRQs eben moeglichst du verteilt werden.
Und dann die IRQs an den Automatismen vorbei manuell zuzuweisen war und ist oft schwieriger, als das ganze von vorherein per Hand im BIOS, im OS (irq-Parameter, Geraetemanager bzw. bei der Installation) oder auch per Jumper auf der Hardware zu erledigen. "PnP OS = no" im BIOS ist Pflicht...
Ich werde es am Wochenende einmal ausprobieren, was dann passiert, wenn ich das ausschalte. *g*.
*g* Ich weiss allerdings nicht, wie sich's verhaelt, wenn man das nach der Installation umstellt -- die 3 Male nach meinem "Ur-PC", wo ich ein neues MoBo in Betrieb genommen habe, war das erste immer ein Gang ins BIOS wo ich u.a. dann ggfs. PNP Os auf "no" gestellt habe ;) [..]
Also bei mir läuft momentan eigentlich alles Recht gut. Ich kann natürlich nicht wissen, ob es nicht alles viel besser wäre, wenn jedes Gerät einen eigenen IRQ hätte.
Schaden kann es jedenfalls nicht.
Ist es eigentlich für die Hardware schonender, wenn jedes Gerät einen eigenen IRQ zugewiesen hat, als wenn sie sich einen teilen müssen?
Nein, "schonender" sicher nicht.
Wäre eine Leistungssteigerung bezüglich der Performance zu erwarten?
Kommt auf die IRQ-Lastigkeit der HW an. Manche HW generiert massiv IRQs, andere kaum welche... Wenn jetzt, wie ich schon oefter gesehen, fast alle HW einen IRQ teilt, dann kann es natuerlich dazu kommen, dass sich die HW schon allen wegen der hohen IRQ-Last gegenseitig stoert. Und dann gibt's natuerlich noch HW (wie IIRC gerade Soundblaster Karten) die generell IRQ-Sharing nicht mag. Ob die Emu10k Karten noch dazu gehoeren weiss ich nicht. Ich wuerde aber auf jeden Fall versuchen der GraKa und Soundkarte jew. einen eigenen IRQ zuzuweisen.
Es werden dem User aber fast in allen Richtungen die Freiheiten mehr und mehr genommen. Da wird leider auch vor dem BIOS kein Halt gemacht.
Eben. *seufz* -dnh -- Bei den meisten Männern reicht es nicht zum Begreifen, nur zum Begrabbeln. -- Gabriele Conrad
participants (2)
-
David Haller
-
Sören Wengerowsky