[asterisk-dev] Link reliability issues on DAHDI

[Felipe Bergo]

Thanks for the reply, Kevin.

> Well, many bugs have been fixed in DAHDI since 2.0.0-rc4, so I'd really
> suggest upgrading before spending much more time on this.

I will upgrade to the latest kernel and svn checkout of DAHDI and repeat the
tests in the next few days.

>
>
> What buffer policy is your application using for the DAHDI channels,
> what size are you setting the buffers to, and how many buffers are you
> configuring?

Both TX and RX policies immediate, 32 buffers of 512 bytes each (just like
the hdlcstress.c sample application provided on dahdi-tools). I have tried
16x1024 and 8x2048 with no noticeable difference.

>
> > About ELAST errors:
> >
> > What is the the intended semantic of the ELAST error on reads and writes
> > ? On a write, if the buffers are full/link is busy, isn't the driver
> > supposed to block the write instead of returning an error immediately ?
>
> Are you setting the channel file descriptor to non-blocking mode? If so,
> this is exactly what you should expect.

I am not setting O_NONBLOCK. But if I were, I would expect EAGAIN errors,
not ELAST.

Looking at the kernel module source, reads and writes return ELAST when
(chan->eventinidx != chan->eventoutidx), which I interpret as "the event
queue is not empty":

(dahdi-base.c, rev. 5275, line 1914):

for (;;) {
>    spin_lock_irqsave(&chan->lock, flags);
>    if (chan->eventinidx != chan->eventoutidx) {
>       spin_unlock_irqrestore(&chan->lock, flags);
>       return -ELAST /* - chan->eventbuf[chan->eventoutidx]*/;
>    }
>


The code in dahdi_chan_write is very similar.

-- Felipe Bergo
LABCOM Sistemas, Campinas, SP, Brazil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20081113/70f0449e/attachment.htm