Hello everyone,
I have a very strange issue with a TE205P, zaptel and chan_ss7 regarding
interrupts. As I think this is originated somehwere in the zaptel
driver, I crosspost this to -dev, hope that's OK.
As chan_ss7 need not d-channel, the configuration in /etc/zaptel.conf is
as follows:
bchan=1-31
bchan=32-62
That's the first difference to a config with zaptel, where dchannels
need to be configured.
I came across the issue, when I started to get a lot of CRC16 errors on
the MTP2 part of chan_ss7 resulting at last in a flapping of the
complete SS7 signaling every few minutes. Together with these CRC16
errors I got messages, that chan_ss7 ran into an "Excessive poll delay"
and that the Zaptel input buffer went full, directly followed by a empty
zaptel output buffer. What was/is strange is the fact, that I have two
machines configured the same, only differing in DPC and OPC codes in
chan_ss7 and different CPUs. The machine working without problems runs
with a AMD Duron with 1300 MHz, the one with the CRC-errors on a P4 with
3GHz.
My first step to find the source of the problem was to put the Card into
a different System, also running a P4, but this time only with 1.8GHz.
That resulted in the same errors, the SS7 part wouldn't even start with
that one.
So I started to dig deeper. I made a crosslink cable and connected two
E1 ports with it, started two instances of asterisk with chan_ss7 and
experienced the problem (that proved at last, that there was no problem
with the Switch from the TelCo). So my next step was to start the two
instances with chan_zap instead of chan_ss7 and everything is fine. No
erros in any way.
As I knew, that the Card in my other system with an AMD worked, I now
changed Hardware again, this time putting the card in AMD Athlon XP
3000+, crosslinked the two E1s again and started two instances of
asterisk running chan_ss7. And voila, no problem. At least at first it
looked this way. I let it run over night (only asterisk is running, no
traffic or whatsoever may distract the system) and when I came back this
morning, I had CRC errors + the other error messages on the screen. So
now I suspected the card (which I still do for a bit). To test, if the
TE205P works as it should, I made a crossover plug (Pin 1-4 and 2-5) and
ran a patlooptest, a loop test with zttool, a zttest and also
uncommented #define CONFIG_ZAPTEL_WATCHDOG in zconfig.h. All looks fine,
no errors whatsoever. The card is assigned an interrupt for itself
without anything else using it. All looked good.
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.
As you can see, I am stuck now, why does this happen and why only with
chan_ss7? I cannot say if I can reproduce the errors on my "running
system" (the one without the errors) as it is located elswhere without a
keyboard connected. Any ideas how to solve this are greatly appreciated,
as I need to get the system back to work.
Best regards,
Kai
--
Kai Militzer WESTEND GmbH | Internet-Business-Provider
Technik CISCO Systems Partner - Authorized Reseller
L?tticher Stra?e 10 Tel 0241/701333-14
km@xxxxxxxxxxx D-52064 Aachen Fax 0241/911879
|