[asterisk-bugs] [Asterisk 0014031]: [patch] "pri_find_dchan: No D-channels available!" error on console when using wcb4xxp
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Jun 29 04:45:03 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=14031
======================================================================
Reported By: sruffell
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14031
Category: Channels/chan_dahdi
Reproducibility: always
Severity: major
Priority: normal
Status: acknowledged
Asterisk Version: SVN
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 160386
Request Review:
======================================================================
Date Submitted: 2008-12-08 14:55 CST
Last Modified: 2009-06-29 04:45 CDT
======================================================================
Summary: [patch] "pri_find_dchan: No D-channels available!"
error on console when using wcb4xxp
Description:
When a wcb4xxp is connected as a BRI span in TE mode, you get errors like:
[Dec 2 22:02:48] WARNING[4759]: chan_dahdi.c:3008 pri_find_dchan: No
D-channels available! Using Primary channel 6 as D-channel anyway!
[Dec 2 22:02:49] WARNING[4758]: chan_dahdi.c:3008 pri_find_dchan: No
D-channels available! Using Primary channel 3 as D-channel anyway!
[Dec 2 22:03:19] WARNING[4759]: chan_dahdi.c:3008 pri_find_dchan: No
D-channels available! Using Primary channel 6 as D-channel anyway!
On your asterisk console and in your asterisk log.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0014617 HFC-s card cannot initiate outgoing calls
related to 0012757 [branch] when BRI span go down cannot m...
======================================================================
----------------------------------------------------------------------
(0107115) nenadr (reporter) - 2009-06-29 04:45
https://issues.asterisk.org/view.php?id=14031#c107115
----------------------------------------------------------------------
I have browsed sources of zaphfc and qozap from bristuff (they are handling
same HFC chip), this weekend, and I have noticed something interesting in
both drivers in "same piece of code" (nadling of HFC chip states), 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, I believe it 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 8) 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 issue, 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.
Issue History
Date Modified Username Field Change
======================================================================
2009-06-29 04:45 nenadr Note Added: 0107115
======================================================================
More information about the asterisk-bugs
mailing list