The drivers still contain references to verify_area which was replaced by access_ok, resulting in unknown symbol errors. Merely by replacing the occurences by access_ok makes them compile and work fine on my system. This worked for me (using the drivers in the original installer from ati): diff -urp ati-driver-original/common/lib/modules/fglrx/build_mod/drm_os_linux.h ati-driver/common/lib/modules/fglrx/build_mod/drm_os_linux.h --- ati-driver-original/common/lib/modules/fglrx/build_mod/drm_os_linux.h 2005-10-11 20:42:31.000000000 +0300 +++ ati-driver/common/lib/modules/fglrx/build_mod/drm_os_linux.h 2005-10-16 18:44:46.000000000 +0300 @@ -75,7 +75,7 @@ typedef void irqreturn_t; copy_to_user(arg1, arg2, arg3) /* Macros for copyfrom user, but checking readability only once */ #define DRM_VERIFYAREA_READ( uaddr, size ) \ - verify_area( VERIFY_READ, uaddr, size ) + access_ok( VERIFY_READ, uaddr, size ) #define DRM_COPY_FROM_USER_UNCHECKED(arg1, arg2, arg3) \ __copy_from_user(arg1, arg2, arg3) #define DRM_COPY_TO_USER_UNCHECKED(arg1, arg2, arg3) \ diff -urp ati-driver-original/common/lib/modules/fglrx/build_mod/firegl_public.c ati-driver/common/lib/modules/fglrx/build_mod/firegl_public.c --- ati-driver-original/common/lib/modules/fglrx/build_mod/firegl_public.c 2005-10-11 20:42:31.000000000 +0300 +++ ati-driver/common/lib/modules/fglrx/build_mod/firegl_public.c 2005-10-16 18:44:16.000000000 +0300 @@ -1473,9 +1473,9 @@ int ATI_API_CALL __ke_copy_to_user(void* return copy_to_user(to, from, size); } -int ATI_API_CALL __ke_verify_area(int type, const void * addr, unsigned long size) +int ATI_API_CALL __ke_access_ok(int type, const void * addr, unsigned long size) { - return verify_area(type, addr, size); + return access_ok(type, addr, size); } int ATI_API_CALL __ke_get_pci_device_info(__ke_pci_dev_t* dev, __ke_pci_device_info_t *pinfo) diff -urp ati-driver-original/common/lib/modules/fglrx/build_mod/firegl_public.h ati-driver/common/lib/modules/fglrx/build_mod/firegl_public.h --- ati-driver-original/common/lib/modules/fglrx/build_mod/firegl_public.h 2005-10-11 20:42:31.000000000 +0300 +++ ati-driver/common/lib/modules/fglrx/build_mod/firegl_public.h 2005-10-16 18:45:09.000000000 +0300 @@ -400,7 +400,7 @@ extern unsigned long ATI_API_CALL __ke_r extern int ATI_API_CALL __ke_copy_from_user(void* to, const void* from, __ke_size_t size); extern int ATI_API_CALL __ke_copy_to_user(void* to, const void* from, __ke_size_t size); -extern int ATI_API_CALL __ke_verify_area(int type, const void * addr, unsigned long size); +extern int ATI_API_CALL __ke_access_ok(int type, const void * addr, unsigned long size); extern void* ATI_API_CALL __ke_malloc(__ke_size_t size); extern void ATI_API_CALL __ke_free_s(void* p, __ke_size_t size);
Created attachment 70803 [details, diff] Patch that fixes original driver distribution
I'll add a sed line to fix the problem soon
sed line added, please test
It seems to work great here, thanks!
Nice, it works correctly also with the .13
undefines symbols register_ioctl32_conversion and unregister_ioctl32_conversion using 2.6.14 final ... will provide emerge info later luca you know how to find me.
seems to be related to x86_64 only as that is only ifdefine I can find that even call for the ioctl32.
I can confirm the same issues on amd64 with register_ioctl32_conversion and unregister_ioctl32_conversion. These errors are thrown when inserting fglrx into the kernel, and insertion then fails. Those are the only two errors I saw in dmesg though. This was using ati-drivers-8.18.8 and gentoo-sources-2.6.14. Portage 2.0.53_rc6 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.5.20050722-r0, 2.6.14-gentoo x86_64) ================================================================= System uname: 2.6.14-gentoo x86_64 AMD Turion(tm) 64 Mobile Technology ML-37 Gentoo Base System version 1.12.0_pre9 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg digest distlocks sandbox sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/sci" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac aalib aim alsa ati audiofile avi bash-completion berkdb bitmap-fonts bootsplash bzlib cdparanoia cdr crypt cscope cups curl dbus directfb doc dri dvd dvdr dvdread eds emboss encode esd ethereal fam fbcon fftw foomaticdb fortran gd gdbm gif gimpprint gmp gphoto2 gpm gstreamer hal icq ieee1394 imagemagick imap imlib ipv6 jabber java jikes jpeg jpeg2k kde kdeenablefinal kerberos lcms libwww lm_sensors lzw lzw-tiff mad madwifi motif mp3 mpeg ncurses netcdf nls nptl nptlonly odbc offensive ogg oggvorbis openexr opengl pam pcre pdflib perl plotutils png povray python qt quicktime readline rtc samba sasl scanner sdl speedo spell sqlite ssl subversion svg tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales videos vorbis wmf xine xinerama xml2 xpm xv xvid zeroconf zlib linguas_en_GB userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS
had ment to change OS to amd64 early as x86 is not effected by this current issue!
Can include this patch into the ebuild?
the access_ok issue is more or less solved (I should check in the ati solution since looks a bit more cleaner) the register/unregister_ioctl32 on the other hand...
I may try to noop those calls. They could be removed since now the ioctl compatibility layer is explicitly exported using compat_ioctl. The problem is that I'm not sure what I should pass to it.
*** Bug 111200 has been marked as a duplicate of this bug. ***
*** Bug 111246 has been marked as a duplicate of this bug. ***
http://ati.cchtml.com/show_bug.cgi?id=211
*** Bug 113565 has been marked as a duplicate of this bug. ***
