Hallo,
ich habe 2 4fach ISDN PCI Karten unter Ubuntu 10.04 64Bit am laufen.
Dialogic Divas 4Bri
Als Treiber verwende ich den vom Hersteller.
Diese Karten gibt es schon sehr lange ca 2002 also zu Zeiten von P4.
Nun ist es so das eine Karte im System problemlos läuft, bei 2 karten
ich schon einträge im syslog habe:
nobody cared (try booting with the "irqpoll" option)
Darauf habe ich die Bootoption irqpoll eingebaut. Das System läuft nun
ohne dieser Meldungen jedoch crasht gelegentlich der Treiber der Karte,
das passiert aber nur wenn 2 Karten im System sind. Ich denke aber
immernoch das es warscheinlich mit den IRQs probleme gibt.
Ich habe schon verschiedene Mainboards getestet das Verhalten war immer
anders, meist schlechter. Eigentlich sollte das System auch mit einer
schwachen CPU laufe, z.b. Celeron, was aber die Crashs sehr viel
häufiger machte. Im Moment ist ein i3-2120 CPU @ 3.30GHz eingebaut.
In einem C2D Quad 9550 Board wird sogar nur eine Karte erkannt. Beim
Start kommt die Meldung das die eine sich nicht initialisieren lässt.
Die Karten sind definitiv vom Hersteller geeignet um mehrere (bis zu 8)
in ein System eingebaut zu werden.
Ich habe noch einen alten P4 3.0Ghz in dem werde ich auch noch testen.
Eine Karte ist auf IRQ16 die andere auf 17.
War früher das IRQ Verhalten von P4 478 - Boards irgendwie anders?
Wiso läuft es mit einer Celeron CPU schlechter obwohl die immernoch um
einiges schneller ist als ein damaliger Skt478 P4? Weniger IRQs möglich?
Kommt es auf den Chipsatz an? Der I3 hat ja eigentlich keine Northbridge
mehr.
hat ein Serverboard ein besseres IRQ Handling? Die Karten machen ja
ordentlich IRQs in der Zeit
uptime
10:11:03 up 1 day, 12:11, 1 user, load average: 0.31, 0.16, 0.11
Durch das Verschwinden von UART und LPT auf den Mainboards hast du jetzt
IRQ 3, 4, 5 und 7 frei. Vllt lohnt es sich, die Karten auf diese zu
legen, damit sie exklusive IRQ haben? Oder erlauben das die Karten
nicht?
Läuft bei debian standardmäßig so ein "irqbalance", das ständig an der
IRQ-Affinität rumwurstet?
=> Versuch das mal zu unterbinden.
Dann, versuch die Karten auf möglichst eigene IRQs zu legen.
Schließlich:
mittels /proc/irq/xxx/affinity_hint o.Ä. alle Karten auf einen Core
festnageln.
Wenn der Treiber aus der P4-Era nicht wirklich SMP-Fähig ist, hilft das
evtl.
Matthias Sch. schrieb:> Oder erlauben das die Karten nicht?
PCI-Karten können und dürfen sich ihren Interrupt gar nicht selbst
aussuchen. Dieser wird vom ACPI-BIOS bzw. vom Betriebssystem zugeteilt.
Laut Spec müßten sogar alle Karten problemlos mit demselben IRQ laufen,
wenn, ja WENN der Treiber sauber programmiert ist. In der Praxis gibt es
jedoch gelegentlich immer noch Probleme, wie man sieht. Ich würde zuerst
nach einem aktuelleren Treiber suchen, alles andere ist
Symptombekämpfung.
Der Tipp mit dem Treiber hat mich schonmal veranlasst etwas genauer zu
suchen, danke. Eine Möglichkeit die Karte an einen IRQ zu binden gibt es
scheinbar nicht. Das Irqbalance kann sein das es aktiv ist, werde ich
mir noch anschauen.
Jedenfalls habe ich gedacht das nach der Installation des Treibers
dieser auch verwendet wird, das ist scheinbar nicht so, es wird
weiterhin der "alte" des Kernels geladen, der neue liegt nicht verwendet
da. Das muß ich mir ansehen.
Luxxer schrieb:> das ist scheinbar nicht so, es wird> weiterhin der "alte" des Kernels geladen
Wer zuerst kommt mahlt zuerst. Einen unerwünschten Kerneltreiber muss
man ausschliessen, irgendwo in den Konfigurationsdateien, Näheres weiss
ich im Moment auch nicht. Ist aber ein häufiges Problem, ich kenne das
von Audiotreibern, da muss man oft eintragen dass der Standardtreiber
nicht verwendet werden darf.
Gruss Reinhard
Das Laden von bestimmten Modulen wird durch eine 'blacklist' in
/etc/modprobe.d bestimmt. Ist ein Modul dort eingetragen, wird es nicht
geladen. Mehr dazu hier:
http://ubuntuforums.org/showthread.php?t=166624Icke ®. schrieb:> PCI-Karten können und dürfen sich ihren Interrupt gar nicht selbst> aussuchen. Dieser wird vom ACPI-BIOS bzw. vom Betriebssystem zugeteilt.
Das sollte tatsächlich so sein, allerdings kenne ich es gerade von
frühen ISDN Karten, das die Treiber nicht besonders kooperativ waren,
wenn sie sich in eine bestehende IRQ Chain eingeklinkt haben. U.U. kann
man im BIOS IRQs für diesen Zweck reservieren.
hmm, weiß jemand wie ich feststellen kann in welchem Verzeichniss das
Modul liegt welches geladen wurde?
Die aktuellen Treiber liegen nicht im /lib/modules/.. Pfad.
modinfo brint immer den Pfad zu /lib/modules auch wenn ein Modul
garnicht geladen ist.
Die Kerneltreiber sind geblacklistet, die richtigen sollten per script
geladen werden.
Matthias Sch. schrieb:> U.U. kann man im BIOS IRQs für diesen Zweck reservieren.
Das geht aber nur für Legacy/ISA. Die IRQ-Leitungen für PCI sind auf den
Boards fest verdrahtet und meist teilen sich mehrere Slots eine
(Hardware)-IRQ. Das Sharing ist somit nahezu unvermeidbar. Zickigen
Karten kommt man nur durch Umstecken in andere Slots bei, sofern sie
sich dort nicht auch wieder mit anderen Komponenten streiten müssen.
Siehe u.a. hier:
http://www.heise.de/ct/Redaktion/ciw/irq.html
Es wird der richtige Treiber geladen, die Blacklist wirkt, das Script
zum laden der Treiber funktioniert.
Wiso gibt es die Kerneloption irqpoll?
Angeblich werden dadurch die Schnittstellen schneller abgefragt. Aber
dafür habe ich doch den IRQ das die Karte PU Zeit anfordern kann,
weshalb verliert die PU IQRs der karten ohne dieser Option?
Εrnst B✶ schrieb:> Wenn der Treiber aus der P4-Era nicht wirklich SMP-Fähig ist, hilft das> evtl.
Der Treiber ist Akuell, dieses Jahr sind schon 2-3 neue herausgekommen.
Das Verhalten am P4 war besser, es ist ein Skt478 Prescott 3.2GHz mit
einem 865 Chipsatz.
Das System lief ohne Kernel Option irqpoll und brachte keine Meldungen.
Thread beobachten
Seitenaufteilung abschalten