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

[Olivier]

2011/12/8, Shaun Ruffell <sruffell at digium.com>:
> 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)
OK
>
>> 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.

OK this matches with the fact my /var/log/kern.log file is cluttered
(say 25 lines per hour) with lines like this:
wctdm24xxp 0000:04:06.0: xhfc_set_sync_src - modpos 0: setting sync to
be port -1

I specifically chose this line as this "setting sync to be port -1"
frightens me a bit as I would rather see a value ranging form 0 to 3
or 1 to 4.


 On
> BRI links this can happen in countries where the provider tries to
> take down layer 1 on idling spans.

1. How can I check this is happening ? Is "pri debug", for instance,
capable enough to confirm this ?
2. On a more general plan, is taking down layer 1 on idling spans
something PBXs are negociating with each other (the public switch
trying to take the layer one down, listening to an acknowledge from
the private PBX) or is it more brutal than that ?
3. Is this feature worked on ?

> 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.
Do you mean dahdi 2.6 ?

>  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.

So, is it correct that :
A it doesn't necessary imply the IRQ is shared, in this specific case,
B that  just means "the driver is asking for something the kernel do
not provide anymore".

Then, why can't I read this "warning line" in every system ?
Could this come from the way dahdi is configured (sometimes, dahdi is
configured in a way that makes it ask for interrupts locks, and
sometimes not) ?


 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

but still not recommended ?



 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>


Thank you very much for your detailed answers.