[asterisk-users] PRI worked fine for months, now it stopps working after 2-3 hours

[Loic Didelot]

Here is some more information:

[ 2936.169191] wcte12xp0: Missed interrupt. Increasing latency to 6 ms
in order to compensate.
[ 4734.685566] wcte12xp0: Missed interrupt. Increasing latency to 7 ms
in order to compensate.
[ 4893.695402] zaptel Disabled echo canceller because of tone (rx) on
channel 56
[ 5248.845635] wcte12xp: NMF workaround on!
[ 5248.845640] wcte12xp: Setting yellow alarm
[ 5248.845658] Zaptel: Master changed to XBUS-00/XPD-00
[ 5248.845777] wcte12xp0: Missed interrupt. Increasing latency to 8 ms
in order to compensate.
[ 5248.910831] wcte12xp: NMF workaround off!
[ 5253.908078] Zaptel: Master changed to WCT1/0
[ 5253.964028] wcte12xp: Clearing yellow alarm
[ 5335.053981] wcte12xp0: Missed interrupt. Increasing latency to 9 ms
in order to compensate.

cat /proc/interrupts 
           CPU0       CPU1       
  0:         83          0   IO-APIC-edge      timer
  1:          2          0   IO-APIC-edge      i8042
  3:     100887          0   IO-APIC-edge      serial
  7:          0          0   IO-APIC-edge      parport0
  8:          3          0   IO-APIC-edge      rtc
  9:          1          0   IO-APIC-fasteoi   acpi
 16:    5381227          0   IO-APIC-fasteoi   uhci_hcd:usb3, wcte12xp0,
eth5
 17:     570760          0   IO-APIC-fasteoi   eth4
 18:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1,
uhci_hcd:usb7
 19:   20413905          0   IO-APIC-fasteoi   ehci_hcd:usb2,
uhci_hcd:usb5
 20:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 21:      33904          0   IO-APIC-fasteoi   uhci_hcd:usb6, libata,
libata
NMI:          0          0 
LOC:     604815     708592 
ERR:          0
MIS:          0


Loic




On Wed, 2009-08-26 at 10:34 +0300, Tzafrir Cohen wrote:
> On Wed, Aug 26, 2009 at 08:53:18AM +0200, Loic Didelot wrote:
> > Hello,
> > we have several customers with a PRI line and a Wildcard TE121.
> > Everything worked fine, but now are one customer the PRI stops working
> > after a few hours.
> > 
> > "zap show channel 1" shows that the channel is InAlarm. I the log files
> > of asterisk I see that the D-Channel seems down. Restarting asterisk
> > does not help, but rebooting the whole server resolves the problem for
> > another 2-3 hours.
> 
> The obvious stupid question: Does Zaptel (The kernel) report that the
> span is in alarm? 
> 
> cat /proc/zaptel/1
> 
-- 
Loïc DIDELOT
MIXvoip S.a.
Tel: +352 20 3333 20
Fax: +352 20 3333 90
ldidelot at mixvoip.com
http://www.mixvoip.com