Well, while we're all submitting patches for bristuff, here is one for
the qozap kernel driver. We had an occasional issue where Quad BRI
cards would oscillate between RED alarm and alarm cleared, when there
was no cable connected, so it should have been staying in RED alarm
state and never clearing.
I am not sure why it does not happen more often. Basically this patch
updates the qozap behaviour so that if the card is in F3 or F4 state
(Deactivated, or awaiting SYNC) it does not clear the RED alarm.
Steve.
--- ./qozap/qozap.c~ 2008-01-14 03:19:01.000000000 +0000
+++ ./qozap/qozap.c 2008-01-14 03:11:58.000000000 +0000
@@ -827,10 +827,12 @@
if (qoztmp->spans[s].alarms != ZT_ALARM_RED) {
qoz_dfifo_tx(qoztmp, s);
} else {
- if ((qoztmp->st[s].t3 == -1) && (qoztmp->st[s].t4
== -1) && (qoztmp->st[s].layer1state == 3) && (qoztmp->st[s].nt_mode
!= 1)) {
+// F3 == Deactivated, so don't clear an alarm
+// F4 == Awaiting Sync, so don't clear an alarm either!!!
+ if ((qoztmp->st[s].t3 > -1) && (qoztmp->st[s].t4 >
-1) && (qoztmp->st[s].layer1state > 4) && (qoztmp->st[s].nt_mode !=
1)) {
/* clear alarms */
if (debug > 2)
- printk(KERN_INFO "qozap: clearing alarms
on span %d\n",s);
+ printk(KERN_INFO "qozap: clearing alarms
on span %d\n",s+1);
qoztmp->spans[s].alarms = ZT_ALARM_NONE;
zt_alarm_notify_no_master_change(&qoztmp->spans[s]);
}
_______________________________________________
Bristuff-users mailing list
[email protected]
http://lists.three-dimensional.net/mailman/listinfo/bristuff-users
