Yes ! I have saw and analyzed those patches and there is nothing in those patches different from my described setup, and I'm pretty sure that this problem will arise with those patches sooner or later (and it will be masked and harder to figure out since there is no_l1_check option wich disables Chan D Up/Down messages on console).
I have browsed sources of zaphfc and qozap from bristuff and I have noticed something interesting which points me to a thought that there might not be a problem with LibPRI in this case, but in fact that telco goes out into IDLE mode and shuts down L1 and power on BRI after a while, and that sends RED alarm to DAHDI. That would explain why BRI span gets in order when new incoming call is generated for that BRI (telco goes out of IDLE mode and resumes talking to us). In any case this what I'll explain below is worth trying.
In qozap.c in function ZAP_IRQ_HANDLER(qoz_interrupt) around line 983 there is piece of code that handles TE mode HFC chip states:
// TE state machine
if (l1state == 3) {
qoztmp->st[st].l1up = 0;
if (qoztmp->st[st].t3 > -1) {
/* keep layer1 up, if the span is started. */
if (qoztmp->spans[st].flags & ZT_FLAG_RUNNING) {
if (debug > 2)
printk("qozap: re-activating layer1 span %d\n", st);
qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);
}
} else {
if (debug > 2)
printk("qozap: not re-activating layer1 span %d\n", st);
qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x40);
/* if we tried to activate layer 1 and it failed make this an alarm */
// qoztmp->spans[st].alarms = ZT_ALARM_RED;
// zt_alarm_notify(&qoztmp->spans[st]);
/* if the network shuts us down in idle mode dont make this an alarm */
}
As you can see this code is trying to bring L1 UP if it see that SPAN is configured and running and T3 timer is > -1 (with command qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60); ), and if T3 timer is -1 it doesn't (command qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x40); ),
BUT IN ANY CASE IT DOESN'T put SPAN in RED alarm (commented part of code).
Now, I believe that equivalent piece of code in wcb4xxp driver is this part of base.c :
In function hfc_handle_state(struct b4xxp_span *s) around line 1392 (in
https://issues.asterisk.org/view.php?id=13897
patched version of base.c)
switch(sta) {
default: /* Invalid TE state */
case 0x0: /* TE state F0: Reset */
case 0x2: /* TE state F2: Sensing */
case 0x3: /* TE state F3: Deactivated */
case 0x4: /* TE state F4: Awaiting Signal */
case 0x8: /* TE state F8: Lost Framing */
s->newalarm = DAHDI_ALARM_RED;
break;
case 0x5: /* TE state F5: Identifying Input */
case 0x6: /* TE state F6: Synchronized */
s->newalarm = DAHDI_ALARM_YELLOW;
break;
case 0x7: /* TE state F7: Activated */
s->hfc_timer_on[HFC_T3] = 0;
s->newalarm = 0;
break;
}
}
s->alarmtimer = b4->ticks + alarmdebounce;
s->oldstate = state;
if (DBG_ALARM) {
dev_info(b4->dev, "span %d: old alarm %d expires %ld, new alarm %d expires %ld\n",
s->port + 1, oldalarm, oldtimer, s->newalarm, s->alarmtimer);
}
/* we only care about T2 expiry in G4. */
if (nt && (sta == 4) && (state & V_T2_EXP)) {
if (s->hfc_timer_on[HFC_T2])
hfc_timer_expire(s, HFC_T2); /* handle T2 expiry */
}
/* If we're in F3 and receiving INFO0, start T3 and jump to F4 */
if (!nt && (sta == 3) && (state & V_INFO0)) {
s->hfc_timers[HFC_T3] = b4->ticks + timer_3_ms;
s->hfc_timer_on[HFC_T3] = 1;
if (DBG_ST) {
dev_info(b4->dev, "port %d: receiving INFO0 in state 3, setting T3 and jumping to F4\n", s->port + 1);
}
hfc_force_st_state(b4, s->port, 4, 1);
}
As you can see for all HFC states in (0,2,3,4 and
s->newalarm = DAHDI_ALARM_RED is set, and there is no try to keep L1 UP like in qozap.c with qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);
Incorporating something like: qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60); to a wcb4xxp driver is beyond my programming knowladge, but I think that it could be a good approach to this issues I explained, and if anyone there is willing to make a patch to a wcb4xxp driver with this changes i'm willing to test it and post results right away.
Kind regards,
Nenad Radosavljevic