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

[Shaun Ruffell]

On Thu, Dec 08, 2011 at 06:41:46PM +0100, Olivier wrote:
> 2011/12/8, Shaun Ruffell <sruffell at digium.com>:
> > On Thu, Dec 08, 2011 at 09:26:14AM +0100, Olivier wrote:
> >
> >> 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.

The -1 in this context means that the card found no external sync
source and switched to use it's internal oscillator. 0-7 means that
it's recovering the clock from one of the BRI spans.

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

This is a good question. I do know how to see this explicitly
occuring other than the BRI spans just going into Red alarm. Perhaps
someone who knows more about BRI than I can chime in here.

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

Not that I'm aware of, but I could be mistaken.

> 3. Is this feature worked on ?

Again, not that I'm aware of.

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

That message would only have been printed in dahdi-linux 2.5.0.
Any revision greater than 2.5.0.1 will not print that message [1].

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10119

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

That is correct.

> 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) ?

That warning was only put in the kernel in 470c66239 [2] which was
first released in kernel 2.6.29. Probably your other systems are
based on distros using older kernel versions as the base.

[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=470c66239ef03364

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

Not recommended, but with the newer cards interrupt sharing is MUCH
less of a problem than it was originally. In fact, with Digium's
Voicebus cards I'm not aware of any problems that were resolved by
trying to ensure the interrupt is on it's own line. Most problems of
that nature are due to other drivers (disk in PIO, framebuffers,
serial consoles on slow links) taking too much time in interrupt
context.

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