[Home]

Summary:DAHLIN-00368: DAHDI fails to build against kernel 5.0
Reporter:Shaun Ruffell (sruffell)Labels:
Date Opened:2019-03-07 08:43:22.000-0600Date Closed:2019-05-31 08:26:09
Priority:MajorRegression?
Status:Closed/CompleteComponents:dahdi (the module)
Versions:3.0.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Linux kernel 5.0 has changed the timekeeping interfaces to fix the 2038 problem.

I believe the drivers should be standardized on ktime for internal time, but before making any changes to the app drivers, I was looking for some early feedback on the proposed approach.

The work is currently at http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=shortlog;h=refs/heads/for-5.0 if anyone has any comments.
Comments:By: Anthony Messina (amessina) 2019-03-25 08:44:47.671-0500

Shaun, since you're working on this. Building with your for-5.0 branch on Fedora 29:

{noformat}
 CC [M]  /builddir/build/BUILD/dahdi-linux-kmod-3.0.0/_kmod_build_5.0.3-200.fc29.x86_64/drivers/dahdi/xpp/xbus-core.o
BUILDSTDERR: /builddir/build/BUILD/dahdi-linux-kmod-3.0.0/_kmod_build_5.0.3-200.fc29.x86_64/drivers/dahdi/xpp/xbus-core.c: In function 'xframe_init':
BUILDSTDERR: /builddir/build/BUILD/dahdi-linux-kmod-3.0.0/_kmod_build_5.0.3-200.fc29.x86_64/drivers/dahdi/xpp/xbus-core.c:262:2: error: implicit declaration of function 'do_gettimeofday'; did you mean 'do_settimeofday64'? [-Werror=implicit-function-declaration]
BUILDSTDERR:   do_gettimeofday(&xframe->tv_created);
BUILDSTDERR:   ^~~~~~~~~~~~~~~
BUILDSTDERR:   do_settimeofday64
BUILDSTDERR: cc1: some warnings being treated as errors
BUILDSTDERR: make[3]: *** [scripts/Makefile.build:277: /builddir/build/BUILD/dahdi-linux-kmod-3.0.0/_kmod_build_5.0.3-200.fc29.x86_64/drivers/dahdi/xpp/xbus-core.o] Error 1
BUILDSTDERR: make[2]: *** [scripts/Makefile.build:492: /builddir/build/BUILD/dahdi-linux-kmod-3.0.0/_kmod_build_5.0.3-200.fc29.x86_64/drivers/dahdi/xpp] Error 2
BUILDSTDERR: make[2]: *** Waiting for unfinished jobs....
{noformat}
By: Shaun Ruffell (sruffell) 2019-03-25 09:43:28.083-0500

Hi Anthony,

I just pushed a change that comments out the xpp drivers for the time being. I didn't want to put the time into changing them without hearing from one of their maintainers that the general approach was acceptable.  If you pull this [1] change you should be able to build at least.

I did make sure I could build against the Fedora 29 kernel (in a docker container) but I've not loaded any drivers in the kernel.

[1] http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=commitdiff;h=aa05a446becc45396abf68c95901280410756578
By: Anthony Messina (amessina) 2019-03-26 10:16:21.957-0500

Thanks Shaun.  Unfortunately (for me), t's the XPP drivers I use :(

Does Tzafrir still work on those?
By: Shaun Ruffell (sruffell) 2019-03-26 12:03:26.974-0500

I do not think so, but I know he has still posted something to this JIRA instance. I'll try assigning this to him and see if he comments.
By: Shaun Ruffell (sruffell) 2019-03-26 12:04:50.352-0500

If we don't hear back (and since you have xpp hardware) I can always make the change for you to test.
By: Anthony Messina (amessina) 2019-03-27 17:11:06.739-0500

Thank you Shaun. I'm happy to try it out.

BTW, is this DAHDI stuff dying out here? There have been a number of "fail to build with current kernel" bugs reported since the 4.x kernel line and the only release was 3.0.0, which stripped out a ton of hardware for the small time folks out there.  I guess that's not really part of this issue, but I'm just trying to think ahead for example if I won't be able to support my setup in the future as I need recent kernels for other fixes and features unrelated to Asterisk/DAHDI.
By: Shaun Ruffell (sruffell) 2019-03-28 05:47:36.485-0500

Anthony, OK, it probably will not be until this weekend that I'll be able to make any changes for you.

As far as DAHDI dying out here, I cannot comment since I no longer work for Digium. I'm pretty sure that drivers for unsupported hardware were removed because there is not anyone with that hardware who has stepped up to maintain it and Digium/Sangoma did not want to spend any time/money supporting hardware that is no longer within support windows.

Although, as someone who purchased a TDM400 many moons ago, I do commiserate with you. I dislike it when users are forced to freeze their configurations, but I do understand how it happens.
By: Shaun Ruffell (sruffell) 2019-03-28 22:21:23.762-0500

Anthony, I've updated the xpp drivers and compile tested them against 2.6.32-754.11.1.el6.x86_64, 3.10.0-957.10.1.el7.x86_64, linux-headers-4.15.0-46-generic (Ubuntu 18.04.2), and 5.0.3-200.fc29.x86_64.

I've no way to really test them, so hopefully they will not crash your system. Again, I do feel a little off playing around with the xpp timekeeping functions since there is a warning about how sensitive it is to the time, but alas...

The changes were pushed onto the http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=shortlog;h=refs/heads/for-5.0 branch.
By: Anthony Messina (amessina) 2019-03-30 07:51:25.853-0500

Shaun, I've successfully built signed kernel modules here https://messinet.com/koji/buildinfo?buildID=3822 using your latest changes from http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=shortlog;h=refs/heads/for-5.0

Quick smoke testing seems to indicate no problems at all with the XPP modules!  Thank you!
By: Shaun Ruffell (sruffell) 2019-03-31 20:59:04.721-0500

Thanks for testing it.  I've fixed a few minor check patch errors and it the branch should be good for [~kmorgan] to smoke check and then possibly issue a release.

Someone should be able to pull this into a branch based on master like:
{{git pull git://git.asterisk.org/team/sruffell/dahdi-linux for-5.0}}

By: Keith Morgan (kmorgan) 2019-04-01 08:56:14.627-0500

We will add smoke testing and a release to our list of things to do.
By: Alex Regan (gossamer) 2019-04-26 08:30:17.015-0500

This still fails on my fedora29 5.0.9 system

root@orion dahdi-for-5.0]# uname -a
Linux orion.inside.guardiandigital.com 5.0.9-200.fc29.x86_64 #1 SMP Mon Apr 22 00:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@orion ~]# git clone git://git.asterisk.org/team/sruffell/dahdi-linux dahdi-for-5.0
Cloning into 'dahdi-for-5.0'...
remote: Counting objects: 20639, done.
remote: Compressing objects: 100% (3910/3910), done.
remote: Total 20639 (delta 13631), reused 20639 (delta 13631)
Receiving objects: 100% (20639/20639), 21.32 MiB | 2.40 MiB/s, done.
Resolving deltas: 100% (13631/13631), done.

make install:
...
 CC [M]  /root/dahdi-for-5.0/drivers/dahdi/oct612x/oct612x-user.o
/root/dahdi-for-5.0/drivers/dahdi/oct612x/oct612x-user.c: In function ‘Oct6100UserGetTime’:
/root/dahdi-for-5.0/drivers/dahdi/oct612x/oct612x-user.c:38:2: error: implicit declaration of function ‘do_gettimeofday’; did you mean ‘do_settimeofday64’? [-Werror=implicit-function-declaration]
 do_gettimeofday(&tv);
 ^~~~~~~~~~~~~~~
 do_settimeofday64


By: Shaun Ruffell (sruffell) 2019-04-26 08:50:34.916-0500

Hmm, are you sure you're building the branch you checked out?

Looking at the source, there is no do_settimeofday64() call at the line the error is reported above.

http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=blob;f=drivers/dahdi/oct612x/oct612x-user.c;h=73f1d48b1addd461197fe94971ce8ac3ef4a3eca;hb=refs/heads/for-5.0#l37
By: Alex Regan (gossamer) 2019-04-26 09:53:19.717-0500

Yes, this is absolutely the your branch. This is what I see near those lines:
(I'm sorry, I dont know how how to format it for code)

[code]
   31  UINT32 Oct6100UserGetTime(tPOCT6100_GET_TIME f_pTime)
   32  {
   33          /* Why couldn't they just take a timeval like everyone else? */
   34          struct timeval tv;
   35          unsigned long long total_usecs;
   36          unsigned int mask = ~0;
   37  
   38          do_gettimeofday(&tv);
   39          total_usecs = (((unsigned long long)(tv.tv_sec)) * 1000000) +
   40                                    (((unsigned long long)(tv.tv_usec)));
   41          f_pTime->aulWallTimeUs[0] = (total_usecs & mask);
   42          f_pTime->aulWallTimeUs[1] = (total_usecs >> 32);
   43          return cOCT6100_ERR_OK;
   44  }[/code]
By: Joshua C. Colp (jcolp) 2019-04-26 09:56:02.180-0500

Your git clone did not change into the branch. You would need to do "git checkout for-5.0" to go into the branch.
By: Shaun Ruffell (sruffell) 2019-04-26 10:01:07.754-0500

Hey [~jcolp], good catch, I missed that in the output he posted.
By: Alex Regan (gossamer) 2019-04-26 10:24:44.942-0500

I'm not sure I understand.

# git clone git://git.asterisk.org/team/sruffell/dahdi-linux for-5.0
Cloning into 'for-5.0'...
remote: Counting objects: 20639, done.
remote: Compressing objects: 100% (3910/3910), done.
remote: Total 20639 (delta 13631), reused 20639 (delta 13631)
Receiving objects: 100% (20639/20639), 21.32 MiB | 5.97 MiB/s, done.
Resolving deltas: 100% (13631/13631), done.

# git checkout git://git.asterisk.org/team/sruffell/dahdi-linux for-5.0
fatal: not a git repository (or any of the parent directories): .git

# git pull git://git.asterisk.org/team/sruffell/dahdi-linux for-5.0
fatal: not a git repository (or any of the parent directories): .git

By: Joshua C. Colp (jcolp) 2019-04-26 10:26:29.794-0500

Full instructions would be:

git clone git://git.asterisk.org/team/sruffell/dahdi-linux
cd dahdi-linux
git checkout for-5.0

Before you were checking out dahdi-linux into a directory named "for-5.0" but the branch was "master".
By: Alex Regan (gossamer) 2019-04-26 10:30:21.461-0500

Awesome. Thanks so much.

By: Alex Regan (gossamer) 2019-04-26 13:14:51.744-0500

Could this error that's seemingly preventing me from loading dahdi properly be related to this branch?

[Apr 26 11:34:04] ERROR[2296] loader.c: Error loading module 'res_ari_mailboxes.so': /usr/lib64/asterisk/modules/res_ari_mailboxes.so: undefined symbol: stasis_app_mailbox_to_json

Apr 26 14:11:26 orion systemd[1]: Starting The DAHDI drivers allow you to use your linux computer to accept incoming data and voice interfaces...
Apr 26 14:11:26 orion sh[32051]: modprobe: FATAL: Module wctdm not found in directory /lib/modules/5.0.9-200.fc29.x86_64
Apr 26 14:11:26 orion sh[32051]: DAHDI_CHANCONFIG failed on channel 1: Invalid argument (22)
Apr 26 14:11:26 orion sh[32051]: Selected signaling not supported
Apr 26 14:11:26 orion sh[32051]: Possible causes:
Apr 26 14:11:26 orion sh[32051]: #011FXS signaling is being used on a FXS interface (use a FXO signaling variant)
Apr 26 14:11:26 orion sh[32051]: #011RBS signaling is being used on a E1 CCS span
Apr 26 14:11:26 orion sh[32051]: #011Signaling is being assigned to channel 16 of an E1 CAS span
Apr 26 14:11:26 orion kernel: dahdi_ioctl_chanconfig: No channel for number 1
Apr 26 14:11:26 orion systemd[1]: dahdi.service: Main process exited, code=exited, status=1/FAILURE
Apr 26 14:11:26 orion systemd[1]: dahdi.service: Failed with result 'exit-code'.
Apr 26 14:11:26 orion systemd[1]: Failed to start The DAHDI drivers allow you to use your linux computer to accept incoming data and voice interfaces.

[root@orion 5.0.9-200.fc29.x86_64]# find . -name wctdm\* -ls
268693686      0 drwxr-xr-x   2  root     root           27 Apr 26 11:29 ./dahdi/wctdm24xxp
268698566   1668 -rw-r--r--   1  root     root      1704288 Apr 26 11:29 ./dahdi/wctdm24xxp/wctdm24xxp.ko


By: Anthony Messina (amessina) 2019-04-26 19:09:09.664-0500

Alex, you can try the packages I build in Copr here: https://copr.fedorainfracloud.org/coprs/amessina/f29-kmod/
By: Alex Regan (gossamer) 2019-04-26 21:12:00.245-0500

Thanks very much. I've installed the repo but still having a problem. Usually I just run "service dahdi restart" and it loads the modules. It doesn't appear this now exists as a service. Am I missing a package?

# rpm -qva|grep dahdi
kmod-dahdi-linux-3.0.0-3.gitb9179db.fc29.4.x86_64
dahdi-linux-3.0.0-1.fc29.noarch
dahdi-tools-3.0.0-1.fc29.x86_64
dahdi-tools-libs-3.0.0-1.fc29.x86_64
kmod-dahdi-linux-5.0.9-200.fc29.x86_64-3.0.0-3.gitb9179db.fc29.4.x86_64
akmod-dahdi-linux-3.0.0-3.gitb9179db.fc29.4.x86_64
asterisk-dahdi-16.2.1-1.fc29.x86_64

# dnf repolist
Last metadata expiration check: 0:13:01 ago on Fri 26 Apr 2019 09:57:05 PM EDT.
repo id                                                repo name                                                                     status
amessina-f29-kmod                                      Copr repo for f29-kmod owned by amessina                                          76
amessina-telephony                                     Copr repo for telephony owned by amessina                                        288
*fedora                                                Fedora 29 - x86_64                                                            58,206
*fedora-modular                                        Fedora Modular 29 - x86_64                                                         8
*updates                                               Fedora 29 - x86_64 - Updates                                                  19,645
*updates-modular                                       Fedora Modular 29 - x86_64 - Updates                                               9
*updates-testing                                       Fedora 29 - x86_64 - Test Updates                                              3,505

By: Anthony Messina (amessina) 2019-04-27 09:26:34.604-0500

Alex, the DAHDI init scripts haven't been necessary for a while.  Most of this is handled by udev and whatever configuration you have in /etc/dahdi/assigned-spans.conf

For example, you would find out where your device is in the sysfs interface and enter something like the following in /etc/dahdi/assigned-spans.conf -- whatever matches your card (see /etc/assigned-spans.conf.sample)
{code}
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/pci:0000:02:08.0 1:1:
{code}

Then in /etc/modprobe.d/dahdi.conf
{code}
options dahdi auto_assign_spans=0
{code}

Check into http://docs.tzafrir.org.il/dahdi-linux/#_span_assignments -- I am not an expert in the best way to handle this, but the above has worked for me with single and multiple devices for years now.  Also, beware of https://issues.asterisk.org/jira/browse/DAHTOOL-82 -- you may need to edit some of the udev scripts (I haven't yet fixed these via packaging since I'm hoping upstream will be getting some of this done).

I began configuring these devices explicitly a while back since for a time, I had multiple DAHDI devices.

It looks like you already grabbed dahdi-tools from https://copr.fedorainfracloud.org/coprs/amessina/telephony

Alternatively, you could create the systemd.service file yourself based on the upstream sources.
By: Shaun Ruffell (sruffell) 2019-04-27 11:53:54.550-0500

Something else may be causing you problems here as well. In the release this branch is based on, the after driver was removed. :(
By: Alex Regan (gossamer) 2019-04-28 21:12:40.549-0500

I have the following in  /etc/dahdi/assigned-spans.conf, which says it was autogenerated in 2017.
     /sys/devices/pci0000:00/0000:00:03.2/0000:04:00.0/0000:05:00.0/pci:0000:05:00.0 1:1:1

I also have /etc/modprobe.d/dahdi.conf with the options you've listed.

There isn't anyone who knows for sure whether this works with a 5.0 kernel?

I also saw a comment about that the timekeeping interface in 5.0 changed, but now can't find it? Does this pertain to this problem?

I have the Tiger3XX card that I believe uses the wctdm driver, but it is not loaded. dahdi also was not loaded after reboot.

05:00.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface
       Subsystem: ATCOM Technology co., LTD. Device 0001
       Flags: bus master, medium devsel, latency 64, IRQ 11, NUMA node 0
       I/O ports at d000 [size=256]
       Memory at fb200000 (32-bit, non-prefetchable) [size=4K]
       Capabilities: [40] Power Management version 2
       Kernel modules: hisax

I used to be much more involved with kernel development, but now just need something that works. I'm really hoping you guys can confirm whether this works on 5.0 and the steps I need to make it work. I'd appreciate any ideas you may have. This has all "just worked" without much fuss since I did the migration to the new dahdi format in like 2010, lol.




By: Shaun Ruffell (sruffell) 2019-04-28 21:29:36.575-0500

a) Yes, the branch works with the 5.0 kernel

b) If you have a Tiger3XX card that depends on the wctdm driver, this branch will not work, and there is not a branch that will work since Digium removed support for the wctdm driver before the v3.0.0 release in commit [1] 04e759f

[1] http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=commit;h=04e759f9c5a6f76ed88bc6ba6446fb0c23c1ff55

You may want to reach out to ATCOM to see if they are still actively supporting your card
By: Alex Regan (gossamer) 2019-04-29 07:55:57.216-0500

Shaun, thanks so much. Do you have any recommendations for a similar replacement? That might be an easier approach than expecting ATCOM to provide drivers...

The current compatibility list goes back to 2016. I just need a simple 4-port card to do SIP. PCI-e 2.0, I believe?
https://wiki.asterisk.org/wiki/display/DAHDI/DAHDI+compatible+hardware
By: Shaun Ruffell (sruffell) 2019-04-29 09:14:52.381-0500

Personally, I would recommend a Digium A4B then since the sales of those cards help support maintaining DAHDI and Asterisk.  But, it's true that I used to be a Digium employee (but I was also a card customer before I was an employee).
By: Alex Regan (gossamer) 2019-04-29 14:43:43.066-0500

Shaun, thanks again. Do you have any recommendations for a more budget-friendly card?

I'm not sure we need much more than a basic FXO(?) card for simply connecting to a cable modem phone...

By: Malcolm Davenport (mdavenport) 2019-04-29 15:00:03.909-0500

The A4B and A4A are the most affordable of the analog cards that we build.
By: Alex Regan (gossamer) 2019-04-29 15:22:23.902-0500

Thanks, Malcolm. I found a link to CDW on the Digium site that lists this card (1A4B00F)

https://www.cdw.com/product/digium-voice-interface-card/4645538?pfm=srh

That's a little more affordable. Is that the same card? Is that still supported? Or is it really just the three A4/A8/2400 that you make/support now?

It appears Atcom is no longer developing cards? None of the TDM cards are supported either?

By: Malcolm Davenport (mdavenport) 2019-04-29 15:27:01.627-0500

That's the base A4B (PCIe) card.  No analog modules.  No echo module.  It has four module slots for adding analog modules.  You need an analog module for each interface (either FXO or FXS) you want to provide.
By: Alex Regan (gossamer) 2019-04-29 16:16:30.042-0500

Thanks for sticking with me. I'm starting to understand. Are any of the Sangoma cards an option at this point?

Would you confirm this PCI-e card is the one I need to connect to the cable modem analog line?
https://www.ebay.com/itm/Digium-4-Port-Analog-PCI-E-Asterisk-Card-with-0-FXS-4-FXO-1-EC-1A4B03F/151645995342

This will support up to three analog lines?

I'm curious why none of these TDM/ATCOM/AXE cards that are so dominant and inexpensive aren't supported any longer?
By: Malcolm Davenport (mdavenport) 2019-04-30 08:47:34.998-0500

The Sangoma A200 is a supported option.  I don't know the exact bundling SKU you'd want there.  We're now in the land of sales questions.

That particular link points to the A4B PCIe card that is bundled with four FXO (connect to lines from your telco that come into your office..that line could be the telephone set port on a cable modem) module and one echo cancellation module.  That'll support four analog lines.

Those companies that aren't Digium or Sangoma simply built knock-offs or created outright clones.  The drivers that those knock-offs use are drivers that we originally wrote for our cards - we didn't write them for anyone else's cards.  We quit selling those older models of our cards years (a decade) ago.  We don't support or test or manufacture those older cards any more.  There's no benefit to us carrying those drivers forward.  

Those companies that aren't Digium and Sangoma are companies that do not contribute to the development or support of Asterisk.  They're not writing new features and contributing them.  They're not fixing bugs.  They're existing purely off the hard work of others.  Putting dollars into their coffers diminishes Asterisk.
By: Alex Regan (gossamer) 2019-04-30 10:07:20.404-0500

Thanks very much for the explanation. I was aware of Digium's relationship to asterisk, the development of the drivers, and the development/production of the boards, but I was not aware the others were complete knock-offs. I've purchased the Digium 1A4B03F PCI-E.

By: Alex Regan (gossamer) 2019-05-04 13:06:09.364-0500

Hi guys, I now have the A4B controller and having some trouble getting it recognized. It appears to have loaded the right modules, but it's not recognized.

# dmesg|grep dahdi
[    4.685478] dahdi: loading out-of-tree module taints kernel.
[    4.686393] dahdi: module verification failed: signature and/or required key missing - tainting kernel
[    4.688443] dahdi: Version: 3.0.0
[    4.688590] dahdi: Telephony Interface Registered on major 196

# dmesg|grep A4B
[    8.758034] wcaxx 0000:04:00.0: Found a Wildcard A4B (SN: XXXXX - DM42190900026 - C - 20190313)

# lsmod|grep dahdi
dahdi                 245760  2 oct612x,wcaxx

# rpm -qva|grep -E 'dahdi|kmod|asterisk'
kmod-dahdi-linux-3.0.0-3.gitb9179db.fc29.5.x86_64
asterisk-sip-16.3.0-2.git6ec4b113c1.fc29.x86_64
akmods-0.5.6-19.fc29.noarch
asterisk-voicemail-plain-16.3.0-2.git6ec4b113c1.fc29.x86_64
kmod-dahdi-linux-5.0.10-200.fc29.x86_64-3.0.0-3.gitb9179db.fc29.5.x86_64
kmod-25-3.fc29.x86_64
dahdi-linux-3.0.0-1.fc29.noarch
dahdi-tools-3.0.0-1.fc29.x86_64
dahdi-tools-libs-3.0.0-1.fc29.x86_64
kmodtool-1-33.fc29.noarch
asterisk-fax-16.3.0-2.git6ec4b113c1.fc29.x86_64
asterisk-sounds-core-en-1.6.1-4.fc29.noarch
akmod-dahdi-linux-3.0.0-3.gitb9179db.fc29.5.x86_64
kmod-dahdi-linux-5.0.9-200.fc29.x86_64-3.0.0-3.gitb9179db.fc29.4.x86_64
kmod-libs-25-3.fc29.x86_64
asterisk-dahdi-16.3.0-2.git6ec4b113c1.fc29.x86_64
asterisk-sounds-core-en-gsm-1.6.1-4.fc29.noarch
asterisk-16.3.0-2.git6ec4b113c1.fc29.x86_64
asterisk-voicemail-16.3.0-2.git6ec4b113c1.fc29.x86_64

# asterisk -r
...
[May  4 13:54:08] WARNING[21579][C-00000003]: app_dial.c:2507 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 0 - Unknown)

I also tried building/installing from source and it also resulted in the same error message.




By: Shaun Ruffell (sruffell) 2019-05-05 10:10:33.623-0500

Hi Alex,

There isn't enough information here for me to debug what exactly is happening (does the new hardware channel configuration match your old hardware configuration? is the dahdi init script running properly to set the channel configuration? does the asterisk dahdi configuration match the new hardware configuratio?

Since you've purchased one of the cards, the quickest way to get things setup is going to be to contact Digium technical support ( https://www.digium.com/support/contact ). They can log onto your system and help ensure that everything is configured properly.
By: Keith Morgan (kmorgan) 2019-05-31 08:25:17.083-0500

dahdi-linux dahdi-tools and dahdi-complete 3.1.0-rc1  available for testing.

http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-3.1.0-rc1+3.1.0-rc1.tar.gz
http://downloads.asterisk.org/pub/telephony/dahdi-linux/dahdi-linux-3.1.0-rc1.tar.gz
http://downloads.asterisk.org/pub/telephony/dahdi-tools/dahdi-tools-3.1.0-rc1.tar.gz

Tested on Fedora 30 and Ubuntu 19.
Will close this ticket since a new one was opened with support at https://www.digium.com/support/contact