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)