<br>Thanks for the reply, Kevin.<br><br>> Well, many bugs have been fixed in DAHDI since 2.0.0-rc4, so I'd really<br>> suggest upgrading before spending much more time on this.<br><br>I will upgrade to the latest kernel and svn checkout of DAHDI and repeat the tests in the next few days.<br>
<br>><br>><br>> What buffer policy is your application using for the DAHDI channels,<br>> what size are you setting the buffers to, and how many buffers are you<br>> configuring?<br><br>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.<br>
<br>><br>> > About ELAST errors:<br>> ><br>> > What is the the intended semantic of the ELAST error on reads and writes<br>> > ? On a write, if the buffers are full/link is busy, isn't the driver<br>
> > supposed to block the write instead of returning an error immediately ?<br>><br>> Are you setting the channel file descriptor to non-blocking mode? If so,<br>> this is exactly what you should expect.<br>
<br>I am not setting O_NONBLOCK. But if I were, I would expect EAGAIN errors, not ELAST. <br><br>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":<br>
<br>(dahdi-base.c, rev. 5275, line 1914):<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">for (;;) {<br> spin_lock_irqsave(&chan->lock, flags);<br>
if (chan->eventinidx != chan->eventoutidx) {<br> spin_unlock_irqrestore(&chan->lock, flags);<br> return -ELAST /* - chan->eventbuf[chan->eventoutidx]*/;<br> }<br></blockquote><br><br>
The code in dahdi_chan_write is very similar.<br><br>-- Felipe Bergo<br>LABCOM Sistemas, Campinas, SP, Brazil<br><br><br>