Created attachment 399962 [details] emerge --info emerge of net-misc/dahdi-2.10.0.1 fails for kernel 3.18.9-hardened with the following (relevant part) of the ebuild-log: [...] implicit declaration of function ‘smp_mb__after_clear_bit’ [-Werror=implicit-function-declaration] smp_mb__after_clear_bit(); ^ cc1: some warnings being treated as errors scripts/Makefile.build:257: recipe for target '/var/tmp/portage/net-misc/dahdi-2.10.0.1/work/dahdi-linux-2.10.0.1/drivers/dahdi/wcte13xp-base.o' failed make[2]: *** [/var/tmp/portage/net-misc/dahdi-2.10.0.1/work/dahdi-linux-2.10.0.1/drivers/dahdi/wcte13xp-base.o] Error 1 Makefile:1459: recipe for target '_module_/var/tmp/portage/net-misc/dahdi-2.10.0.1/work/dahdi-linux-2.10.0.1/drivers/dahdi' failed make[1]: *** [_module_/var/tmp/portage/net-misc/dahdi-2.10.0.1/work/dahdi-linux-2.10.0.1/drivers/dahdi] Error 2 make[1]: Leaving directory '/usr/src/linux-3.18.9-hardened' Makefile:74: recipe for target 'modules' failed make: *** [modules] Error 2 * ERROR: net-misc/dahdi-2.10.0.1::gentoo failed (compile phase): * emake failed" [...] According to my research, this is due to the fact that the function "smp_mb__after_clear_bit" is deprecated in favour of "smp_mb__before_atomic". Up to kernel 3.17 there was an inline wrapper defined in linux/bitops.h: #ifndef smp_mb__after_clear_bit static inline void __deprecated smp_mb__after_clear_bit(void) { extern void __smp_mb__after_atomic(void); __smp_mb__after_atomic(); } #endif This wrapper appears to be no longer available under kernel 3.18 thus resulting in the above error message. Fixing this should be pretty easy by just replacing every occurrence of "smp_mb__before_clear_bit" with the new "smp_mb__before_atomic" call. A quick grep in the source showed that this is function is called from the following four source files: ./dahdi-linux-2.10.0.1/drivers/dahdi/wcte12xp/base.c ./dahdi-linux-2.10.0.1/drivers/dahdi/wcaxx-base.c ./dahdi-linux-2.10.0.1/drivers/dahdi/wcte13xp-base.c ./dahdi-linux-2.10.0.1/drivers/dahdi/wcte43x-base.c Thanks Atom2
(In reply to KK from comment #0) The penultimate paragraph should actually read: Fixing this should be pretty easy by just replacing every occurrence of "smp_mb__after_clear_bit" with the new "smp_mb__after_atomic" call. A quick grep in the source showed that this is function is called from the following four source files: In other words: s/__before_/__after_/g Sorry for any confusion caused.
Created attachment 399976 [details, diff] dahdi patch for kernel 3.18
Just drop the attached patch file into the folder /etc/portage/patches/net-misc/dahdi (create it if neccessary) and (re)emerge dahdi. The patch files' name can be choosen arbitrarily as long as it ends in .patch. After that dahdi emerges without any issues. Regards KK
Have you reported this upstream at issues.asterisk.org as well please?
(In reply to Tony Vroon from comment #4) > Have you reported this upstream at issues.asterisk.org as well please? I do not have an account at issues.asterisk.org and a simple search there for "smp_mb__after_atomic" or "smp_mb__after_clear_bit" (as a guest) did not reveal anything. However, googling for "smp_mb__after_clear_bit dahdi" brought up http://lists.digium.com/pipermail/dahdi-commits/2014-October/004011.html as the first hit which seems to resolve the issue identical to my suggestion (i.e. by replacing "smp_mb__after_clear_bit()" with "smp_mb__after_atomic()") and its comments even contain a reference to kernel 3.18. The commit details are as follows: commit 378986841cbf7c94e43dc34580def06088116652 Author: Shaun Ruffell <sruffell at digium.com> Date: Thu Oct 16 18:41:27 2014 -0500 The resolution of the problem is identical to what I have proposed; in addition to this there are a few more changes in that link which may or may not be related to the error I have observed. To me this indicates that the guys at digium are aware of the issue and have already taken appropriate action. I was not able to figure out if there was a new (point) release for dahdi including these changes or when this will be merged and released. Thanks KK
It looks like version 2.10.1 carries this commit. Could you please confirm that temporarily adding this to /etc/portage/package.keywords helps: =net-misc/dahdi-2.10.1 If it does I will ask for it to be stabilised.
Excuse delay; a confirmation just arrived from Bobby Hakimi that the new version is functional. Arches, please test & mark stable: =net-misc/dahdi-2.10.1 Test plan: 1) compile 2) /etc/init.d/dahdi-autoconf start 3) /etc/init.d/dahdi start 4) lsmod (confirm "dahdi" listed) 5) /etc/init.d/dahdi stop 6) /etc/init.d/dahdi-autoconf stop 7) lsmod (confirm "dahdi" no longer listed) For bonus points run test plan steps 2 to 7 a second time and confirm no panic or kernel taint has occurred.
Should net-misc/dahdi-tools-2.10.1 be stabilized with this too?
That makes sense, yes. In which case I will invalidate that bug and add it here.
*** Bug 535596 has been marked as a duplicate of this bug. ***
Arches, please test & mark stable: =net-misc/dahdi-2.10.1 =net-misc/dahdi-tools-2.10.1 Test plan: 1) compile 2) /etc/init.d/dahdi-autoconf start 3) /etc/init.d/dahdi start 4) lsmod (confirm "dahdi" listed) 5) /etc/init.d/dahdi stop 6) /etc/init.d/dahdi-autoconf stop 7) lsmod (confirm "dahdi" no longer listed) For bonus points run test plan steps 2 to 7 a second time and confirm no panic or kernel taint has occurred.
amd64 stable
x86 stable. Closing.
