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
