<br>Hi,<br><br>We are having what seems to be a weird issue with DAHDI. We are using Digium boards and DAHDI to monitor and generate signalling of some protocols (ISUP and ISDN) on E1 lines, without the higher level Asterisk application.<br>
<br>Using a D-channel configured as HDLCFCS for sparse ISDN signalling works without problems.<br><br>When we tried to use a D-channel (configured as either HDLCFCS or HARDHDLC) and mtp2 (but without DAHDI's mtp2 mode -- in our application we need to count FISU and LSSU message repetitions), we got a huge flow of EVENT_ABORT and EVENT_BADFCS, not to mention several ELAST errors on read() and write() calls -- even though we are trying to deplete the event buffer with a loop of DAHDI_GETEVENT before reads and writes. ISUP signalling suffers badly in these conditions. And HARDHLDC gives many more errors than HDLCFCS.<br>
<br>To check whether the link was reliable, I wrote a simple application to test a repeat pattern of 160 bytes (00 .. 9F) over a clear (audio) channel. Link to the source:<br><br><a href="http://pastebin.com/f40704fc1" target="_blank">http://pastebin.com/f40704fc1</a><br>
<br>The setup is a TE205P board on a x86_64 (core2 duo, lots of RAM) running CentOS 5.2 and DAHDI 2.0.0rc4 (the latest non-SVN at the time we started testing). The 2 E1 ports of the 205P are attached with a 1-foot crossover cable. We already tried switching cables -- it's not the cable. <br>
<br>When the system is idle, we get loss of one or a handful of bytes occasionally. (in the application above, an error rate of 0.3 to 1.0 errors/second).<br>Whenever there is any disk activity ("/bin/yes > /tmp/file.txt" and hit Ctrl+C after a few seconds), the received pattern is full of errors (> 20 errors/second)<br>
<br>Can anyone point the reason for this behavior ? Is there any obvious mistake in the pattern testing code ? Isn't the board supposed to receive and buffer all E1 frames regardless of interrupt activity on the PC bus ?<br>
<br>Also related: I have tried changing noburst=1 and noburst=0 in the wct4xxp module options (,/etc/modprobe.d/dahdi) but dmesg always shows the driver coming up in burst mode:<br><br>Nov 12 11:40:44 labcom52 kernel: Found TE2XXP at base address fdeff000, remapped to ffffc20000064000<br>
Nov 12 11:40:44 labcom52 kernel: TE2XXP version c01a016a, burst ON<br>Nov 12 11:40:44 labcom52 kernel: Octasic optimized!<br>(...)<br>Nov 12 11:40:44 labcom52 kernel: Found a Wildcard: Wildcard TE205P (4th Gen)<br><br>Is there any reason for the driver to refuse non-burst mode on this board ?<br>
<br>About ELAST errors:<br><br>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 ?<br>
<br><br>Thanks in advance,<br><br>-- Felipe Bergo<br>LABCOM Sistemas, Campinas, SP, Brazil<br><br><br>