[asterisk-ss7] Strange interrupt issue with zaptel and chan_ss7

[P.B.]

The card does not behave any different if all channels are idle or if 
all channels are used - In fact the card can not even tell the 
difference. The driver reads and writes audio samples on free and on 
used channels no matter what. The difference between no calls and 24 
simultaneous calls is the processor load of the system. With the 
processor load also interrupt latency increases - not linearly though. 
So depending on the cards buffer, if the card is not being serviced in 
time, frame slips occur and audio and/or hdlc frames are lost.
If another interrupt is being handled (keyboard, harddisk, ethernet) it 
will be serviced and will further increase interrupt latency, sometimes 
to the point where a buffer overrun (slip) occurs.

The strange behavior between P4 and AMD could be because of slightly 
different bus timings on the PCI bus and a faulty card which barely made 
the pci specs.

m.f.G.
Peter

Kai Militzer wrote:
> Hello everyone,
>
> I solved my problem, so I tought I give you an update.
>
>> Then finaly I came across the behavior that puzzles me. Asterisk was 
>> running with two instances over the crosslink and the console screen 
>> was blanked on the console. So I wanted to press Shift to unblank it, 
>> but accidently pressed the CapsLock key. When the screen was 
>> unblanked and I  started to type, I realized, that CapLock was on. I 
>> pressed it again and in this moment, I got a CRC16 error. I thought 
>> that was strange and pressed it again twice, and there it was again, 
>> Packets from the zaptel driver to chan_ss7 got lost. The same 
>> behavior happens, when I press ScollLock or NumLock. The Keyboard 
>> runs on interrupt 1 and the TE205P on IRQ11, so there shouldn't be 
>> any impact when the keyboard uses this interrupt.
>
> I got the card interchanged with a new one from my distributor. With 
> the new card, the problem does not exsists. So the reason for the 
> strange behavior was a faulty hardware. That's OK, things like that 
> can happen, but what I cannot understand is, that the tests shipped 
> with the zaptel source did not detect it.
>
> If I understand correctly patlooptest should reveal problems with bad 
> cards, but it went through without problems on my faulty card. I think 
> the problem is, that the error I had only surfaced, when a channel in 
> the span was completely used (i.e. the complete bandwith of 64kbit is 
> used by the signaling channel for SS7). I think that patlooptest does 
> not use the full bandwith of a channel and therefore does not detect 
> the error and it tests only one (the first) channel of a span. As I am 
> not a developer and my C knowledge tends to zero, I am not sure, if my 
> claim is right. But if it is, zaptel IMHO needs a test, that uses the 
> full bandwith of more than one channel to detect faulty cards.
>
>
> Best regards,
> Kai
>