Using gentoo-dev-sources-2.6.8-r1, gentoo-dev-sources-2.6.8-r2 produces same results. I compile fb support, bootsplash support grub entry: title Gentoo Linux (2.6.8-gentoo-r2) root (hd0,0) kernel /kernel-2.6.8-gentoo-r2 root=/dev/md/2 md=2,/dev/hde3,/dev/hdg3 hdc=noprobe hdd=noprobe video=vesa-tng:ypan,mtrr,1600x1200@85 splash=silent initrd /initrd.bs Nvidia geforce FX6800 AGP dual AMD 2400+ Reproducible: Always Steps to Reproduce: 1. compile kernel with vesa-tng support, bootsplash support 2. boot 3. kernel panic Actual Results: kernel panic Expected Results: computer should have booted. emerge info: Portage 2.0.50-r9 (default-x86-2004.2, gcc-3.3.3, glibc-2.3.3.20040420-r1, 2.6.8-gentoo-r1) ================================================================= System uname: 2.6.8-gentoo-r1 i686 AMD Athlon(tm) MP 2400+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -mmmx -msse -m3dnow -mfpmath=sse -fprefetch-loop-arrays -fforce-addr -fomit-frame-pointer -falign-functions=4" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -mmmx -msse -m3dnow -mfpmath=sse -fprefetch-loop-arrays -fforce-addr -fomit-frame-pointer -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.oregonstate.edu/pub/gentoo http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi aim alsa apache2 arts audiofile avi berkdb bonobo cddb cdparanoia cdr crypt cups directfb divx4linux dv dvd dvdr dvdread encode esd ffmpeg foomaticdb freetype gd gdbm gif glade glut gnome gphoto2 gstreamer gtk gtk2 gtkhtml ieee1394 imagemagick imap imlib imlib2 innodb ipv6 jabber java jpeg kde libg++ libwww mad mikmod mmx motif mozilla moznocompose moznoirc moznomail mozsvg mozxmlterm mpeg mpeg4 mysql ncurses nls nvidia oci8 odbc offensive oggvorbis opengl oss pam pcre pda pdflib pear-db perl php png pnp postgres ppds python qt quicktime readline samba sasl sdl slang slp spell sse ssl svga tcltk tcpd tiff transcode truetype type1 usb video_cards_nvidia wifi x86 xine xinerama xml2 xmms xv xvid zlib"
Created attachment 38144 [details] picture of kernel dump took picture with camera
I will be away for the next 3 days, so we will get a slight delay here. In the meantime - could you please compile your kernel with SMP support disabled and check whether vesafb-tng works then?
I compiled without SMP and it worked. In all cases bootsplash does not work. I am using the latest bootplash from portage, 0.6.1-r6.ebuild and the changelog claims to have changes for 2.6.8.1, but I get no bootsplash with vesa-fb or vesa-tng. Previously I have been using and working with bootsplash since before an ebuild for bootsplash existed... ;)
Bootsplash will not work with g-d-s, as it has been removed from this kernel package and replaced by an alternative called fbsplash. See the ChangeLog and http://dev.gentoo.org/~spock/ for details. I'm working on the vesafb-tng SMP problem - I'll contact you as soon as I find a fix.
Created attachment 38995 [details, diff] A possible fix for the SMP problem. Apply the attached patch to your gentoo-dev-sources with: cat vesafb-tng-smp.patch | patch -p1 Then compile your kernel with SMP support and please let me know if it fixes the problems you've been experiencing.
I patched my kernel and receive the same strlcpy() panic. ;(
Now that I've had a second look at the kernel oops, I've noticed that this is probably caused by a piece of obscure code that does a thing that should never be done.. That piece of code has been removed from the latest version of vesafb-tng. Please use the attached patch to upgrade your gentoo-dev-sources to the latest version of vesafb-tng and check if it changes anything. BTW: What graphics board are you using on that system?
Created attachment 39354 [details, diff] a patch to update g-d-s to vesafb-tng-0.9-rc4-r3
graphic chipset = nvidia FX6800 AGP I am going to try the patch out in a few minutes.. ;)
this time it booted, but dmesg shows this: vesafb: BUG, returned from vm86 with 0 vesafb: warning, copying modelist from somewhere in RAM! vesafb: Getting mode info block failed (eax=0x1c) vesafb: vbe_init failed vesafb: probe of vesafb0 failed with error -22
Could you try emerging 'lrmi' and then running vbetest to see if it gives you a modelist?
vbetest worked only after repeatedly running it. Once the full list was displayed, it worked anytime after that... vbetest results: jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest Trace/breakpoint trap jedi ~ # vbetest VBE Version 3.0 WinFast [256] 640x400 (256 color palette) [257] 640x480 (256 color palette) [259] 800x600 (256 color palette) [261] 1024x768 (256 color palette) [263] 1280x1024 (256 color palette) [270] 320x200 (5:6:5) [271] 320x200 (8:8:8) [273] 640x480 (5:6:5) [274] 640x480 (8:8:8) [276] 800x600 (5:6:5) [277] 800x600 (8:8:8) [279] 1024x768 (5:6:5) [280] 1024x768 (8:8:8) [282] 1280x1024 (5:6:5) [283] 1280x1024 (8:8:8) [304] 320x200 (256 color palette) [305] 320x400 (256 color palette) [306] 320x400 (5:6:5) [307] 320x400 (8:8:8) [308] 320x240 (256 color palette) [309] 320x240 (5:6:5) Segmentation fault jedi ~ # vbetest VBE Version 3.0 WinFast [256] 640x400 (256 color palette) [257] 640x480 (256 color palette) [259] 800x600 (256 color palette) [261] 1024x768 (256 color palette) [263] 1280x1024 (256 color palette) [270] 320x200 (5:6:5) [271] 320x200 (8:8:8) [273] 640x480 (5:6:5) [274] 640x480 (8:8:8) [276] 800x600 (5:6:5) [277] 800x600 (8:8:8) [279] 1024x768 (5:6:5) [280] 1024x768 (8:8:8) [282] 1280x1024 (5:6:5) [283] 1280x1024 (8:8:8) [304] 320x200 (256 color palette) [305] 320x400 (256 color palette) [306] 320x400 (5:6:5) [307] 320x400 (8:8:8) [308] 320x240 (256 color palette) [309] 320x240 (5:6:5) [310] 320x240 (8:8:8) [317] 640x400 (5:6:5) [318] 640x400 (8:8:8) [325] 1600x1200 (256 color palette) [326] 1600x1200 (5:6:5) [327] 1400x1050 (256 color palette) [328] 1400x1050 (5:6:5) [338] 2048x1536 (8:8:8) Type a mode number, or 'q' to quit -
I recently rebooted my machine for a hardware upgrade and bootsplash worked on shutdown and worked on bootup. I haven't shut my machine since then, but it seemed to work. maybe my card is too new or something is not standard about it?
from dmesg: vesafb: Leadtek Research Inc, nv40 Board - 21202992, Chip Rev (OEM: WinFast) vesafb: VBE version: 3.0 vesafb: protected mode interface info at c000:d170 vesafb: pmi: set display start = c00cd1a6, set palette = c00cd210 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: ywrap using protected mode interface, yres_virtual=4096 vesafb: framebuffer at 0xf0000000, mapped to 0xe0807000, size 16384k fb0: VESA VGA frame buffer device
My bad on last port. My dual AMD's are actually XP's modded into MP's, so every once in a while, on a reboot, the BIOS only comes up with 1 CPU. The time that my bootsplash worked for me was one of those times. So SMP boot is still not working. I also am using 2.6.8-gentoo-r3.
I'm wondering whether it has anything to do with the VBE not being able to handle SMP systems correctly. The trace/breakoints/segfeaults with vbetest definitely shouldn't be happening. I'll need some more input from other SMP users if I'm going to try fix that. I will add an appropriate note to my devpage shortly.
I hope its ok for us to leave this one for you spock :)
I'm using a CUV4X-D (dual P3 1ghz) at home with either a Geforce TI 4200 or a GeForce FX 5900 (I'm switching occasionnaly with my friend video card). I'm using a nitro4 patched 2.6.9 kernel on fedora core 2. Every one or 2 reboots my system hangs just before starting redhat nash... at that point when it boots it usually changes the resolution to 1280x1024-32@85 and the continues with redhat nash... I've tried nitro4 kernel on my Dell Precision 530 dual P4 2ghz at the office and the boot splash does not work with hotplug activated... I've found that out that fedora core 3 uses udev and when I ported my old home-made kernel config from core 2 without usb or firewire that hotplug was deactivated.. and the bootsplash was working properly but udev was failing. By activating it it made the kernel panic on vesa_tng at every boot... by usaing the vesa_std it booted like usual. I've tried it a couple of time... and I'm sure that by only activating hotplug (without pcmcia or pci hotplug) it make the kernel panic! Hope this helps! - vin
BTW, it is also an nvidia card that I use at my job.. a quatro 4 in dual head mode. If you ever need more specific info don't hesitate to ask.
I too have problems running vesa frame buffer but I didn't get any kernel panic messages. The farthest I could go with gentoo-dev-sources-2.6.9-r12 was to get a frame buffer console but the keyboard refused to work. The first problem I had was boot locked up while loading vesafb. As gentoo live cd always works I wanted to get as close as possible to its kernel configuration. The main differences are that LiveCD 1) uses 486 instruction sets, 2) loads with acpi=ht and 3) also supports APM as a module in spite of built-in ACPI support. I could get one successful boot but as soon as I rebooted I got message "i8042.c: Can't read CTR while initializing i8042"; keyboard didn't work anymore. I loaded kernel with nolapic and noapic but it helped only the first boot. Subsequent boots resulted in keyboard refusing to work.
Please try with 2.6.10
Created attachment 47255 [details] Kernel panic (2.6.10-nitro2) I've just gave I try on nitro2 patch for 2.6.10. Ain't sure of the exact revision of the vesa_tng module but anyhow, here's what it looks like on a dual P3 1ghz with a GeForce 2 GTS Pro 64. - vin
As of 2.6.10-gentoo-r4 I still get kernel panic on boot. Note, old vesafb still works fine. I did not make a screenshot of the panic, but I could, although it is very similar, if not the same as the last attachment posted http://bugs.gentoo.org/attachment.cgi?id=47255&action=view cheers
Tried 2.6.11-gentoo-r4, 1280x1024-32@60 mode. both screens blanks after kernel boots, computer is unresponsive. Unable to see any errors. I am not sure how to log any information in a situation like this, but I am willing to help in anyway to solve what seems to be either a VESA or VESA/SMP problem. Leadtek A400 Geforce6800 AGP. dual display, one VGA and one DVI output used. uname -a: Linux jedi 2.6.11-gentoo-r4 #1 SMP Fri Mar 25 00:34:12 MST 2005 i686 AMD Athlon(tm) MP 2800+ AuthenticAMD GNU/Linux [I--] [ ] media-gfx/splashutils-0.9.1 (0) [I--] [ ] sys-kernel/gentoo-dev-sources-2.6.11-r4 (2.6.11-r4) emerge info: Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r4 i686) ================================================================= System uname: 2.6.11-gentoo-r4 i686 AMD Athlon(tm) MP 2800+ Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 6 2005, 23:14:36)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -mmmx -msse -m3dnow" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /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/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -mmmx -msse -m3dnow" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex S3TC X a52 aac aalib acl acpi aim alsa apache2 arts artswrappersuid artworkextra asm audiofile avi bash-completion berkdb bitmap-fonts bmp bzip2 bzlib cairo cddb cdparanoia cdr cdrom crypt cscope ctype cups curl dhcp divx4linux dnd dts dv dvd dvdr dvdread emacs encode esd exif ffmpeg flac flash foomaticdb freetype freetype2 ftp gd gif gimp gimpprint glade glut gmail gphoto2 graphviz gs gstreamer gtk gtk2 gtkhtml guile hal haskell icq ieee1394 image imagemagick imap imlib imlib2 innodb ipv6 j2ee jabber java joystick jpeg jpeg2k kde lirc lm_sensors lzo lzw lzw-tiff mad mbox mjpeg mmap mmx mmx2 mng motif mozdevelop mozilla moznocompose moznoirc moznomail mozsvg mozxmlterm mp3 mpeg mpeg4 mplayer msn mysql mythtv ncurses nls nntp nptl nvidia offensive oggvorbis openal opengl openssh oss pam pcap pcre pda pdf pdflib pear-db perl php png pnp ppds print pthreads python qt quicktime rdesktop readline rtc samba sasl scanner sdl slang slp snmp sounds sox speex spell sql sse ssl stream subversion svg svga tcltk tcpd tetex theora threads tiff transcode truetype truetype-fonts type1 type1-fonts usb userlocales v4l v4l2 videos vim-with-x vnc vorbis wifi xchatdccserver xine xinerama xinetd xml xml2 xmlrpc xosd xpm xprint xrandr xscreensaver xsl xslt xv xvid zlib video_cards_nvidia" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
vbetest, which used to segfault, now returns this: jedi joe # vbetest VBE Version 3.0 WinFast [256] 640x400 (256 color palette) [257] 640x480 (256 color palette) [259] 800x600 (256 color palette) [261] 1024x768 (256 color palette) [263] 1280x1024 (256 color palette) [270] 320x200 (5:6:5) [271] 320x200 (8:8:8) [273] 640x480 (5:6:5) [274] 640x480 (8:8:8) [276] 800x600 (5:6:5) [277] 800x600 (8:8:8) [279] 1024x768 (5:6:5) [280] 1024x768 (8:8:8) [282] 1280x1024 (5:6:5) [283] 1280x1024 (8:8:8) [304] 320x200 (256 color palette) [305] 320x400 (256 color palette) [306] 320x400 (5:6:5) [307] 320x400 (8:8:8) [308] 320x240 (256 color palette) [309] 320x240 (5:6:5) [310] 320x240 (8:8:8) [317] 640x400 (5:6:5) [318] 640x400 (8:8:8) Type a mode number, or 'q' to quit - q
Please give the following patch a try: http://dev.gentoo.org/~spock/projects/vesafb-tng/testing/vesafb-tng-testing-2005091603.patch The patch should apply against vanilla 2.6.13* and 2.6.14-rc1.
2.6.14_rc1, no boot. different error msgs. screens: http://www.roback.cc/tmp/SMPbug1.jpg : http:// www.roback.cc/tmp/SMPbug2.jpg
Hmm.. it looks like a far too long list of PMI ports. Could you please try commenting out lines 994 and 995 in drivers/video/vesafb-tng.c? /* if ((vesafb_vbe_getpmi(tsk)) != 0) goto out; */ After that, please make sure that you don't have 'ypan', 'ywrap' or 'pmipal' in your video options on the kernel command line.
Created attachment 68630 [details] vesafb-tng.c modifications screenshot vesafb-tng.c modifications screenshot. Kernel just freezes there. :(
Hm.. it seems like it's stuck somewhere near getting the EDID block from the Video BIOS. Could you please try adding 'noedid' to your video= kernel command line options (like: video=vesafb:noedid,1024x768-32)? I realize that it's hackish and we're just skipping parts of the code now, but I would like to see just how far can we get it.
I had the same kind of problems with EDID using new nvidiafb driver (http://bugzilla.kernel.org/show_bug.cgi?id=4768). Maybie there is a few interesting part of the code wich could be used for this specific case. - vin
Vincent: as I recall, you also had some problems with vesafb-tng on a SMP system. If you have some free time, could you please try the new 'testing' patch I mentioned in comment #26?
Ok, we booted! After commenting out those 2 lines of code from vesafb-tng.c and changing my grub line to: video=vesafb:noedid,mtrr:3,1280x1024-32@60
Nice :) Could you please check whether the system is stable after you boot, and whether you can safely switch modes with fbset? It would also be helpful if you could emerge x11-misc/read-edid and see whether `get-edid | parse-edid` works for you..
azrael ~ # get-edid get-edid: get-edid version 1.4.1 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Trace/breakpoint trap --------- After trying a few times in a row: azrael ~ # get-edid get-edid: get-edid version 1.4.1 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0x11110 "WinFast" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call failed The EDID data should not be trusted as the VBE call failed EDID claims 255 more blocks left EDID blocks left is wrong. Your EDID is probably invalid.
azrael ~ # get-edid get-edid: get-edid version 1.4.1 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Trace/breakpoint trap --------- After trying a few times in a row: azrael ~ # get-edid get-edid: get-edid version 1.4.1 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0x11110 "WinFast" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call failed The EDID data should not be trusted as the VBE call failed EDID claims 255 more blocks left EDID blocks left is wrong. Your EDID is probably invalid. ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ------- parsed output: azrael ~ # get-edid|parse-edid parse-edid: parse-edid version 1.4.1 get-edid: get-edid version 1.4.1 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0x11110 "WinFast" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call failed The EDID data should not be trusted as the VBE call failed EDID claims 255 more blocks left EDID blocks left is wrong. Your EDID is probably invalid. parse-edid: EDID checksum failed - data is corrupt. Continuing anyway. parse-edid: first bytes don't match EDID version 1 header parse-edid: do not trust output (if any). # EDID version 255 revision 255 Section "Monitor" Identifier "___:ffff" VendorName "___" ModelName "___:ffff" # DPMS capabilities: Active off:yes Suspend:yes Standby:yes Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz DotClock 655.350000 HTimings 4095 4350 4605 8190 VTimings 4095 4158 4221 8190 Flags "Interlace" "+HSync" "+VSync" EndMode Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz DotClock 655.350000 HTimings 4095 4350 4605 8190 VTimings 4095 4158 4221 8190 Flags "Interlace" "+HSync" "+VSync" EndMode Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz DotClock 655.350000 HTimings 4095 4350 4605 8190 VTimings 4095 4158 4221 8190 Flags "Interlace" "+HSync" "+VSync" EndMode Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz DotClock 655.350000 HTimings 4095 4350 4605 8190 VTimings 4095 4158 4221 8190 Flags "Interlace" "+HSync" "+VSync" EndMode EndSection ------ I will try fbset as soon as I get a chance and let you know
An updated patch is available at: http://dev.gentoo.org/~spock/projects/vesafb-tng/testing/vesafb-tng-testing-2005092001.patch This one should work out of the box, provided you use the 'noedid' option and don't use any fancy features such as pmipal and ypan/ywrap. The EDID function is definitely broken in your case -- as you can see, it doesn't return any meaningful data. What worries me is the 'Trace/breakpoint trap' messages you're getting when running some vm86 apps. I wonder whether one of these traps can one day happen when running vesafb-tng code..
The problem should be fixed in the latest gentoo-sources (2.6.14) which include vesafb-1.0-rc1.
