# How to get DAHDI working with kernel 4.19

## Fog_Watch

UPDATE

Following on:

```
# uname -r

4.19.57-gentoo
```

```
cd /tmp

wget https://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-3.0.0-rc1+3.0.0-rc1.tar.gz

tar -xf dahdi-linux-complete-3.0.0-rc1+3.0.0-rc1.tar.gz

cd dahdi-linux-complete-3.0.0-rc1+3.0.0-rc1/linux/

mkdir drivers/staging

cp -fR /usr/src/linux/drivers/misc/echo drivers/staging

sed -i "s|#obj-m += dahdi_echocan_oslec.o|obj-m += dahdi_echocan_oslec.o|" drivers/dahdi/Kbuild 

sed -i "s|#obj-m += ../staging/echo/|obj-m += ../staging/echo/|" drivers/dahdi/Kbuild

echo 'obj-m += echo.o' > drivers/staging/echo/Kbuild

```

I could not build 3.1.

drivers/dahdi/wctdm.c was missing, which was needed for my TDM400P.

So I downloaded the old version:

```
cd /tmp

wget https://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1.tar.gz

tar -xf dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1.tar.gz

cp dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1/linux/drivers/dahdi/wctdm.c dahdi-linux-complete-3.0.0-rc1+3.0.0-rc1/linux/drivers/dahdi/
```

And added in the required lines:

```
# grep DAHDI_WCTDM dahdi-linux-complete-3.0.0-rc1+3.0.0-rc1/linux/drivers/dahdi/{Kconfig,Kbuild}

Kconfig:config DAHDI_WCTDM

Kconfig:config DAHDI_WCTDM24XXP

Kbuild:obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_WCTDM)   += wctdm.o

Kbuild:obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_WCTDM24XXP)   += wctdm24xxp/

```

I could then 

```
cd /tmp/dahdi-linux-complete-3.0.0-rc1+3.0.0-rc1/linux

make 

make install

reboot
```

```
# lsmod | grep -E 'oslec|dahdi'

dahdi_echocan_oslec    16384  2

echo                   16384  1 dahdi_echocan_oslec

dahdi                 221184  4 wctdm,dahdi_echocan_oslec

crc_ccitt              16384  1 dahdi

```

Last edited by Fog_Watch on Fri Nov 29, 2019 5:19 am; edited 1 time in total

----------

## jcandle

I'm going to res this old thread only because somebody will find this useful and there's no other place on the webs that I could find anyone posting this.

To make wctdm working with DAHDI 3.1.0 the following changes need to be made in addition to the changes posted by @Fog_Watch

file: wctdm.c

line: 1135

< DAHDI_IRQ_HANDLER(wctdm_interrupt)

> static irqreturn_t wctdm_interrupt(int irq, void *dev_id)

line: 2853

< 	res = dahdi_pci_module(&wctdm_driver);

> 	res = pci_register_driver(&wctdm_driver);

----------

## Fog_Watch

```
 # uname -r

4.19.82-gentoo

```

```
cd /tmp/

wget https://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-3.1.0+3.1.0.tar.gz

tar -xf dahdi-linux-complete-3.1.0+3.1.0.tar.gz 

cd dahdi-linux-complete-3.1.0+3.1.0/linux

mkdir drivers/staging

cp -fR /usr/src/linux/drivers/misc/echo drivers/staging

sed -i "s|#obj-m += dahdi_echocan_oslec.o|obj-m += dahdi_echocan_oslec.o|" drivers/dahdi/Kbuild

sed -i "s|#obj-m += ../staging/echo/|obj-m += ../staging/echo/|" drivers/dahdi/Kbuild

echo 'obj-m += echo.o' > drivers/staging/echo/Kbuild 

```

Include wctdm.c:

```
cd /tmp 

wget https://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1.tar.gz

tar -xf dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1.tar.gz

cp dahdi-linux-complete-2.11.1-rc1+2.11.1-rc1/linux/drivers/dahdi/wctdm.c dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/

```

```
# grep DAHDI_WCTDM dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/{Kconfig,Kbuild}

dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/Kconfig:config DAHDI_WCTDM

dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/Kconfig:config DAHDI_WCTDM24XXP

dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/Kbuild:obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_WCTDM) += wctdm.o

dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/Kbuild:obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_WCTDM24XXP) += wctdm24xxp/

```

Edit wctdm.c:

```
cd dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/

# sed -n -e 1135p -e 2852p wctdm.c

static irqreturn_t wctdm_interrupt(int irq, void *dev_id) 

   res = pci_register_driver(&wctdm_driver);

```

Build:

```
cd /tmp/dahdi-linux-complete-3.1.0+3.1.0/linux/

make

make install

reboot

```

```
hostname ~ # asterisk -rx "dahdi show version"

DAHDI Version: 3.1.0 Echo Canceller: OSLEC

```

----------

## ajorians

This all helped me!  I am OpenSuse and hit the issues where the TDM400P is no longer supported with DAHDI 3.  So I made the changes you all supplied, built and installed the drivers and all worked.  So thanks again.

----------

## Fog_Watch

The above works for 5.4. In addition the following change is needed.

file: tmp/dahdi-linux-complete-3.1.0+3.1.0/linux/include/dahdi/kernel.h

line: 62

< #include <linux/pci-aspm.h>

> #include <linux/pci.h>

```
# uname -r

5.4.38-gentoo

```

```
# asterisk -rx "dahdi show version" 

DAHDI Version: 3.1.0 Echo Canceller: OSLEC

```

----------

## Hyper_Eye

I modified the current stable net-misc/dahdi ebuild to restore the legacy modules wcfxo and wctdm. You can find the ebuild here: https://github.com/HyperEye/dahdi_legacy

----------

## Fog_Watch

This works with 5.4.97. With kernel 5.10.27 the ebuild ends in error 2. Ahh.

----------

## kalgonite

 *Fog_Watch wrote:*   

> This works with 5.4.97. With kernel 5.10.27 the ebuild ends in error 2. Ahh.

 

Same frustrating problem here on 5.10. 

Not really being into kernel headers and such, the only thing I could find is that a specific function, file_operations, seems to have been replaced by proc_ops: https://lore.kernel.org/linux-fsdevel/20191225172228.GA13378@avx2/

I've tried making changes accordingly on dahdi-base.c, but it really requires some more expertise to get something working out of it..

----------

## Hu

The pastebin link from Fog_Watch has long since expired, and no one quoted the error messages it contained.  Without those errors, anyone who wants to help you would first need to set up an environment to reproduce those errors.

----------

## kalgonite

 *Hu wrote:*   

> The pastebin link from Fog_Watch has long since expired, and no one quoted the error messages it contained.  Without those errors, anyone who wants to help you would first need to set up an environment to reproduce those errors.

 

I believe that the error isn't related specifically to gentoo's ebuild system, it depends on a kernel function change, to which I'm desperately trying to find a solution.   :Shocked: 

The same error is reproducible on different distros using the vanilla make procedure.

----------

## Hu

There may be people who could tell you how to fix it, but who have no interest in setting up to build DAHDI just to find out how it is broken.  If you post the errors you get, someone might be able to tell you what to do.  As is, all we know is that if we set up to build DAHDI, we will (probably) get the errors you saw.

----------

## Fog_Watch

After 15 years of sterling service my OpenVox A400P11 has gone to meet its maker. So unfortunately this thread is no longer relevant to me.

With respect to pastebin links though, Hu, I hear you.Last edited by Fog_Watch on Sat Aug 28, 2021 4:35 am; edited 1 time in total

----------

## Hu

 *Fog_Watch wrote:*   

> After 15 years of sterling service my OpenVox A400P11 has gone to meet its maker.

 Securing an RMA after 15 years is impressive.  Few things enjoy such a long warranty.  :Wink:  *Fog_Watch wrote:*   

> With respect to pastebin links though, Hu, I hear you.

 To be clear, I was trying to encourage kalgonite to provide the errors seen on a modern kernel.  I don't mind that your last paste is long gone, since we currently don't even know if your errors are the same as the ones kalgonite is encountering.

----------

## Hyper_Eye

 *Fog_Watch wrote:*   

> This works with 5.4.97. With kernel 5.10.27 the ebuild ends in error 2. Ahh.

 

 *kalgonite wrote:*   

> Same frustrating problem here on 5.10. 
> 
> Not really being into kernel headers and such, the only thing I could find is that a specific function, file_operations, seems to have been replaced by proc_ops: https://lore.kernel.org/linux-fsdevel/20191225172228.GA13378@avx2/
> 
> I've tried making changes accordingly on dahdi-base.c, but it really requires some more expertise to get something working out of it..

 

I updated my overlay with dahdi-3.1.0-r3.ebuild. I did not have to change the patch for the legacy modules. This is building without error for me with kernel 5.10.52. https://github.com/HyperEye/dahdi_legacy

Enable it with eselect-repository:

eselect repository add dahdi_legacy git https://github.com/HyperEye/dahdi_legacy

emerge --sync

emerge -av net-misc/dahdi::dahdi_legacy

----------

## kalgonite

 *Hyper_Eye wrote:*   

> 
> 
> I updated my overlay with dahdi-3.1.0-r3.ebuild. I did not have to change the patch for the legacy modules. This is building without error for me with kernel 5.10.52. https://github.com/HyperEye/dahdi_legacy
> 
> Enable it with eselect-repository:
> ...

 

Using the last patchset I could successfully compile and finally resume my TDM400P card (using the obsoleted wctdm driver). 

The error 2  I encountered during dahdi_tools compilation was the following:

```

make[3]: Entering directory '/usr/src/dahdi-tools-3.1.0/xpp'

  CCLD     astribank_tool

/usr/bin/ld: ./.libs/libastribank.a(libxtalk_la-xtalk_sync.o):/usr/src/dahdi-tools-3.1.0/xpp/xtalk/xtalk_sync.c:63: multiple definition of `members'; ./.libs/libastribank.a(libastribank_la-mpptalk.o):/usr/src/dahdi-tools-3.1.0/xpp/mpptalk.c:240: first defined here

```

I had to add the following rule on debian to compile dahdi_tools: 

```
export DEB_LDFLAGS_MAINT_APPEND="-Wl,--allow-multiple-definition"
```

I suppose this could work on gentoo, if needed: 

```
append-ldflags -Wl,--allow-multiple-definition
```

Thanks again and have a nice day!

----------

## Hu

While that will allow the compile to succeed, multiple definitions are an error by default for good reason.  In this case, are both definitions equivalent in their size, content, and const-ness?  Does either file assume it is the sole user of that symbol?  If not, the resulting code may misbehave at runtime.

----------

## kalgonite

 *Hu wrote:*   

> While that will allow the compile to succeed, multiple definitions are an error by default for good reason.  In this case, are both definitions equivalent in their size, content, and const-ness?  Does either file assume it is the sole user of that symbol?  If not, the resulting code may misbehave at runtime.

 

You are right in pointing this out, Hu.

The portion of code seems to concern a specific tool to control a subset of USB VoIP devices, called Astribank, produced by Xorcom. 

This is what I could quickly find about:

 *Quote:*   

> astribank_tool is a tool to control the USB-level functionality of an Astribank.
> 
> https://www.xorcom.com/usb-voip-gateway/

 

I think it's reasonable to believe that possible exceptions with this compilation (as in the variable duplication/scope error ignored with the additional flag posted in my last message) could appear when executing that specific tool, so my layman's conclusion would be against suggesting its use when having a USB device requiring astribank_tool to drive it.

Unfortunately I can't go further than this without real world testing or having additional knowledge about the toolset's source and dahdi's common interfaces.   :Sad: 

Ensuring there aren't additional passed exceptions behind the next corner would get me into a fix, so to speak.

----------

