Hallo,
also, da scheinen ein paar Irrtümer rumzugeistern, deshalb mal alles zusammengefasst:
PCI kann Interrupt-Sharing, weil die Interrupts nicht per Level (also logisch Null
statt
logisch 1)
gemeldet werden, sondern per Flanke. Ich glaube sogar, dass ist die ansteigende
Flanke.
Da der Ruhepegel aber auch auf der Eins ist, muss ein Baustein, der einen Interrupt
anfordern
will, erst auf die Null schalten (dann ist die Leitung natürlich belegt, da eine
weitere Null
natürlich nicht auffällt), dann aber auf die Eins zurück, weil erst diese Flanke den
Interrupt tatsächlich auslöst. ISA hatte noch Pegeltriggerung und damit sich der PIC
(der
Interrupt-Empfänger vor der CPU) nicht verhedderte, musste der Pegel sogar bis zum
Ende der Service-Routine stehen bleiben.
Jeder On-Board-Baustein hat einen fest zugeordneten Interrupt, an dem sich in der
Regel auch nicht rütteln lässt. Das betrifft zum Beispiel im vorliegenden Fall
wahrscheinlich den USB-Teil des Ganzen (außer, das ist eine Steckkarte).
Ein eventueller PCMCIA-Slot (ich denke mal, eth0 ist sowas) ist natürlich auch fest an
einen IRQ geklemmt (durch die PCMCIA-Schnittstelle).
Steckkarten sind auch festgelegt, aber auf einen bestimmten PCI-Interrupt. Das sind
vier Kontakte an den Steckern, die INT A bis INT D heißen. Die sind alle vier an allen
vier Slots zu finden, insgesamt hat PCI aber auch nur vier System-Interrupts zum
Verteilen. Deshalb werden diese INT-Leitungen der Slots geschickt miteinander
verdrahtet (INT A von Slot 1 mit INT B von Slot 2 usw.) Die genaue Zuordnung macht
jeder Hersteller nach seinem Gusto. Bei Laptops sind ja meist keine oder nur wenige
PCI-Slots da. Da wird dieses Problem also weniger. Es ist aber klar:
Angenommen, ich habe zwei Karten a und b. Bei a ist INT A benutzt, bei b INT B (die
Norm verlangt zwar, dass alle INT A benutzen, außer bei Kombikarten, aber da hält sich
nicht jeder dran). Secke ich Karte a in Slot 1 und Karte b in den Zweier, dann kann es
sein, dass die beiden auf dem gleichen IRQ auftauchen, denn Slot 1 INT A ist oft mit
Slot
2 INT B zusammen. Auch ein Umsetzen des PCI-INT auf einen anderen IRQ nützt
nichts, es trifft beide. Tauschen aber hilft, denn Slot 1 INT B ist umgekehrt eher
selten
dann auch wieder mit Slot 2 INT A zusammen (zumindest nicht bei diesem MB).
Ein zu massiv geshareter IRQ kann sehr wohl zu Problemen führen, denn innerhalb der
Handler-Routine (ein Vor-Handler ist dafür nötig) muss der tatsächlich um den
Interrupt
nachsuchende Baustein ja erst per Polling ermittelt werden. Das stört manchmal den
laufenden Betrieb, da das betreffende Register bei den heute meist nur aus einem Chip
mit ein wenig Kleinkram drumherum bestehenden Steckkarten eben in diesem Chip ist.
Da kann es dann sein, dass der Zugriff auf das Interrupt-Pending-Flag über eben den
internen Datenbus des Peripherie-Chips läuft, der gerade eigentlich anderweitig
benötigt
wird.
Dann stört sowas, vor allem, wenn dieser Chip eben gerade nicht bedient werden wollte,
weil er eigentlich schon voll mit Arbeit eingedeckt ist. USB ist da ein gewisser
Störfaktor,
da diese Chips (warum auch immer) recht viele Interrupts erzeugen. Außerdem stimmt
es nicht ganz, dass zwei Interrupts nicht parallel laufen können, aber bei geshareten
Interrupts muss das nicht klappen. Der erste Interrupt aus diesem Kanal läuft ja noch,
also ist unter Umständen das Interrupt-Pending-Flag dieses entsprechenden Bausteins
gesetzt. Bei einem erneuten Interrupt auf diesem IRQ wird ja auch von Neuem gepollt
und dann irrigerweise dieses gesetzte Interrupt-Pending-Flag für ein Zeichen einer
neuen Anforderung gehalten, dabei wurde die dazu gehörende Runde der Service-
Routine gerade unterbrochen. So kommt dann der den Interrupt tatsächlich brauchende
Baustein nie zu seinem Service, und der andere wird nie fertig mit dieser Schleife. Ob
sowas passiert, hängt natürlich von der Reihenfolge beim Pollen ab (und die wiederrum
von der Reihenfolge des Einbindens der Hardware).
Auch bei PCI gibt es also durchaus ein paar Klippen zu Umschiffen.
Wenn die Soundkarte im Slot steckt und da ist noch einer, wäre ein Tauschen des Slots
die beste Lösung für das Problem. Sonst bleibt eigentlich nur noch eine teurere
Soundkarte mit mehr Hardware für den Sound, die mehr alleine machen kann. Dann
fallen zumindest die Störungen durch falsches Polling (siehe direkt obendrüber) nicht
so
sehr auf. Auch kann es dann sein, dass auf dem internen Bus ein Parallelbetrieb von
CPU-Zugriffen und internem Verkehr möglich ist. Dann stört auch das Polling nicht
mehr.
Tschüß
Manfred
From: Hans Freitag <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [PUG] Alles auf IRQ 11
Send reply to: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]?subject=subscribe>
<mailto:[EMAIL PROTECTED]?subject=unsubscribe>
Date sent: Fri, 7 Feb 2003 09:45:21 +0100
> On Fri, Feb 07, 2003 at 09:01:26AM +0100, Valentin Heinitz wrote:
> > Aber wenn ich so nachdenke, arbeitet CPU beim Intrrupt sowieso eine Interrupt
> > Service Routine ab. Die Nummer ist dabei voellig egal. Zwei Interrupt Service
> > Routinen koennen sowieso nicht gleichzeitig ausgefuert werden.
>
> Das problem ist glaube ich eher zu erkennen welche Interrupt service
> routine ausgeführt werden soll.
>
>
> --
> May the source be with you!
>
> ----------------------------------------------------------------------------
> PUG - Penguin User Group Wiesbaden - http://www.pug.org
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
