Shared IRQ problemen met Junghanns ISDN kaart

[BarthezZ]

In onze Asterisk (op linux) telefonie server heb ik de laatste tijd een probleem dat gesprekken tijdelijk wegvallen en in syslog ik meldingen krijg zoals: "qozap: dropped audio card 1 cardid 0 bytes 17 z1 109 z2 76 fifo 3", dit blijkt te komen omdat er een interrupt (IRQ als ik het goed begrepen heb van de support) gedeeld wordt tussen de Junghanns Quad Bri ISDN kaart en een ander device. in dit geval of de IDE of de S-ata controller (beiden noodzakelijk), de meldingen zijn verder niet relevant voor dit topic.

Hardware specs zover bekend:
Asus P5b-vm do Retail
Intel CORE 2 QUAD Q6600 2.4GHZ SKT775 FSB1066 2X4MB CACHE BOXED IN (CORE2Q)
2x Kingston 1024MB 800MHZ DDR2 DIMM NON-ECC CL4 (5-5-5-15) NS (NMS)
Junghanns Quad BRI PCI ISDN Kaart
1 CF IDE Kaart (boot)
Software Raid (mirror) met 3 s-ata schijven (data)


Het doel is om de Junghanns PCI ISDN kaart zijn eigen irq/interrupt ruimte te geven zodat een ander device niet kan storen met de telefonie. Om dit te bereiken heb ik op het moederbord al alle mogelijke nutteloze devices (usb, audo, firewire etc) uit proberen te zetten zodat dat niet zou verstoren. Helaas bleef het probleem en blijkt volgens cat /proc/interrupts er op allebei de beschikbare PCI sloten ook een ander apparaat te zitten (s-ata of ide controller). Ook het unloaden van de IDE drivers heeft niet het gewenste effect gehad en zelfs er voor gezorgd dat de kernel segfault (ging niet helemaal netjes)

Nu heeft Junghanns en onze leverancier aangegeven dat het het verstandigst was om een nieuw moederbord aan te schaffen, maar geen van beiden kon aangeven wat een verstandige keuze was. Helaas geven fabrikanten vaak weinig informatie af over wat hun moederborden kunnen met interrupts en IRQ's en dergelijke en heeft de Asus support desk mij hier ook weinig meer over kunnen vertellen. Onze leverancier heeft het volgende bord aangedragen: Asus P5QL SE maar de support van Asus snapte weinig van mijn vraag over de interrupts en dergelijke.

Ik vroeg mij dus af of het mogelijk is om:
- Het huidige moederbord dermate te tweaken dat het een PCI slot zijn eigen IRQ/Interrupt geeft
- Het aangeboden Asus moederbord de gewenste feature heeft
- Een compleet ander moederbord te vinden die een PCI bord wél zijn eigen IRQ/interrupt kan geven.

[ Voor 9% gewijzigd door BarthezZ op 11-03-2009 18:16 . Reden: Offerte gevonden -> Specs aangevuld ]

[GENETX]

Wat raar dat Asus neits te melden heeft... Doorgaans zie ik nog altijd in de BIOS de optie om de IRQ's te wijzigen voor PCI slots en andere devices, er zijn er ook zat van.

Als het niet kan, kun je de kaart niet in een ander slot steken, of zijn er geen andere PCI slots over? Anders, kun je geen SATA controller voor PCI of PCIe scoren en zo de interne uitschakelen? Anders zou je wss idd een ander bord moeten halen. IRQ's kun je alleen in de BIOS wijzigen voor zover ik weet. 2 Interrupt Requests (IRQ)op 1 adres gaan inderdaad niet werken

Om je nog wat meer diepgang te geven over het ondwerwerp (en dus het echte probleem):
Een interrupt is een melding dat er iets is met het device. Het device onderbreekt daarom de CPU en de CPU zal zijn huidige taken even stilzetten om te "luisteren" naar de hardware die met de interrupt komt. De CPU zal dan deze behandelen en wanneer deze klaar is zal de CPU weer verder gaan met waar die gebleven was.

Ieder apparaat moet zijn eigen IRQ hebben. Je kan je wel voorstellen wat er gebeurt als er 2 op 1 lijn zitten. De modem gaat aandacht vragen van de CPU, maar de CPU denkt dat het van je SATA controller komt. Nee zegt de SATA controller, ik heb niets te melden.

[ Voor 70% gewijzigd door GENETX op 11-03-2009 19:09 ]

[BarthezZ]

GENETX schreef op woensdag 11 maart 2009 @ 19:03:
Wat raar dat Asus neits te melden heeft... Doorgaans zie ik nog altijd in de BIOS de optie om de IRQ's te wijzigen voor PCI slots en andere devices, er zijn er ook zat van.

Als het niet kan, kun je de kaart niet in een ander slot steken, of zijn er geen andere PCI slots over? Anders, kun je geen SATA controller voor PCI of PCIe scoren en zo de interne uitschakelen? Anders zou je wss idd een ander bord moeten halen. IRQ's kun je alleen in de BIOS wijzigen voor zover ik weet. 2 Interrupt Requests (IRQ)op 1 adres gaan inderdaad niet werken

Tsja ik was ook niet erg overtuigd van de kennis en kunde van de asus medewerker die ik te spreken kreeg en heb er achteraan ook nog even een extra mailtje gestuurd met dezelfde vraag. In de BIOS zitten een hoop opties wat betreft IRQ's, maar helaas weet ik daar niet genoeg vanaf om zomaar wat aan/uit te zetten etcetera. Indien gewenst kan ik wel even een aantal foto's van de bios maken (zou waarschijnlijk vrijdag middag worden) zodat jullie me misschien kunnen helpen het huidige bord toch zo ver te krijgen te doen wat ik wil.

Wat betreft het kopen van een ander board; dat zou geen probleem zijn, maar dan wil mijn chef wel zekerheid dat dat ding dit probleem wel met zekerheid oplost. En zowel mijn leverancier als Asus kon daar niks over zeggen (over het aan gedragen moederbord) dus je zou dit topic lichtelijk stiekem kunnen bombarderen tot verkapt "welk moederbord kan dit wel"-topic maar dat houden we geheim

Het is trouwens geen modem maar meer een voice kaart (waar 4 ISDN2 lijnen op kunnen), we gebruiken het om uitgaande en inkomende gesprekken die we niet over ons voip netwerk (aantal asterisk dozen bij klanten ed aan elkaar gekoppeld) over POTS te sturen. Wat er gebeurd ten tijde van een interrupt snap ik in grote lijnen. Aan de hand van de volgende output concludeerde Junghanns dat het kwam omdat de interrupts gedeeld werden:

root@voip01:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:   78764576   72963512   13844581          0    IO-APIC-edge  timer
  1:         94          0          0          0    IO-APIC-edge  i8042
  6:          3          0          0          0    IO-APIC-edge  floppy
  8:          0          0          0          0    IO-APIC-edge  rtc
  9:          1          0          0          0   IO-APIC-level  acpi
 58:    1042431    1727620      28051    1128640         PCI-MSI  eth1
169:          0          0          0          0   IO-APIC-level  libata
--> 177:  227276215  204783773   93359485  144695339   IO-APIC-level  ide0, qozap <--
233:    2984688    3860647     577441     574526         PCI-MSI  libata
NMI:          0          0          0          0
LOC:  161292292  166950601  171184863  168768545
ERR:          0
MIS:          0

[H!GHGuY]

Wat GENETX zegt klopt voor het grootste deel, maar hij vergeet nog even dat IRQ sharing wel degelijk goed mogelijk is. Als devices een IRQ sharen dan vraagt het OS aan elk toestel met die IRQ of er iets moet gebeuren. Toestellen die dit niet ondersteunen kunnen dus problemen geven. Bekende voorbeelden hiervan zijn oudere Creative geluidskaarten. Deze situatie heeft natuurlijk wel nadelen voor de performantie aangezien meerdere toestellen moeten aangesproken worden.

Ik weet niet of huidige moederborden dit nog in die zin hebben, maar vroeger waren er alleszins verschillende IRQ-lines die elk PCI slot op een ander IRQ mapten.

	PCI slot 1	PCI slot 2	PCI slot 3
IRQ A	10	11	12
IRQ B	13	11	10
IRQ C	12	10	13

Van een oude Asus moederbord wat ik had, stond dit beschreven in de manual.

Conclusie is dat je:
- de kaart in ander slot zal moeten stoppen tot deze geen interrupt lijn meer deelt.
- aan de slag kunt met IRQ settings en andere zut waar je als leek geheid problemen mee zal hebben.

[BarthezZ]

Ok, weer een gesprek met de Asus support verder (US in dit geval, NL had weinig zinnigs te zeggen omdat ze er gewoon niks van snapte) en een 15 euro zwaardere telefoon rekening.

Zij beweerden dat het OS er voor zorgde dat de interrupts gedeeld werden en dat het moederbord hier in geen enkele vorm iets aan kon doen. De settings in de bios zouden er ook niet voor kunnen zorgen dat de kaart een eigen IRQ zou krijgen zodat er geen sharing is.

@H!GHGuY: Opzich beschouw ik mijzelf absoluut niet als leek, maar ik moet eerlijk zijn dat ik wat betreft IRQ's en interrupts mijn kennis niet voldoende is verder. Ik zal vrijdagmiddag even verder kijken en verdiepen in wat de bios kan.

Tss Terw_Dan, mijn verstrooidheid hoeft niet publieke bekend gemaakt te worden

[ Voor 6% gewijzigd door BarthezZ op 11-03-2009 21:05 ]

[TERW_DAN]

Titelfixje want deze slaat eigenlijk nergens op
'Shared IRQ problemen met IRQ problemen' > 'Shared IRQ problemen met Junghanns ISDN kaart'

[GENETX]

BarthezZ schreef op woensdag 11 maart 2009 @ 20:16:
@H!GHGuY: Opzich beschouw ik mijzelf absoluut niet als leek, maar ik moet eerlijk zijn dat ik wat betreft IRQ's en interrupts mijn kennis niet voldoende is verder. Ik zal vrijdagmiddag even verder kijken en verdiepen in wat de bios kan.

Das ook niet vreemd hoor. Dat gaat nog dieper dan de kennis van de gemiddelde tweaker. Maar het komt ook doordat ik het wel heb gehad tijdens de studie

[ThaHandy]

dingen die je kunt doen:

om wat extra IRQ's te krijgen(just in case) kan je uit zetten in de bios:
com 1/2 poort (irq 4/3), de LPT poort (7) en meschien de onboard audio?
PNP OS in bios uit zetten zodat de bios(jij) IRQ's toewijst (kan puinhoop worden met booten??! anyone? (geen linux kenner)

ow enne @ google: geen idee of dit van toepassing is?

Just to let know the solution I have found.

typing dmesg one can see the kernel log.
In that I have seen that the HISAX module was loaded.
To remove it i have:
1. unloaded module hisax with rmmod hisax (it told me to remove first another specific driver which i suddenly rmmod-ed)
2. moved away the dir /lib/modules/<kernel version>/drivers/isdn/hisax
3. modprobed the right module i had

and all problems were gone.


Angyel

[ Voor 4% gewijzigd door ThaHandy op 11-03-2009 22:07 ]

[BarthezZ]

@ThaHandy ik heb even gekeken of er nutteloze modules geladen zijn en alles wat nutteloos unloaded, maar de genoemde module was niet aanwezig op mijn systeem.
Ik kwam ook nog een variabel in mijn kernel config tegen betreffende IRQ Sharing, vrijdag ga ik dat even uitzetten (remote met kernel prutsen zonder iLo/KVM-over-IP vind ik niet fijn om te doen) en dan ga ik de rest van de suggesties ook even proberen.

[mad_max234]

Windows doet toch ook een IRQ routing, of heeft dat niks te maken met het verdelen van IRQ's?

Nadat het systeem-BIOS broninstellingen heeft toegewezen en de PCI IRQ-routetabel heeft opgebouwd, wordt Windows geladen. Windows extraheert PCI- en ISA-Plug en Play-compatibele apparaatbrongegevens uit het systeem-BIOS en leest de gegevens van de PCI IRQ-routetabel. Windows kan dan de ISA IRQ's die zijn toegewezen aan een bepaald PCI INT-nummer, opnieuw toewijzen. Windows kan de IRQ's ook dynamisch opnieuw toewijzen als een Plug en Play-gebeurtenis optreedt, bijvoorbeeld het plaatsen van een laptopcomputer in het basisstation.

Ben hier niet zo in thuis, heb al jaren geen conflict meer gehad, was vroeger wel anders.

[BarthezZ]

Even een updateje:

Omdat ik de Flash kaart maar vervangen heb door een normaal s-ata diskje kon ik de IDE controller disablen. Hierdoor zit de Junghanns ISDN kaart op zijn eigen interrupt te spelen en is het probleem opgelost

Iets om bij toekomstige Asterisk dozen rekening mee te houden, een moederbord vinden wat een PCI slot zijn eigen IRQ kan geven (of iig, de IRQ's niet deelt met onboard apparaten) of maar eens kijken naar PCI-E hardware wat dan hopelijk niet hetzelfde probleem heeft.

[H!GHGuY]

Waarschijnlijk was dit probleem ook opgelost door het kaartje in een ander PCI slot te stoppen.

[BarthezZ]

Nopes H!GHGuY, zoals aangegeven in de TS had ik dat al geprobeerd.

BarthezZ schreef op woensdag 11 maart 2009 @ 17:54:
Helaas bleef het probleem en blijkt volgens cat /proc/interrupts er op allebei de beschikbare PCI sloten ook een ander apparaat te zitten (s-ata of ide controller). Ook het unloaden van de IDE drivers heeft niet het gewenste effect gehad en zelfs er voor gezorgd dat de kernel segfault (ging niet helemaal netjes)