The make.sh script in the build_mod/ directory of the fglrx package assumes that if "fgrep -c smp /proc/kallsyms" has greater than 10 hits then the kernel is compiled for SMP. However, with APIC enabled in a 2.6 kernel, the actual number of SMP symbols is between 15 and 20 even with SMP disabled. This causes the module to get compiled with SMP enabled, and causes problems with visual artifacts (such as in SPECviewperf as described in the forum link above). This could be the cause of various lock-ups people are having as well. Reproducible: Always Steps to Reproduce: 1. ebuild ati-drivers-3.14.6.ebuild compile 2. in the work directory, view the make.log file that make.sh generates Actual Results: notice that SMP=1 even if SMP is disabled in the kernel (but APIC is enabled). Expected Results: SMP should be off (SMP=0 in make.log file) if the kernel does not truly have SMP enabled. That is CONFIG_SMP=y in /usr/src/linux/.config.
Created attachment 44618 [details, diff] Patch to correct make.sh so that it does not enable SMP on non-SMP systems This is a simple patch to change the number of "smp" matches needed to enable SMP in the fglrx module from 10 to 20. This should be enough for all current kernels. Systems with SMP enabled should have more than 40 smp symbols in /proc/kallsyms. Also since this patch only touches the /proc/kallsyms logic, it is safe for 2.4 kernels since they do not have the /proc/kallsyms file.
The ebuild should use directly the 2.6 makefile and not use the bash script. How's possible you get make.sh called?
My mistake... I read the if "[ ${KV} != ${KV/2\.6} ]" comparison the wrong way, so I thought that make.sh would be run for 2.6 kernels. However, now this makes me wonder if __SMP__ is defined correctly for SMP machines. It seems that __SMP__ is never defined or used when building a 2.6 kernel (even if using the make.sh script).... is this an ATI script bug, or should it really not be ever defined for 2.6 kernels?
Created attachment 45668 [details, diff] Patch to correct __SMP__ in firegl_public.c with the respect to a kernel CONFIG_SMP
I installed ati-drivers 3.14.6 on 2.6 smp kernel and then saw the /var/log/XFree86.0.log (II) fglrx(0): Kernel Module Build Time Information: (II) fglrx(0): Build-Kernel UTS_RELEASE: 2.6.9-gentoo-r9-smp (II) fglrx(0): Build-Kernel MODVERSIONS: no (II) fglrx(0): Build-Kernel __SMP__: no (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000 __SMP__ option was wrong, even if /usr/src/linux/.config had a CONFIG_SMP=y. OpenGL test application glxgears didn't work longer ther 10-15 seconds. I changed file /var/tmp/portage/ati-drivers-3.14.6/work/lib/modules/fglrx/build_mod/firegl_public.c to check CONFIG_SMP kernel define and then define the __SMP__ properly. Patch is attached.
Maybe this patch should also #undef __SMP__ in an #else clause? That way it will be defined (or undefined) correctly regardless of the script.
is the issue still valid?
ati-drivers-8.8.25-r3 also does not set __SMP__ on smp 2.6 kernels. Vadym's patch corrects this. (Also, is ati-drivers-8.8.25-r3 installs glxATI.h into /usr/include/include/GL - I think this should be /usr/include/GL)
fixed in the latest ebuild
I hope adding to this bug is OK even though its old, but... I am having this problem on an SMP kernel with x11-drivers/ati-drivers-8.25.18. In Xorg.0.log I get: (II) fglrx(0): Kernel Module Version Information: (II) fglrx(0): Name: fglrx (II) fglrx(0): Version: 8.25.18 (II) fglrx(0): Date: May 18 2006 (II) fglrx(0): Desc: ATI FireGL DRM kernel module (II) fglrx(0): Kernel Module version matches driver. (II) fglrx(0): Kernel Module Build Time Information: (II) fglrx(0): Build-Kernel UTS_RELEASE: 2.6.16-suspend2-r6 (II) fglrx(0): Build-Kernel MODVERSIONS: no (II) fglrx(0): Build-Kernel __SMP__: no (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000 If I use the make.sh from ATI I get: (II) fglrx(0): Kernel Module Version Information: (II) fglrx(0): Name: fglrx (II) fglrx(0): Version: 8.25.18 (II) fglrx(0): Date: May 18 2006 (II) fglrx(0): Desc: ATI FireGL DRM kernel module (II) fglrx(0): Kernel Module version matches driver. (II) fglrx(0): Kernel Module Build Time Information: (II) fglrx(0): Build-Kernel UTS_RELEASE: 2.6.16-suspend2-r6 (II) fglrx(0): Build-Kernel MODVERSIONS: yes (II) fglrx(0): Build-Kernel __SMP__: yes (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000 Notice MODVERSIONS and __SMP__ are both "yes" in the later case, matching my kernel. This is causing problems. Using suspend2 I have very few problems when __SMP__ is "yes", I have got up to 14 cycles. With __SMP__ "no" 3 is doing good before it crashes on the atomic copy. I am not sure of possible other problems related to this. If you want me to file a new bug I will.
Submitted bug 137745 due to silence and age of this one :)
