asterisk
Build fails linking dahdi_vpmadt032_loader.o
Dahdi Linux version: 3.4.0 (cloned from here) Linux: Fedora Linux 6.15.6-200.fc42.x86_64 Related issues: #94 #93
I believe that the problem is in the vpmadt032_x86_64.o_shipped. See the output of nm below.
Functions __vpmadt032_cleanup and __vpmadt032_init in the firmware's source code needs some maintenance similar to the snippet from my patch to dahdi_dummy.c patch shown below.
Note: I am not an expert C coder, kernel programmer, or Dahdi programmer so my patch needs to be reviewed and tested carefully. I have been using a small subset of the Dahdi functionality for a simple answering machine for over 10 years.
Error output from make:
CC [M] vpmadt032_loader/dahdi_vpmadt032_loader.o
COPY vpmadt032_loader/vpmadt032_x86_64.o
LD [M] dahdi_vpmadt032_loader.o
dahdi_vpmadt032_loader.o: warning: objtool: .text+0x444a: unannotated intra-function call
make[4]: *** [/usr/src/kernels/6.15.6-200.fc42.x86_64/scripts/Makefile.build:408: dahdi_vpmadt032_loader.o] Error 255
make[4]: *** Deleting file 'dahdi_vpmadt032_loader.o'
make[3]: *** [/usr/src/kernels/6.15.6-200.fc42.x86_64/Makefile:2043: .] Error 2
make[2]: *** [/usr/src/kernels/6.15.6-200.fc42.x86_64/Makefile:260: __sub-make] Error 2
make[2]: Leaving directory '/home/zippy/tmp/dahdi-linux.3.4.0/drivers/dahdi'
make[1]: *** [Makefile:260: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/kernels/6.15.6-200.fc42.x86_64'
make: *** [Makefile:74: modules] Error 2
Output from nm:
$ nm vpmadt032_x86_64.o_shipped
000000000000630e T __vpmadt032_cleanup
0000000000006283 T __vpmadt032_done
000000000000433e T __vpmadt032_init
0000000000000000 D __vpmadt032_loader_version
000000000000497f T __vpmadt032_receive
0000000000004907 T __vpmadt032_start_load
0000000000006185 T __vpmadt032_transmit
Snippet from dahdi_dummy.c patch
-int init_module(void)
+static int __init dahdi_dummy_init(void)
-void cleanup_module(void)
+static void __exit dahdi_dummy_cleanup_module(void)
+module_init(dahdi_dummy_init);
+module_exit(dahdi_dummy_cleanup_module);
Cannot upload the dahdi_dummy.patch so contents pasted below.
Review carefully.
diff --git a/drivers/dahdi/dahdi_dummy.c b/drivers/dahdi/dahdi_dummy.c
index b1004d9..76a265d 100644
--- a/drivers/dahdi/dahdi_dummy.c
+++ b/drivers/dahdi/dahdi_dummy.c
@@ -209,7 +209,7 @@ static int dahdi_dummy_initialize(struct dahdi_dummy *ztd)
return res;
}
-int init_module(void)
+static int __init dahdi_dummy_init(void)
{
int res;
ztd = kzalloc(sizeof(*ztd), GFP_KERNEL);
@@ -227,9 +227,10 @@ int init_module(void)
return res;
}
+
#if defined(USE_HIGHRESTIMER)
printk(KERN_DEBUG "dahdi_dummy: Trying to load High Resolution Timer\n");
- hrtimer_init(&zaptimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_setup(&zaptimer, dahdi_dummy_hr_int, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
printk(KERN_DEBUG "dahdi_dummy: Initialized High Resolution Timer\n");
/* Set timer callback function */
@@ -250,8 +251,7 @@ int init_module(void)
return 0;
}
-
-void cleanup_module(void)
+static void __exit dahdi_dummy_cleanup_module(void)
{
#if defined(USE_HIGHRESTIMER)
/* Stop high resolution timer */
@@ -272,3 +272,6 @@ module_param(debug, int, 0600);
MODULE_DESCRIPTION("Timing-Only Driver");
MODULE_AUTHOR("Robert Pleh <[email protected]>");
MODULE_LICENSE("GPL v2");
+
+module_init(dahdi_dummy_init);
+module_exit(dahdi_dummy_cleanup_module);
This looks like the same issue as what I reported in #80, but you've given quite a bit more detail - I was a bit puzzled as to what this might be myself but now it makes more sense (and by the way, I've put up PRs for both of the issues with dahdi_dummy - thanks for bringing that to my attention).
However, since only the shipped object file is present, I believe this is something that presumably Digium/Sangoma can fix, since the source code for that file isn't present in the tree. For the time being, I've been reverting the kernel commit that made objtool failures fatal, just to allow builds to proceed, but that's obviously not a real solution.
A quick follow-up:
- I created a stub object file containing empty functions for the 4 functions listed in vpmadt032_x86_64.o_shipped
- Ran the build until it aborted on aborted on the linking of dahdi_vpmadt032_loader.o as per above.
- Overwrote vpmadt032_x86_64.o_shipped with my stub object file. (I don't know how to alter the kbuild file to do this.)
- Continued the build and it got past the linkage problem but started to throw errors and abort on compiling some of the drivers.
- Edited some other driver source code files to resolve the errors.
- But when these errors were "resolved", the build aborted at the final linkage step with undefined symbols.
So there is some more work to be done patching some source code to support 6.15+ kernel. On of the errors had to do with not finding certain kernel include files. I hacked and hard-coded the path to the include files but there were multiple copies on my desktop to I wasn't sure if I picked the correct ones.
Happily, I realised that all I needed for my poor-man's answering machine app was the dahdi.ko and (deprecated) wcfxo.ko modules so I commented out everything that is unneeded in the kbuild file. These kernel modules build, install and run on my Fedora Linux desktop with the patched 3.4.0 dahdi-linux and 6.17 kernel. It does throw the seemingly innocuous messages below upon boot, even with 6.14 kernel, which I don't remember seeing in dahdi-linux 3.0.0.
Sep 23 09:23:06 zippy kernel: NMI: PCI system error (SERR) for reason b0 on CPU 0.
Sep 23 09:23:06 zippy kernel: Dazed and confused, but trying to continue
System:
Kernel: 6.17.0-0.rc7.56.fc43.x86_64 arch: x86_64 bits: 64 compiler: gcc
v: 15.2.1
Desktop: Cinnamon v: 6.4.9 Distro: Fedora Linux 42 (Adams)
Both a stub file and commenting out drivers in kbuild are just workarounds and don't address the real issue here.
The real issue is that @push143smart and @duncanpatterson are AWOL and not doing anything to maintain DAHDI, and while I have been trying to stay on top of things, this seems to be some kind of binary that only a Sangoma employee would be able to generate since the source is not in the tree.
The real issue is that @push143smart and @duncanpatterson are AWOL and not doing anything to maintain DAHDI, and while I have been trying to stay on top of things, this seems to be some kind of binary that only a Sangoma employee would be able to generate since the source is not in the tree.
This is unfortunate because the binary firmware is blocking some other Linux distributions like Debian and Ubuntu.
I think it is questionable if this Sangoma company will release an updated (aka recompiled) binary. It appears that it hasn't been updated in many years.
- The reason for making a stub was to see what other compile/build issues would be encountered after dahdi_vpmadt032_loader
- And then explore the possibility of using a "decompiler" to generate C-code from the proprietary binary:
* But this is probably not legally appropriate solution* I couldn't get this tool installed and functional* This type of hacking and programming is probably way beyond my level of expertise* But it may be doable because the binary was compiled long ago with the gcc compiler - Then I discovered that I didn't need this proprietary firmware and the subsequent drivers for other cards.
I can confirm, I've hit the issue under Debian and chose the nuclear option of reverting to an older kernel and packages to ride the crescent-fresh wave of distributed packages in a known operable state. I did stray into the weeds on this (much like the above) and basically came to the same conclusion, but wanting a quickly-packagable-and-repeatable vps deployment I can reproduce easily, ended up choosing the path of installing at a certain state, upgrading to no further than a set point, and holding packages until this is fixed.
Hoping for some progress on the Digium/Sangoma binary front.
If you dont use hardware echo canceler daughter board vpmadt032 you can comment out in the Kbuid dahdi/linux/drivers/dahdi/Kbuid this section
after that dahdi compile and install with kernel 6.15 I know it's a temporary solution while Sangoma fixes the problem, but it's better than tinkering with the firmware code.
