This was a vesafb bug in vanilla 2.6.9 that was corrected with vanilla 2.6.10. ref: this part of the vanilla 2.6.10 ChangeLog: --------------------- <adaplas@hotpop.com> [PATCH] fbdev: fix framebuffer memory calculation for vesafb - use vesafb_fix.line_length * vesafb_defined.yres to calculate the minimum memory required for a video mode. From Aurelien Jacobs <aurel@gnuage.org>. - separately calculate the memory required for a video mode, memory to be remapped, and total memory (for MTRR). From Gerd Knorr <kraxel@bytesex.org>. - the 'vram' option is for memory to be remapped, not total memory. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> --------------------------------------------------------------------------- The fix that was folded into vanilla 2.6.10 needs to be reproduced similarly for vesafb-tng. The workaround when using vesafb-tng is to delete the bogus mtrr segment and re-create a correctly sized one manually, e.g. ----/etc/conf.d/local.start------- echo " --> Correcting mtrr video segment ... " echo "disable=2" >| /proc/mtrr echo "base=0xf0000000 size=0x2000000 type=write-combining" >| /proc/mtrr ---end---- The above example would be for a 32M vid card whose base video mem address is 0xf0000000. See /usr/src/linux/Documentation/mtrr.txt. This problem will cause other issues, such as write-combining errors when X. It's also _possibly_ the cause of bug# 69676. Reproducible: Always Steps to Reproduce: 1. reboot and cat /proc/mtrr to observe incorrectly sized video mem segment 2. 3. Expected Results: correctly calculated total video memory size when creating mtrr segment Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r2 i686) ================================================================= System uname: 2.6.10-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://gentoo.mirrors.pair.com http://gentoo.ccccom.com" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X aalib alsa avi bitmap-fonts cdr cups divx4linux dvd dvdr encode gpm gtk2 imlib java jpeg mad mikmod mmx mpeg ncurses nls nptl oggvorbis opengl oss png python readline sdl slang sse sse2 ssl tcpd truetype xml2 xprint xv xvid zlib"
The problem is fixed in g-d-s-2.6.10-r5.
