[asterisk-users] bristuff - qozap dirver bug (and fix?)

[Steve Davies]

Hi,
(cc. asterisk-users, hope that is not a big Faux Pas)

I've had trouble with the qozap driver for a LONG time now, where it
will not recognise and ignore a missing ISDN2 line on a quad card if
one of the 4 ports is unplugged or somehow faulty.

The symptom is that is correctly recognises the fault, but then clears
the RED ALARM almost immediately, leaving Asterisk thinking that it
can call using that line, and failing the call, instead of using one
of the other (working) lines in the same Zaptel group.

I /think/ I might have spotted the code in the driver which needs
changing to fix this, and it does seem to work after some very basic
testing, so I'd like as much opinion from the mailing list(s) as to
whether the fix is valid.

Diff (I hope gmail does not wrap it too much!):

--- qozap/qozap.c~      2007-08-13 13:25:38.000000000 +0100
+++ qozap/qozap.c       2007-08-13 13:10:18.000000000 +0100
@@ -827,7 +827,7 @@
                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)) {
+                   if ((qoztmp->st[s].t3 > -1) && (qoztmp->st[s].t4
== -1) && (qoztmp->st[s].layer1state == 3) && (qoztmp->st[s].nt_mode
!= 1)) {
                        /* clear alarms */
                        if (debug > 2)
                            printk(KERN_INFO "qozap: clearing alarms
on span %d\n",s);

Basically the change says to not clear the RED alarm until at least
the t3 timer has started (This is handled elsewhere if the line status
changes).

Comments welcome.

Cheers,
Steve