[asterisk-users] debian/dahdi/zaphfc - Unable to receive TEI fromnetwork!

[Alex]

Tzafrir Cohen wrote:
> On Fri, Oct 01, 2010 at 01:49:48PM +0100, Andrew Thomas wrote:
>> What happens if you change to:
>>
>> signalling=bri_cpe_ptp
> 
> It's bri_cp , not bri_cpe_ptp .
> 

yes, bri_cpe, for p2p mode, that's what my last failure report was using
(the bri_cpe vs bri_cpe_ptmp inconsistency hurts a little, but lets keep
that for later). Note that I disconnected the phone that's sharing the
S0-bus with the HFC while doing this, for good measure.

Anyway, I understand this was just a test to help diagnose the problem
rather than a hint at a potential misconfiguration, as I'm pretty sure
my line is in p2mp mode; the ISDN phone happily shared the S0 with the
asterisk box for years.

To narrow down the source, I then put a "new" hdd (w/ squeeze on it) in
the "original" machine and put the HFC back in, in the slot it used to
be. Everything behaves exactly as reported in my initial mail, including
the warn_slowpath_common warning (I still don't know what to think of
it); this should discard machine/HFC incompatibility as the cause. The
interrupt is shared in this machine, but my etch/bristuff/ast1.2 was
happy about that, so that's not the point, unless this newer driver has
"enhanced" requirements.

However, the card is fine. To confirm this, I removed all dahdi stuff,
loaded debian stock hfcpci module and mISDN_dsp, built mISDNuser from
git and I can see incoming and outgoing call setups (from/to the phone
on the shared S0 bus) with misdn_log:

# tools/misdn_log
mISDN kernel version 1.01.21 found
mISDN user   version 1.01.21 found
1 controller found
        id:             0
        Dprotocols:     00000006
        Bprotocols:     0000006e
        protocol:       0
        channelmap:     00000000000000000000000000000006
        nrbchan:        2
        name:           hfc-pci.1
log bind ch(1) return -1
log bind error Invalid argument
log bind ch(0) return 0
0
[censored packets flow...]

# dmesg | grep --relevant
[    7.517932] hfcpci 0000:01:02.0: enabling device (0000 -> 0003)
[    7.517960] hfcpci 0000:01:02.0: PCI INT A -> Link[LNKB] -> GSI 9
(level, low) -> IRQ 9
[    7.517972] mISDN_hfcpci: found adapter CCD/Billion/Asuscom 2BD0 at
0000:01:02.0
[    7.517981] mISDN: HFC-PCI driver 2.0
[    7.518131] HFC-PCI: defined at mem 0xd8d66800 fifo
0xd73d8000(0x173d8000) IRQ 9 HZ 250
[    7.558468] HFC 1 cards installed
...
[   59.173173] DSP modul 2.0
[   59.173190] mISDN_dsp: DSP clocks every 64 samples. This equals 2
jiffies.
[   81.010222] base_sock_release(d748e340) sk=d6b9b600
[  106.181034] base_sock_release(d748e340) sk=d6b9b600
[  106.181093] connect_layer1: ret -22 (dev 0)
[  106.181192] init_card: entered
[  106.181222] reset_hfcpci: entered
[  106.181229] HFC_PCI: resetting HFC ChipId(30)
[  106.181241] HFC-PCI status(4) before reset
[  106.184031] HFC-PCI status(2) after reset
[  106.184031] HFC-PCI status(4) after 5us
[  106.184031] inithfcpci: entered
[  106.268053] HFC PCI: IRQ 9 count 33
[  106.268067] connect_layer1: ret 0 (dev 0)

subsequent launches of misdn_log will log this:
[ 1047.287483] base_sock_release(d7421a00) sk=d6b9ba00
[ 1047.287542] connect_layer1: ret -22 (dev 0)
[ 1047.287642] connect_layer1: ret 0 (dev 0)

I haven't yet configured misdn properly, but I can issue calls with
misdntestlayer3, so the card seems to behave well enough with misdn to
get a TEI and make a call.

I'm not that much thrilled by ISDN these days, I mostly want to get back
to a working setup. But since I've battled with this for a few days, if
a few more days are needed to help debug what appears to be a problem
with vzaphfc (?), I can spend some time. That is, if you care to provide
test scenarios and/or test/instrumented code. Tell me if this needs to
be moved off (this) list... jabber would be fine, if you say so.