The dahdi kernel module (used by asterisk for some Digium telephony cards, including the one I have) is not included in Fedora because it is not free software. The dahdi configuration tools are included, but not the kernel module. The software is free as in beer, it can be downloaded and built, and I have successfully done that in the past. However, the last time the kernel module compiled successfully was back at kernel-4.6.3-300.fc24.x86_64 . On all newer kernels that I have tried, I get this:
[root@worldsys dahdi-linux-master]# make make -C drivers/dahdi/firmware firmware-loaders make[1]: Entering directory '/local/src/dahdi-linux-master/drivers/dahdi/firmware' make[1]: Leaving directory '/local/src/dahdi-linux-master/drivers/dahdi/firmware' make -C /lib/modules/4.11.12-100.fc24.x86_64/build SUBDIRS=/local/src/dahdi-linux-master/drivers/dahdi DAHDI_INCLUDE=/local/src/dahdi-linux-master/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m make[1]: Entering directory '/usr/src/kernels/4.11.12-100.fc24.x86_64' CC [M] /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.o /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.c: In function ‘dahdi_ioctl_iomux’: /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.c:5954:7: error: implicit declaration of function ‘signal_pending’ [-Werror=implicit-function-declaration] if (signal_pending(current)) { ^~~~~~~~~~~~~~ cc1: some warnings being treated as errors scripts/Makefile.build:294: recipe for target '/local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.o' failed make[2]: *** [/local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.o] Error 1 Makefile:1496: recipe for target '_module_/local/src/dahdi-linux-master/drivers/dahdi' failed make[1]: *** [_module_/local/src/dahdi-linux-master/drivers/dahdi] Error 2 make[1]: Leaving directory '/usr/src/kernels/4.11.12-100.fc24.x86_64'
It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source.
Thanks, --Greg
On 07/30/2017 01:54 PM, Greg Woods wrote:
It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source.
Have you discussed this with the people who wrote and maintain this?
On Sun, Jul 30, 2017 at 3:04 PM, Joe Zeff joe@zeff.us wrote:
On 07/30/2017 01:54 PM, Greg Woods wrote:
It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source.
Have you discussed this with the people who wrote and maintain this?
I did what I probably should have done in the first place: I posted this to the asterisk list. And it turns out someone does have a patched src rpm. When I get some time later this week, I'll try it out, because I definitely don't want to be running a kernel that I can't update.
--Greg
On Sun, Jul 30, 2017 at 9:47 PM, Greg Woods woods@ucar.edu wrote:
On Sun, Jul 30, 2017 at 3:04 PM, Joe Zeff joe@zeff.us wrote:
On 07/30/2017 01:54 PM, Greg Woods wrote:
It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source.
Have you discussed this with the people who wrote and maintain this?
I did what I probably should have done in the first place: I posted this to the asterisk list. And it turns out someone does have a patched src rpm. When I get some time later this week, I'll try it out, because I definitely don't want to be running a kernel that I can't update.
Just to close out this thread in case someone encounters it in the archives later: I was able to find some patch files inside the source RPM at
https://messinet.com/pub/fedora/linux/updates/26/SRPMS/
This also contains the 2.11 version of the dahdi-linux module. After refreshing my memory on how to use the patch program, I was able to apply the patches and build the module for the latest F24 kernel (4.11.12-100.fc24.x86_64) and it is working. Hopefully I can now proceed to upgrade the asterisk server box to F25 and then F26, and build the dahdi module for those kernels.
--Greg
On 08/01/2017 08:48 PM, Greg Woods wrote:
On Sun, Jul 30, 2017 at 9:47 PM, Greg Woods <woods@ucar.edu mailto:woods@ucar.edu> wrote:
On Sun, Jul 30, 2017 at 3:04 PM, Joe Zeff <joe@zeff.us <mailto:joe@zeff.us>> wrote: On 07/30/2017 01:54 PM, Greg Woods wrote: It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source. Have you discussed this with the people who wrote and maintain this? I did what I probably should have done in the first place: I posted this to the asterisk list. And it turns out someone does have a patched src rpm. When I get some time later this week, I'll try it out, because I definitely don't want to be running a kernel that I can't update.Just to close out this thread in case someone encounters it in the archives later: I was able to find some patch files inside the source RPM at
https://messinet.com/pub/fedora/linux/updates/26/SRPMS/
This also contains the 2.11 version of the dahdi-linux module. After refreshing my memory on how to use the patch program, I was able to apply the patches and build the module for the latest F24 kernel (4.11.12-100.fc24.x86_64) and it is working. Hopefully I can now proceed to upgrade the asterisk server box to F25 and then F26, and build the dahdi module for those kernels.
You should check out https://messinet.com/rpms/
Scan down the page and you'd find they have their own repo you could install on your F26 system and just use dnf to install their stuff.
On 08/01/2017 09:31 PM, Ed Greshko wrote:
On 08/01/2017 08:48 PM, Greg Woods wrote:
On Sun, Jul 30, 2017 at 9:47 PM, Greg Woods <woods@ucar.edu mailto:woods@ucar.edu> wrote:
On Sun, Jul 30, 2017 at 3:04 PM, Joe Zeff <joe@zeff.us <mailto:joe@zeff.us>> wrote: On 07/30/2017 01:54 PM, Greg Woods wrote: It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source. Have you discussed this with the people who wrote and maintain this? I did what I probably should have done in the first place: I posted this to the asterisk list. And it turns out someone does have a patched src rpm. When I get some time later this week, I'll try it out, because I definitely don't want to be running a kernel that I can't update.Just to close out this thread in case someone encounters it in the archives later: I was able to find some patch files inside the source RPM at
https://messinet.com/pub/fedora/linux/updates/26/SRPMS/
This also contains the 2.11 version of the dahdi-linux module. After refreshing my memory on how to use the patch program, I was able to apply the patches and build the module for the latest F24 kernel (4.11.12-100.fc24.x86_64) and it is working. Hopefully I can now proceed to upgrade the asterisk server box to F25 and then F26, and build the dahdi module for those kernels.
You should check out https://messinet.com/rpms/
Scan down the page and you'd find they have their own repo you could install on your F26 system and just use dnf to install their stuff.
And they use koji ....
https://messinet.com/koji/buildinfo?buildID=3118
On 07/30/2017 01:54 PM, Greg Woods wrote:
/local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.c: In function ‘dahdi_ioctl_iomux’: /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.c:5954:7: error: implicit declaration of function ‘signal_pending’ [-Werror=implicit-function-declaration] if (signal_pending(current)) { ^~~~~~~~~~~~~~ cc1: some warnings being treated as errors
It looks like some warnings are being treated as errors, such as an implicit function declaration in this case. Is there a way I can turn that off just long enough to get this module built? I'm stuck running a non-updateable kernel until I can find a way around this. In my early career I used to build stuff all the time, but it has been a while since I have had to compile anything from source.
That is a warning that generally indicates an error. You might be able to ignore that warning, but you will probably get a linking error further on. It's possible that that function has been changed. I don't see that function name in my /usr/include anywhere. Has the module source been kept up-to-date with the kernel? As Joe said, check with upstream. If they're going to supply a non-free kernel module, they'll have to deal with the problems.
On Sun, Jul 30, 2017 at 3:24 PM, Samuel Sieb samuel@sieb.net wrote:
If they're going to supply a non-free kernel module, they'll have to deal with the problems.
I suppose so, but "upstream" in this case is a hardware vendor, who is much less motivated to keep supporting a 10-year-old card than they are to sell new hardware. The last update to the module source was around March of 2016. Unfortunately telephony cards in general are way overpriced for what they do. Maybe patents involved? But this was a $600 PCI card ten years ago, I can't afford to just junk it now. If it weren't so expensive to replace, I wouldn't even think of trying to keep running hardware this old.
I guess I can file a support ticket with Digium, but I doubt I'll get much of a helpful response. I was just sort of hoping against hope that somebody had seen this and knew of a workaround.
In the meantime my only real option is to keep running the old kernel.
A Fedora-related question is wondering whether I can upgrade to F25 and still keep running an F24 kernel.
--Greg
On 07/30/2017 02:40 PM, Greg Woods wrote:
I suppose so, but "upstream" in this case is a hardware vendor, who is much less motivated to keep supporting a 10-year-old card than they are to sell new hardware. The last update to the module source was around March of 2016. Unfortunately telephony cards in general are way overpriced for what they do. Maybe patents involved? But this was a $600 PCI card ten years ago, I can't afford to just junk it now. If it weren't so expensive to replace, I wouldn't even think of trying to keep running hardware this old.
I've seen similar cards for significantly less than that. And depending on what you're trying to do, there are other options as well. If you're interested, email me directly to take it off the list.
A Fedora-related question is wondering whether I can upgrade to F25 and still keep running an F24 kernel.
I would expect things would keep working. Just be careful that the kernel you want doesn't get removed during an update. The easiest method would be to keep the latest kernel and the kernel you want. Any other kernel packages will need to be removed before doing any updates.
I've been working on this too, this week. I think I have it working from source but haven't finished testing yet. The source install wasn't really too bad, so I recommend it. The messinet rpms didn't work for me.
Quoting "Dr. Robert Marmorstein" marmorsteinrm@longwood.edu:
I've been working on this too, this week. I think I have it working from source but haven't finished testing yet. The source install wasn't really too bad, so I recommend it. The messinet rpms didn't work for me.
Feel free to contact me offline to let me know what didn't work and I may be able to resolve that in future packages. -A
-
Anthony Messina -
Dr. Robert Marmorstein -
Ed Greshko -
Ed Greshko -
Greg Woods -
Joe Zeff -
Samuel Sieb