After upgrading my kernel to gentoo-sources-2.6.14-r2, I found I was unable to switch to the fb console after X had loaded. splashutils and the fb console worked fine during boot. Switching back to a console using CTRL+ALT+Fx causes my monitor to issue a "signal out of range" message, and nothing is displayed. When shutting down or rebooting the machine (from xdm), I also get the "signal out of range" and don't see the shutdown splash. I used make oldconfig when I upgraded kernel versions, so my video config is exactly the same as it was with my prior kernel version (gentoo-sources-2.6.13-r5). I have no problem switching back to the fb console using 2.6.13-r5. At the suggestion from hielvc (h_vancampen@yahoo.com) in the forums, I checked my /etc/rc.conf and changed UNICODE="yes" to UNICODE="no". This solved the problem. Reproducible: Always Steps to Reproduce: 1. Make sure you have a working fb console using vesafb-tng under gentoo-sources-2.6.13 2. Upgrade to gentoo-sources-2.6.14-r2 3. Reboot machine 4. Allow X to load via xdm 5. Attempt to switch back to the fb console using CTRL+ALT+Fx Actual Results: Monitor yields "signal out of range." Expected Results: Display the fb console, even with UNICODE="yes" in /etc/rc.conf. This apparently doesn't happen with all hardware, or else is tied specifically to the UNICODE="yes" in /etc/rc.conf. More user experiences can be read here: http://forums.gentoo.org/viewtopic.php?p=2900866
Please do the following: 1) paste your /proc/cmdline 2) attach your kernel config 3) let us know what xorg driver you're using 4) try typing `fbset -xres 1024 -yres 768 -depth 32` (adjust the settings for the resolution you're using) in the following situations: a) before X has started, with UNICODE="yes" b) before X has started, with UNICODE="no" c) after X has started, with UNICODE="yes" (you'll have to blindly type on the console while you're seeing the out-of-sync message).
1) paste your /proc/cmdline: root=/dev/sda3 video=vesafb:mtrr,ywrap,1024x768-32@75 splash=silent CONSOLE=/dev/tty1 2) attach your kernel config: To follow shortly... 3) let us know what xorg driver you're using: I'm using the i810 driver for xorg (I've got an Intel 915G motherboard with integrated Intel GMA900 graphics). fbset -xres 1024 -yres 768 -depth 32 a) before X has started, with UNICODE="yes": This works as expected. Since X hasn't started, I don't have any problems seeing or using the fb console. The screen flashes as the display mode is changed, and then reappears exactly as it was prior to fbset. b) before X has started, with UNICODE="no": This works as expected. The screen flashes as the display mode is changed, and then reappears exactly as it was prior to fbset. c) after X has started, with UNICODE="yes": OK, since I had taken xdm out of my startup for part a), I started X manually using startx. With UNICODE="yes", I had no problems switching back to the fb console from X this way. Surprised, I put xdm back in my default runlevel and rebooted. Even more surprising, I wasn't able to reproduce the problem--CTRL+ALT+Fx worked just fine, with no monitor sync errors. After having this occur consistently since upgrading to gentoo-sources-2.6.14-r2, I have to admit that this is baffling. I can only suspect that perhaps there was some subtle difference between UNICODE="yes" and UNICODE="no", and that after switching to "no", my monitor somehow remembered the video mode even when I switched back to "yes". In short, this is totally bizarre. I know this more than a fluke since other people are having the same problems. I'll refer those in the forum thread to try the above steps as well, to see if they have anything they can contribute.
Created attachment 73651 [details] My gentoo-sources-2.6.14-r2 kernel config Attaching kernel config as requested.
OK, today I was able to reproduce the problem. X started via xdm, with UNICODE="yes". I switched back to my console and got "signal out of range." I issued the fbset command (blindly) and nothing happened at all. For kicks and giggles, I even tried different combinations of resolutions and color depths--nothing.
I'm also having problems with vesafb-tng causing monitor to loose sync in console after starting X. But for me I fixed it temporarily by using 800x600 resolution in vesafb-tng rather than 1024x768 as usual.
Just a quick note to let you all know that I haven't forgotten about the problem :) For now, those of you who don't care about higher refresh rates could probably try to use the 'nocrtc' vesafb-tng option (eg. video=vesafb:nocrtc,1024x768-32@85) which will cause the default BIOS refresh rate to be used. Here is one more thing to check. When your console goes out of sync (after you switch to it from Xorg), try using the following two commands: fbset -xres 1024 -yres 768 -depth 32 -pixclock 1 fbset -xres 1024 -yres 768 -depth 32 -pixclock 0 (as usual, you'll have to adjust the settings for the resolution you're using). The important thing here is the pixclock value. Please let me know whether you get any interesting results with these two.
fbset -xres 1024 -yres 768 -depth 32 -pixclock 1 This didn't seem to have any visible effect, although there's a possibility that I didn't wait long enough (see my comment on the second command below). fbset -xres 1024 -yres 768 -depth 32 -pixclock 0 At first I thought this command had no effect either, but after a couple of seconds my fb console reappeared! Yippee! Because I tried this really soon after the first command, I suppose it may be possible that the first command may have succeeded had I waited a few more seconds. Anyway, I know for sure that the second command fixed the problem for me. I will try the first command after the bug manifests itself again, and wait a little longer next time to see if that works as well.
(In reply to comment #6) > fbset -xres 1024 -yres 768 -depth 32 -pixclock 1 No change. > fbset -xres 1024 -yres 768 -depth 32 -pixclock 0 This gave me my console back. :)
*** Bug 119394 has been marked as a duplicate of this bug. ***
*** Bug 116791 has been marked as a duplicate of this bug. ***
Is this still a problem for anyone?
Its still a problem to me. Changing the pixclock partial fix it, but then the h-position get messy.
Yes, I still have problems unless I use the nocrtc option.
(In reply to comment #13) > Yes, I still have problems unless I use the nocrtc option. > It's been awhile since anyone commented on this, but the problem still exists.
(In reply to comment #14) > (In reply to comment #13) > > Yes, I still have problems unless I use the nocrtc option. > > > > It's been awhile since anyone commented on this, but the problem still exists. > I should clarify, this problem continues to affect the vesa-tng included in gentoo-sources-2.6.18, haven't tested with 2.6.19
I'm closing this bug as WONTFIX, since we're dropping support for vesafb-tng. vesafb-tng has been replaced by uvesafb in gentoo-sources-2.6.23. uvesafb provides the same functionality, but is completely redesigned and hopefully will prove to be free of any bugs that might have been present in vesafb-tng. If you encounter a similar problem with uvesafb, please open a new bug.
