A check for CONFIG_PREEPMT_RCU that was added to the ati-drivers ebuilds circa May 2008 (and carried forward since then) causes ati-drivers to fail to build against 2.6.37. FWIW this kernel option is absent from 2.6.36; sphinx src # grep PREEMPT_RCU linux-2.6.36-gentoo-r5/.config CONFIG_TREE_PREEMPT_RCU=y sphinx src # grep PREEMPT_RCU linux-2.6.37-gentoo/.config CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y sphinx src # I guess ati-drivers started supporting PREEMPT_RCU at some stage (at least 10.11 does) so the check is cruft. Reproducible: Always Steps to Reproduce: 1. Unmask ati-drivers so 10.11 is used 2. Install gentoo-sources-2.6.37 and set /usr/src/linux symlink 3. # emerge ati-drivers Actual Results: * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.37-gentoo/build * Found sources for kernel version: * 2.6.37-gentoo * ati-drivers-10.11 is incompatible with RCU preemption (bug #223281). * Please disable it: * CONFIG_PREEMT_RCU=n * in /usr/src/linux/.config or * Processor type and features ---> * [ ] Preemptible RCU * in the 'menuconfig' * ERROR: x11-drivers/ati-drivers-10.11 failed: * CONFIG_PREEMT_RCU enabled Expected Results: Not to get the Preemptible error - i actually dont know if ati support 2.6.37, so i dont know if this should work or fail in some other manner. Also - the P is missing in the warning! ie PREEMT should be PREEMPT
Additional Note: its not possible to disable PREEMPT_RCU in 2.6.37
Apparently in #349375, the plan is to remove the check for ati-drivers-10.12.
(In reply to comment #1) > Additional Note: its not possible to disable PREEMPT_RCU in 2.6.37 > It is if you set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set which translates to Processor type and features ---> Preemption Model (Voluntary Kernel Preemption (Desktop)) It still doesn't build on my system: CC [M] /var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.o /var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:410:5: error: unknown field ‘ioctl’ specified in initializer /var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:410:5: warning: initialization from incompatible pointer type /var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function ‘KAS_Mutex_Initialize’: /var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:5099:5: error: implicit declaration of function ‘init_MUTEX’ make[2]: *** [/var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [_module_/var/tmp/portage/x11-drivers/ati-drivers-10.11/work/common/lib/modules/fglrx/build_mod/2.6.x] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.37-gentoo' make: *** [kmod_build] Error 2 emake failed but I don't know if thats related or not.
Maybe this is how to make links: bug #349375 ? (In reply to comment #3) > It is if you set > # CONFIG_PREEMPT_NONE is not set > CONFIG_PREEMPT_VOLUNTARY=y > # CONFIG_PREEMPT is not set > which translates to > Processor type and features ---> > Preemption Model (Voluntary Kernel Preemption (Desktop)) > > It still doesn't build on my system: ... > but I don't know if thats related or not. 1) I don't know what the first error is, but the second on line 5099 is a difference between 2.6.37 and previous kernels; it's been cropping up a lot. 2) I think you should be leaving preemption on unless you are nostalgic about Linux-2.4 where only one task can be making a system call at any one time. I'm not sure how noticeable it is, but it is a waste.
Oh, I see, CONFIG_PREEMPT_VOLUNTARY is sort of a middle ground choice. Well I expect that, eventually, CONFIG_PREEMPT will be the only choice. I'm not even sure what the CONFIG_PREEMPT_RCU conflict is about. I would imagine that AMD has fixed the conflict since May 2008; their drivers don't seem to check for it themselves, so they likely would have noticed the bug and resolved it.
also noting: not only does it have a spelling error in the name of the kernel component but it ALSO is in the wrong place. the actual location is: General setup ---> RCU Subsystem---> ... however; as comment #1 states, it is, indeed, not able to be disabled (nor should it have to be, as other comments have pointed out). i'm adding =sys-kernel/gentoo-sources-2.6.37 to my /etc/portage/package.mask for now until i hear if this is resolved or, hopefully, sys-kernel/gentoo-sources-2.6.37-r# will resolve and be in the tree shortly. :)
(In reply to comment #6) > however; as comment #1 states, it is, indeed, not able to be disabled see comment #6 If you can live with --- CONFIG_PREEMPT_VOLUNTARY: This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions, at the cost of slightly lower throughput. This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is under load. Select this if you are building a kernel for a desktop system. --- instead of --- CONFIG_PREEMPT: This option reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. This allows reaction to interactive events by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This allows applications to run more 'smoothly' even when the system is under load, at the cost of slightly lower throughput and a slight runtime overhead to kernel code. Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range. --- you can disable CONFIG_PREEMPT_RCU.
(In reply to comment #7) comment #3 not comment #6 sorry.
ati-drivers-10.12 (ebuild does not contain the PREEMPT_RCU check) works fine for me with 2.6.37 and PREEMPT_RCU enabled.
(In reply to comment #9) > ati-drivers-10.12 (ebuild does not contain the PREEMPT_RCU check) works fine > for me with 2.6.37 and PREEMPT_RCU enabled. > would you be able to post your .config for us less fortunate ones so we can diff and investigate some other possible causes?
Created attachment 259591 [details] As requested .config
> would you be able to post your .config for us less fortunate ones so we can > diff and investigate some other possible causes? I have attached my .config, but if your issue isn't about PREEMPT_RCU then you should probably raise a new bug.
(In reply to comment #12) > > would you be able to post your .config for us less fortunate ones so we can > > diff and investigate some other possible causes? > > I have attached my .config, but if your issue isn't about PREEMPT_RCU then you > should probably raise a new bug. > understood; i'm getting the same errror displayed; i can only assume it's PREEMPT_RCU but as others said, the option for disabling it doesn't exist and it worked fine in previous versions, so i'm curious if there'd be any related configuration that would throw the same message that may have nothing to do with PREEMPT_RCU
(In reply to comment #13) > understood; i'm getting the same errror displayed; On 10.12? Maybe there's been a change without a version bump - see if your md5 matches this; $ md5sum ati-drivers-10.12.ebuild d8f3aae20e3f5fb032292c6c21169057 ati-drivers-10.12.ebuild > i can only assume it's > PREEMPT_RCU but as others said, the option for disabling it doesn't exist and > it worked fine in previous versions, That's because that particular option name has not been used for a while and has now been re-used. Since the preemption option name was different in earlier kernels, the ebuild check didnt get hit so the driver were built successfully with the RCU preemption function - it was just called a different option in .config. AFAICT at least.
(In reply to comment #14) > $ md5sum ati-drivers-10.12.ebuild > d8f3aae20e3f5fb032292c6c21169057 ati-drivers-10.12.ebuild zsh 4357 # ls -la ati-drivers-10.12.ebuild;md5sum ati-drivers-10.12.ebuild;echo "d8f3aae20e3f5fb032292c6c21169057" -rw-r--r-- 1 root root 19862 Jan 9 19:31 ati-drivers-10.12.ebuild d8f3aae20e3f5fb032292c6c21169057 ati-drivers-10.12.ebuild d8f3aae20e3f5fb032292c6c21169057 no version bump that i see
(In reply to comment #15) > no version bump that i see You are trying to build ati-drivers-10.12, not a previous version, correct? I'm not sure if it needs to be unmasked or what.
(In reply to comment #14) > (In reply to comment #13) daggum it. nevermind. i was using an old .config with CONFIG_PREEMPT (which, as you alluded to, actually maps to: -> Processor type and Features -> Preemption Model -> (X) Preemptible Kernel (Low-Latency Desktop) i switched to Voluntary Kernel Preemption (Desktop) (right above it) and it compiles fine. I apologise for the confusion! I believe this is the default for stock configs on x86 and x86_64 so this should only be an issue if it's been changed. sorry for the confusion. :)
Ok,because I can't read 17 comments to understand what is going on here, can someone tell me, is this fixed with x11-drivers/ati-drivers-10.12? I resolve this as TEST-REQUEST. Please reopen only if the problem persists even with x11-drivers/ati-drivers-10.12. Thank you for your report.
(In reply to comment #18) > Ok,because I can't read 17 comments to understand what is going on here, can > someone tell me, is this fixed with x11-drivers/ati-drivers-10.12? Yes, its fixed in 10.12.
