Well, after making lots of tests, it seems that neither vesafb nor vesafb-tng work correctly in kernel 2.6.9. I have removed the vga= from the kernel boot options and added it as follows: video=vesafb:ywrap,mtrr,1280x1024-32@75 I have also tried video=vesafb:ywrap,1024x768@75, changing yrawp with ypan, removing mtrr,... nothing seems to work. It always gets into a 640x480 framebuffer. I have also tried setting the vesafb-tng default resolution into the kernel. Doesn't work either. The only driver that did work was radeonfb... which does work perfectly, except when using X... after exiting X or switching from X to a terminal, the system crashes. So after all those tests and seeing that radeonfb works perfectly with the same parameters, I have concluded that vesafb and vesafb-tng could be broken. Please, also check my system settings: gcc3.4, flags, etc. Reproducible: Always Steps to Reproduce: Portage 2.0.51 (gcc34-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20041006-r0, 2.6.9-gentoo i686) ================================================================= System uname: 2.6.9-gentoo i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.5.3 distcc 2.18 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=i586 -mtune=i686 -ftracer -fomit-frame-pointer -ffast-math -pipe -fforce-addr -fforce-mem -falign-functions=4" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=i586 -mtune=i686 -ftracer -fomit-frame-pointer -ffast-math -pipe -fforce-addr -fforce-mem -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distlocks fixpackages sandbox usersandbox" GENTOO_MIRRORS="http://ftp.caliu.info/pub/gentoo/ http://mirror.switch.ch/mirror/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi acpi4linux alsa apache2 apm arts audiofile avi berkdb bitmap-fonts blender-game bluetooth bootsplash bzlib c++ caps cddb cdinstall cdparanoia cdr cdrom chroot clamav clanVoice codecs crypt cups curl dga dio directfb divx4linux dvd dvdr encode erandom esd ethereal f77 fastcgi fbcon flac flash foomaticdb freetype gd gdbm ggi gif gimp gimpprint gmp gnome gphoto2 gpm gstreamer gtk gtk2 icq imagemagick imlib ipv6 java jikes jpeg junit kde lcms ldap libg++ libwww mad memlimit mikmod mmx motif mozilla mpeg msn mysql ncurses nls nocd nptl oggvorbis opengl oss pam pdflib perl pic png ppds python qt quicktime readline samba sdl session slang spell ssl svg svga szip tcltk tcpd tetex tiff truetype ttf unicode usb videos wmf x86 xml xml2 xmms xprint xv xvid zlib linguas_es linguas_el"
Spock has updated his patches http://dev.gentoo.org/~spock/
If that is correct, hope to have soon release 2.6.9-gentoo-r1 with the new patches commited to CVS.
Update: 2.6.9-gentoo and 2.6.9-gentoo-r1 have buggy vesafb/vesafb-tng Using 2.6.9-ck1 doesn't bring any problem. About the system crash after exiting X or switching from X to a terminal, that's an ati-drivers bug for what I've seen. Disabling this driver solves the issue at the cost of losing 3D acceleration, which is not tolerable.
*** Bug 70147 has been marked as a duplicate of this bug. ***
i have experienced the same problem with 2.6.9-r3 with both vesafb and vesafb-tng. i am always dumped into the 640x480 framebuffer.
Michal has attempted to fix this bug.. could someone test it? You'll need to grab 2.6.10-rc1, patch it with a nightly -bk patch and then apply the vesafb-tng for 2.6.10-rc1-bk11 from his site: http://dev.gentoo.org/~spock If it works, maybe we can backport it to fix up 2.6.9
I would rather suggest to go directly into a 2.6.10 kernel... which is the poing of view of kernel developers about leaving behind the 2.6.9 kernel?
Sorry, I don't understand what you just posted. To clarify, what I mean is that I would like you to test spocks new patch just to see if it fixes the issue. We've had no feedback about it.
Let me explain myself: it's time to forget kernel 2.6.9 and mark 2.6.10 as stable and do all tests there... I'll try tonight to do what you requested.
i can't volunteer for testing, because on my dell machine, 2.6.9-r3 will not turn on the APIC. i think that many of my problems may be a result of that. until that bug gets resolved, lots of things are likely to remain broken.
Ioannis: 2.6.10 is not final, infact it is still only in early development. There's not a chance that we'd mark it stable in its current form. Please read my earlier post again: spock has (hopefully) fixed this in the form of a patch that applies the development kernel (2.6.10 tree). We cannot reproduce the issue and we have had no feedback, so we don't know if it fixes the problem or not. If someone was to test it and said that it solves the issue, maybe we would backport it to 2.6.9 and fix gentoo-dev-sources. If you want to help fix this bug, please *test out* 2.6.10 with spocks patch (we are only interested if the new vesafb-tng driver fixes the issue described in this bug, not how well 2.6.10 runs.) B. Predaina: If you have been unable to run 2.6.9, how do you know you experience this vesafb-tng bug? And please don't bring multiple issues onto the same bug (your APIC issue is infact not a bug, Dell Bios's ask Linux to disable APIC, you may wish to investigate the 'lapic' boot param)
Spock, you own all vesafb-tng bugs :)
I'm currently trying to test this out... you'll have a report soon :)
I have patched: kernel: linux-2.6.10-rc1 with: patch-2.6.10-rc1-bk21 successfully. Afterwards, I patch it with: vesafb-tng-0.9-rc4-r3-2.6.10-rc1.patch and it fails: patching file Documentation/fb/vesafb.txt patching file arch/i386/boot/video.S patching file drivers/video/Kconfig patching file drivers/video/Makefile Hunk #1 succeeded at 96 (offset 5 lines). patching file drivers/video/fbmem.c Hunk #1 FAILED at 51. Hunk #2 succeeded at 1165 (offset -142 lines). 1 out of 2 hunks FAILED -- saving rejects to file drivers/video/fbmem.c.rej patching file drivers/video/vesafb-thread.c patching file drivers/video/vesafb-tng.c patching file include/video/vesa.h Rejects of fbmem.c.rej: *************** *** 51,56 **** * Frame buffer device initialization and setup routines */ #define FBPIXMAPSIZE 16384 static struct notifier_block *fb_notifier_list; --- 51,58 ---- * Frame buffer device initialization and setup routines */ + extern int vesafb_init_thread(void); + #define FBPIXMAPSIZE 16384 static struct notifier_block *fb_notifier_list; I'll proceed anyway, just in case but, check it out!
Please use either a plain .10-rc1 kernel and patch it with http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-0.9-rc5-2.6.10-rc1.patch or use a -bk patched kernel, and patch it with http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-0.9-rc5-2.6.10-rc1-bk11.patch. The first option will probably bring less troubles if you were to ask me :)
I already compiled with the -bk one, although the hunk error. Rebooting to check whether it works. Will fall back to the other option if errors are found.
Guys, I regret to inform you that none of the proposals worked. It always falls back to 640x480. Tough luck.
A few questions/things to test: 1) What was the last kernel version vesafb(-tng) worked for you? 2) When testing the kernel with the standard vesafb driver, you're using the vga= parameter, right? 3) Try emerging development-sources. Don't patch it with anything. Just compile the kernel and try using it with vesafb (vga=). Does that get you into 640x480 as well? If yes, what mode number are you using?
>1) What was the last kernel version vesafb(-tng) worked for you? -The last one that worked with vesafb/vesafb-tng was linux-2.6.8-gentoo-rX >2) When testing the kernel with the standard vesafb driver, you're using the vga= parameter, right? -I have tried all ways, using it and not using it, both vesafb and vesafb-tgn >3) Try emerging development-sources. Don't patch it with anything. Just compile the kernel and try using it with vesafb (vga=). Does that get you into 640x480 as well? If yes, what mode number are you using? -No, using the vanilla sources, AFAI remember did work well without patch, but I'm not completely sure. I'll try that again and report it here. The mothe number that corresponds to 1280x1024-32, that is 0x31B (795)
I have compiled version 2.9.10-rc1-bk21 with patch from Spock. It works for me. Anyway now I cannot use kernel versions 2.6.9 and above, because keyboard and touchpad are not working under xorg. (the PS/2 mouns is working and that is all).
I have also experienced this problem, exactly as Ioannis described, and would like to help with any testing. I am new to gentoo, but have used various other distros over the years. I have tried 2.6.9-r6 2.6.10-rc1 2.6.10-rc2 to no avail. I am using a dell inspiron 8600 with nvidia 5650. currently, using 2.6.9 with standard vesafb enabled, "dmesg | grep vesafb" reports vesafb: probe of vesafb0 failed with error -6 regards, Andrew
Andrew: this bug regards vesafb-tng, not vesafb.
I posted the vesafb error since I thought it might have some bearing on the problem. This is the output from "dmesg | grep vesafb" while running 2.6.9 with vesafb-tng Kernel command line: root=/dev/hda5 video=vesafb:1024x768-8@60 vesafb: NVIDIA Corporation, NV31 Board - p136nz , Chip Rev (OEM: NVIDIA) vesafb: VBE version: 3.0 vesafb: protected mode interface info at c000:e560 vesafb: pmi: set display start = c00ce596, set palette = c00ce600 vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da vesafb: hardware doesn't support DCC transfers vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz vesafb: scrolling: redraw vesafb: framebuffer at 0xd0000000, mapped to 0xe0880000, size 16384k I noted the line concerning the monitor limits, and attempted to override them on the kernel commandline. Although they were updated in dmesg, it had no other effect. Andrew
vesafb doesn't accept resolution/depth/refresh like that. You have to use the appropriate vga=0x... value.
Is there anyone for whom this still is a problem with gentoo-dev-sources-2.6.10?
Yes I have. I have tryed with new notebook, with radeon mobility M11 with display 1680x1050. The FB screen freeze during boot at the moment of change of resolution. In logbook I have found this: vesafb: ATI Technologies Inc.,P11, 01.00 (OEM ATI MOBILITY RADEON 9600) vesafb: VBE version 2.0 vesafb: protected mode interface info at: C000:597a vesafb: pmi: set display start = c00c59e8, set palette = c00c5a22 vesafb: pmi: ports = 3010 3016 3054 3038 303c 305c 3000 3004 3060 3062 3064 vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz vesafb: scrolling: redraw vesafb: mode switch failed (eax: 0x14F) console: switching tocolour frame buffer device 200x75 I have tried with different settings of resolution (800x600, 1024x768, 1400x1050, 1680x1050) with the same effect.
You're saying you've tried it with a new notebook. Have you ever been able to get vesafb-tng working on it (with previous kernel versions, and with previous patches)? If not, then you're experiencing a different problem than the one this bug is about.
I have tryed only with the kernels 2.6.8, 2.6.9 and 2.6.10, but without success.
1) What was the last kernel version vesafb(-tng) worked for you? It was gentoo-dev-sources-2.6.9-r13 There is more people with problems geting a framebuffer with 2.6.10: http://forums.gentoo.org/viewtopic.php?t=277733
Maybe it can be helpfull. have installed new kernel 2.6.10-r4, and Vesafb-tng don't report any errors, but screen remain at low resolution. fbset show resolution set by the kernel command line (for example 1400x1050). The interesting thing is that in list of possible display modes there are modes that cannot be displayed on the LCD screen of my notebook, and are missing modes for high resoution of LCD. It seems like that, that tng driver try to set frame buffer for not existing screen (in my case for external monitor).
OK, this is getting complicated, with many bug reports for what is probably a bunch of different issues. Let's stick to a common testing scenario: 1) Upgrade your kernel to the latest gentoo-dev-sources (2.6.10-r4 at the time this is being written). Not 2.6.9, not 2.6.8 or whatever else, just 2.6.10. 2) Make sure you have correctly set the kernel command parameters in your grub/lilo config file. Remember, that it is not video=vesafb-tng:blabla, not video=vesafb-tng,sghaf, not video=vesafb-oh-it-really-rules-doesnt-it:dfadhfad, but pure, simple and plain video=vesafb:[options],<mode>, for example: video=vesafb:1024x768-32@75. 3) Reboot and see what happens. 4) Note that the standard text mode (80x25) is not 640x480! 5) Run `fbset -i` and check the graphic mode you're in. Now, if you're still not satisfied with what you get, do the following: 1) If you have tried vesafb-tng with previous kernel versions, an it has never worked for you, go start a new bug and DO NOT POST any comments here. 2) If you're getting a "mode switch failed" message in your dmesg, emerge lrmi and run vbetest. If you're unable to get into the graphic mode you want to use with vesafb-tng - abandon all hope, I'm sorry, it just isn't going to work. 3) If you can't make vesafb-tng to work, try it with the plain vesafb. Remember to use vga=<mode_number>. If it's not working with vesafb, then it is probably not going to work with vesafb-tng. 4) In all other cases, please post a comment including the following info: - exact kernel version - exact kernel command line parameters - `dmesg | grep vesa` - `fbset -i` - info about whether vbetest from the lrmi package works for you.
Please add comments only about bugs you can reproduce with g-d-s-2.6.10-r5.
I have checked with 2.6.10-gentoo-r5 and there is as follow: - screen remain frozen after kernel set FB there is following from dmesg: Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 865 Chipset. agpgart: Maximum main memory to use for agp memory: 941M agpgart: AGP aperture is 128M @ 0xd8000000 vesafb: ATI Technologies Inc., P11 , 01.00 (OEM: ATI MOBILITY RADEON 9600 ) vesafb: VBE version: 2.0 vesafb: protected mode interface info at c000:597a vesafb: pmi: set display start = c00c59e8, set palette = c00c5a22 vesafb: pmi: ports = 3010 3016 3054 3038 303c 305c 3000 3004 30b0 30b2 30b4 vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz vesafb: scrolling: redraw vesafb: mode switch failed (eax: 0x14f) Console: switching to colour frame buffer device 200x75 fbsplash: console 0 using theme 'default' vesafb: framebuffer at 0xe0000000, mapped to 0xf8880000, using 7500k, total 262080k fb0: VESA VGA frame buffer device the contents of the file /proc/fb0/modes : 320x200-8 320x200-15 320x200-16 320x200-24 320x200-32 320x240-8 320x240-15 320x240-16 320x240-24 320x240-32 400x300-8 400x300-15 400x300-16 400x300-24 400x300-32 512x384-8 512x384-15 512x384-16 512x384-24 512x384-32 640x350-8 640x350-15 640x350-16 640x350-24 640x350-32 640x400-8 640x400-15 640x400-16 640x400-24 640x400-32 640x480-8 640x480-15 640x480-16 640x480-24 640x480-32 800x600-8 800x600-15 800x600-16 800x600-24 800x600-32 1024x768-8 1024x768-15 1024x768-16 1024x768-24 1024x768-32 1280x1024-8 1280x1024-15 1280x1024-16 1280x1024-24 1280x1024-32 1400x1050-8 1400x1050-15 1400x1050-16 1400x1050-24 1400x1050-32 1600x1200-8 1600x1200-15 1600x1200-16 1600x1200-24 1600x1200-32 result of fbset -i: mode "1600x1200-60" # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz geometry 1600 1200 1600 1200 16 timings 6172 304 64 46 1 192 3 hsync high vsync high rgba 5/11,6/5,5/0,0/0 endmode Frame buffer device information: Name : VESA VGA Address : 0xe0000000 Size : 7680000 Type : PACKED PIXELS Visual : MONO01 XPanStep : 0 YPanStep : 0 YWrapStep : 0 LineLength : 0 Accelerator : No and for the comparison the content of the dmesg if I select the radeonfb framebuffer: Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 865 Chipset. agpgart: Maximum main memory to use for agp memory: 941M agpgart: AGP aperture is 128M @ 0xd8000000 radeonfb_pci_register BEGIN ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 17 (level, low) -> IRQ 17 radeonfb: probed SDR SGRAM 262144k videoram radeonfb: mapped 16384k videoram radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=6) Memory=410.00 Mhz, System=270.00 MHz radeonfb: PLL min 20000 max 40000 i2c_adapter i2c-0: registered as adapter #0 i2c_adapter i2c-1: registered as adapter #1 i2c_adapter i2c-2: registered as adapter #2 i2c_adapter i2c-3: registered as adapter #3 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 3 (DVI-I) : 3200 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: Reversed DACs detected i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found Non-DDC laptop panel detected radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: Monitor 1 type LCD found radeonfb: Monitor 2 type no found radeonfb: panel ID string: 1680X1050 WSXGA+ radeonfb: detected LVDS panel size from BIOS: 1680x1050 BIOS provided panel power delay: 400 radeondb: BIOS provided dividers will be used ref_divider = 6 post_divider = 1 fbk_divider = 36 Scanning BIOS table ... 320 x 350 320 x 400 320 x 400 320 x 480 400 x 600 512 x 384 640 x 350 640 x 400 640 x 475 640 x 480 720 x 480 720 x 576 800 x 600 848 x 480 1024 x 768 1280 x 800 1152 x 864 1280 x 1024 1400 x 1050 1680 x 1050 Found panel in BIOS table: hblank: 192 hOver_plus: 56 hSync_width: 32 vblank: 12 vOver_plus: 1 vSync_width: 1 clock: 12150 Setting up default mode based on panel info radeonfb: Power Management enabled for Mobility chipsets hStart = 1736, hEnd = 1768, hTotal = 1872 vStart = 1051, vEnd = 1052, vTotal = 1062 h_total_disp = 0xd100e9 hsync_strt_wid = 0x406c2 v_total_disp = 0x4190425 vsync_strt_wid = 0x1041a pixclock = 8230 freq = 12150 Console: switching to colour frame buffer device 210x65 fbsplash: console 0 using theme 'default' radeonfb: ATI Radeon NP SDR SGRAM 256 MB radeonfb_pci_register END Please take a look for detected video modes in both cases, the driver vesafb-tng detect video modes for an external monitor (not for the lcd screen in the notebook). I don't know how to detect the monitors so I cannot help more. the vbetest I will check today.
There is result of vbetest: VBE Version 2.0 ATI MOBILITY RADEON 9600 [386] 320x200 (256 color palette) [269] 320x200 (5:5:5) [270] 320x200 (5:6:5) [271] 320x200 (8:8:8) [288] 320x200 (8:8:8) [402] 320x240 (256 color palette) [403] 320x240 (5:5:5) [404] 320x240 (5:6:5) [405] 320x240 (8:8:8) [406] 320x240 (8:8:8) [418] 400x300 (256 color palette) [419] 400x300 (5:5:5) [420] 400x300 (5:6:5) [421] 400x300 (8:8:8) [422] 400x300 (8:8:8) [434] 512x384 (256 color palette) [435] 512x384 (5:5:5) [436] 512x384 (5:6:5) [437] 512x384 (8:8:8) [438] 512x384 (8:8:8) [450] 640x350 (256 color palette) [451] 640x350 (5:5:5) [452] 640x350 (5:6:5) [453] 640x350 (8:8:8) [454] 640x350 (8:8:8) [256] 640x400 (256 color palette) [387] 640x400 (5:5:5) [388] 640x400 (5:6:5) [389] 640x400 (8:8:8) [390] 640x400 (8:8:8) [257] 640x480 (256 color palette) [272] 640x480 (5:5:5) [273] 640x480 (5:6:5) [274] 640x480 (8:8:8) [289] 640x480 (8:8:8) [259] 800x600 (256 color palette) [275] 800x600 (5:5:5) [276] 800x600 (5:6:5) [277] 800x600 (8:8:8) [290] 800x600 (8:8:8) [261] 1024x768 (256 color palette) [278] 1024x768 (5:5:5) [279] 1024x768 (5:6:5) [280] 1024x768 (8:8:8) [291] 1024x768 (8:8:8) [263] 1280x1024 (256 color palette) [281] 1280x1024 (5:5:5) [282] 1280x1024 (5:6:5) [283] 1280x1024 (8:8:8) [292] 1280x1024 (8:8:8) [320] 1400x1050 (256 color palette) [321] 1400x1050 (5:5:5) [322] 1400x1050 (5:6:5) [323] 1400x1050 (8:8:8) [324] 1400x1050 (8:8:8) [370] 1600x1200 (256 color palette) [371] 1600x1200 (5:5:5) [372] 1600x1200 (5:6:5) [373] 1600x1200 (8:8:8) [374] 1600x1200 (8:8:8)
vesafb has no way to detect whether you're running LCD, CRT or the latest Ultra 4D Holography Display, it just takes whatever info the video BIOS gives to it. Mirek: can you use vbetest, to actually switch the video modes (and see the colorful checkerboard?), or just to list the video modes? If you can, make sure you try it right after booting up, before X is started.
Thanks Spock. The checking with vbetest was usefull. I have found that on some bpp the resolutions on my laptop cannot be switched. Now I use 1400x1050 with 32 bpp with VESA-TNG driver. The driver is OK, and it seems that my problem is solved (at least in using of possible VESA modes reported by BIOS). Thanks
OK, I'm assuming the problem is fixed then. If it's not, please comment/reopen. If you decide to reopen, please make sure you provide the info requested in comment #31.
