I have updated to the newest available gentoo sources (2.6.16-gentoo-r7) First i had gentoo-sources 2.6.16-gentoo-r6 and no problem. Then i updated them with "emerge -uav gentoo-sources" to r7. The Symlink was set up correct and i tried to compile a new kernel. I realized that there was no more /gentoo-sources-2.6.16-gentoo-r6 folder in /usr/src. Did i something wrong at that time? Then i did makemenuconfig and set up my configuration. Then is did "make && make modules_install" After a very short time i get an error. Screen output looks like this: LD .tmp_vmlinux1 drivers/built-in.o.data+0x7dd8): undefined reference to 'cfb_fillrect' and 3 other errors that look the same. I have to mention that i upgraded gcc from 3.36 to 3.4.5 following the gcc upgrading guide for a first (fresh) install (that my system probably is). I thought i would have messed up anythong and reinstalle gentoo completely but the error still remains. I then disabled the framebuffer support because the error message seemed to me like a code synatx error (maybe in the driver code???) for some graphics application (... fillrect). Now my kernel compiles without any problem. Besides this, the problem would still occur when enabling framebuffer device support or enabling it as a module. Emerge --info: Portage 2.0.54-r2 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.16-gentoo-r7 x86_64) ================================================================= System uname: 2.6.16-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 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-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="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/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ " LINGUAS="en de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X alsa audiofile avi berkdb bitmap-fonts bzip2 cdr cli crypt cups dri dvd dvdr eds emboss encode expat fam foomaticdb fortran gif gmp gpm gstreamer gtk2 hal idn imlib ipv6 isdnlog jpeg kde kdeenablefinal lcms lzw lzw-tiff mad mng mp3 mpeg ncurses nls nptl opengl pam pcre pdflib perl png pppd python qt quicktime readline reflection sdl session spell spl ssl symlink tcpd tiff truetype truetype-fonts type1-fonts udev usb xml2 xorg xpm xv zlib linguas_en linguas_de userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS, PORTDIR_OVERLAY
Created attachment 88472 [details] Kernel .config
Michal, What is the future of vesafb-tng? Can any of it be fed back into vesafb? Is it ever going to work on non-x86? For now, can we at least separate the options for vesafb/vesafbtng and make them block each other? i.e. config FB_VESA bool "vesafb" depends on (FB = y) && X86 && !FB_VESA_TNG config FB_VESA_TNG tristate "vesafb-tng" depends on (FB = y) && X86 && !FB_VESA That way we can avoid this bug, right? Johannes: The solution right now is not to build vesafb as a module. In an unpatched kernel you would not have the option of selecting it as a module.
*** Bug 135166 has been marked as a duplicate of this bug. ***
Daniel, I've just released a new patch [1], which should fix the problem this bug is about. I decided not to separate the option to avoid confusion among the users and further problems with the Kconfig system (your solution would be the best way to go, unfortunately, the Kconfig scripts complain: "Warning! Found recursive dependency: FB_VESA FB_VESA_TNG FB_VESA", and the interface behaves strangely). vesafb can still be selected as a module, but in this case it will simply be built into the kernel as usual. Wrt the future of vesafb-tng -- it's unlikely any code can be moved to vesafb. The way to go (and this seems to be both my own opinion and the opinion of the fb developers) is to have the vm86 code separated into an userspace application (which will also make it possible for the driver to work on non-x86, since x86emu can be used in place of vm86). I'm going to work on this during the summer, but I wouldn't want to set any deadlines or promise completion dates just yet :) [1] http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-1.0-rc2-git-20060629.patch
Fixed in gentoo-sources-2.6.17-r1 / genpatches-2.6.17-1
