dynamic-loc-call test fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dahdi-linux (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Lunar |
New
|
Undecided
|
Unassigned |
Bug Description
The dynamic-loc-call test fails with the following:
[E] Spans not created or channels not properly registered in Asterisk.
The module is loaded without issue,s but there are failed logs in dmesg:
[ 1183.547021] dahdi: dahdi_unassign_
[ 1183.547039] dahdi: disable_span: span 1
[ 1183.552345] dahdi: dahdi_unassign_
[ 1183.552366] dahdi: disable_span: span 2
[ 1183.575782] TDMoL: Removed interface for DYN/loc/1:1, key 1 id 1
[ 1183.575792] dahdi: disable_span: span 0
[ 1183.575796] dahdi_devices dynamic:loc:1: local span 1 is already unassigned
[ 1183.673992] TDMoL: Removed interface for DYN/loc/1:0, key 1 id 0
[ 1183.674002] dahdi: disable_span: span 0
[ 1183.674005] dahdi_devices dynamic:loc:0: local span 1 is already unassigned
[ 1183.875872] DAHDI Dynamic Span support unloaded
[ 1183.900454] dahdi: Telephony Interface Unloaded
[ 1187.979061] dahdi: Version: 2.11.1.0.20170917
[ 1187.979236] dahdi: Telephony Interface Registered on major 196
[ 1187.982430] DAHDI Dynamic Span support LOADED
[ 1187.984543] TDMoL: Added new interface for DYN/loc/1:0, key 1 id 0
[ 1187.984590] TDMoX: No master.
[ 1188.049900] dahdi_echocan_
[ 1188.049907] dahdi_echocan_
[ 1188.049917] dahdi_echocan_
[ 1188.049919] dahdi_echocan_
[ 1188.049929] dahdi_echocan_
[ 1188.049930] dahdi_echocan_
[ 1188.085064] TDMoL: Added new interface for DYN/loc/1:1, key 1 id 1
[ 1188.085116] TDMoX: No master.
[ 1188.113916] Span DYN/loc/1:1: Expected seq no 0, but received 48 instead
[ 1188.132020] dahdi_echocan_
[ 1188.132024] dahdi_echocan_
[ 1188.132030] dahdi_echocan_
[ 1188.132031] dahdi_echocan_
[ 1188.132037] dahdi_echocan_
[ 1188.132037] dahdi_echocan_
This issue was spotted on Lunar linux-aws while carrying out the tests for the 6.2.0-1005.5 release. Full logs can be seen here: https:/
It seems to affect all arches supported by this kernel.
One version before (6.2.0-1004.4) worked as expected. See full logs here: https:/
This looks to be an odd interaction between binutils, the kernel, and the way dahdi gets built. The dahdi_echocan_oslec module depends on echo.ko and the reported symbols belong to that. This modules is part of the kernel. It used to be in drivers/staging but moved to drivers/misc. The required header "oslec.h" unfortunately is not exported but seems to match the copy in dahdi-linux.
The dahdi-dkms spec file got modified so it does not install echo.ko from the dahdi build, but the module gets built regardless whenever dahdi_echocan_oslec is built. I am guessing that in that case linkage prefers the external built module over the existing kernel module. Which seems to work sometimes but then there are the cases where things do not match up. So dahdi_echocan_oslec cannot be loaded and the test fails.
I was able to get a previously failing test to work by changing the /usr/src/ dahdi-* /drivers/ dahdi/Kbuild file the following way (additional comment):
ifneq (,$(wildcard $(src)/ ../staging/ echo/echo. c)) oslec.o echo/echo. o
obj-m += dahdi_echocan_
#obj-m += ../staging/
endif