[asterisk-users] Issues with dahdi show status output (and check IRQs)

[Shaun Ruffell]

On Thu, Dec 08, 2011 at 09:26:14AM +0100, Olivier wrote:
> Hi,
> 
> On a (bogus) system equiped with a Digium HA8 and 8 BRI ports, I'm reading this:
> # asterisk -rx "dahdi show status"
> Description   Alarms  IRQ    bpviol CRC4  Fra Codi Options  LBO
> HA8-0000      RED     109    0      0     CCS AMI  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      UNCONFI 109    0      0     CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      RED     109    0      0     CCS AMI  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      RED     109    0      0     CCS AMI  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      RED     109    0      0     CCS AMI  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      RED     109    0      0     CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      RED     109    0      0     CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
> HA8-0000      RED     109    0      0     CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
> 
> (In this case, ports 2, 6, 7 and 8 are unconfigured).
> When I'm reading this output, I often can see a different IRQ value.
> 
> 
> On another (functional) system, with an HA8 and 4 BRI ports, I can
> read an IRQ value which is constant.  But the displayed value is
> both different from the one I can read with lpsci -v and lspci
> -bv.
> 
> 1. Where does this IRQ value from "dahdi show status" come from ?
> How can I check this value with linux tools such as lspci ?

The number displayed in the IRQ field is actually the "IRQ misses",
or a count of frames where what was expected from the card didn't
match up with what was actually received. This value should be the
same as what you would see at the top of /proc/dahdi/<span> (when
it's greater than 0)

> 2. Is it normal to see this IRQ changing from time to time ?

Normally, after things have stabilized, it should remain constant on
any of the newer cards that can adjust to system latency.

On the Hx8 cards however, there are conditions where it will
increase regularly if the card is looking for a new sync source. On
BRI links this can happen in countries where the provider tries to
take down layer 1 on idling spans. When the card internally switches
it's timing source it will drop an in flight packet, and the IRQ
miss will bump.

> 3. From "dmesg | grep IRQ" output:
> [   13.565786] wctdm24xxp 0000:04:06.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [   13.565823] IRQ 20/wctdm24xxp0: IRQF_DISABLED is not guaranteed on shared IRQs
> 
> What does the last line mean ?
> I read it as implying my "Digium HA8 board is sharing the IRQ 20"
> but cat /proc/interrupts and lspci -v do not confirm this.

You would no longer see that message with the current release of
DAHDI. It's an indication that the driver requested the kernel keep
interrupts locked while running it's interrupt handler but the
kernel doesn't guarantee that anymore. The current release of the
wctdm24xxp driver in DAHDI does not request the kernel keep
interrupts locked anymore.

In this context shared IRQ means that it's technically possible for
the card to share it's interrupt line, which is common for PCI
devices.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org