Gettys (virtual consoles) still inaccessible?

linuxvvhore · 04-26-03, 10:47 AM

I've upgraded to the 4363 drivers, and I'm elated at the fact that I no longer need to use the KT400 workarounds. Kudos to Andy and the NVidia guys.

However, I still have problems switching to any of my virtual consoles or even just plain shutting down. The screen goes blank (but not off) and the computer becomes unresponsive. Any idea if this was supposed to be adressed in this driver release? If not, is there a workaround yet?

Thanks!
(Redhat 9 & GeForce4 Ti4200 8x)

linuxvvhore · 04-26-03, 11:49 PM

Is this a common problem? Anyone have any ideas?

bwkaz · 04-27-03, 07:29 AM

It's a sort-of common problem, but the only solution I know of (turn on vesafb), I think you've tried, and IIRC, it didn't work.

Jon_e · 04-28-03, 07:23 PM

For some people this also happens with a TV connected.

I don't know if this also happens with other types of dual display setups.

dougster · 04-28-03, 08:53 PM

After rebuilding with VESAFB and then booting the kernel with the vga=9 parameter this totally resolved the problem for me. I don't know why this is, only that doing this re-enabled the virtual terminals where none others seemed to work; i.e. the "vga16 framebuffer" doesn't work, and the default "no framebuffer" doesn't work either. Not a fix, only a workaround, although the vesafb console drivers seem stable enough and there is no big reason not to use them with a nVidia card.

linuxvvhore · 04-29-03, 07:40 PM

So, if I understand correctly, I need to recompile my linux kernel with vesafb support enabled.

Any tips on how to do this without configuring the kernel from scratch? Is there a file I can simply modfy to say VESAFB=yes and then rpmbuild or something? I don't like having to use stock kernels when Redhat has patches they use in the official release.

linuxvvhore · 04-29-03, 08:18 PM

Erm, well., maybe vesafb support is compiled in by default on the RH kernels. However, I'm still having problems. "vga=9" doesn't work for me. I look in /usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20/Documentation/fb/vesafb.txt and see this table of values:

| 640x480 800x600 1024x768 1280x1024
----+-------------------------------------
256 | 0x301 0x303 0x305 0x307
32k | 0x310 0x313 0x316 0x319
64k | 0x311 0x314 0x317 0x31A
16M | 0x312 0x315 0x318 0x31B

None of these look like "9" to me. I tried some of the 640x480 and 800x600 modes, but neither of them seemed to fix my gettys problem. What am I missing?

04-26-03, 10:47 AM	#1
linuxvvhore Registered User Join Date: Apr 2003 Location: Neenah, WI Posts: 13	Gettys (virtual consoles) still inaccessible? I've upgraded to the 4363 drivers, and I'm elated at the fact that I no longer need to use the KT400 workarounds. Kudos to Andy and the NVidia guys. However, I still have problems switching to any of my virtual consoles or even just plain shutting down. The screen goes blank (but not off) and the computer becomes unresponsive. Any idea if this was supposed to be adressed in this driver release? If not, is there a workaround yet? Thanks! (Redhat 9 & GeForce4 Ti4200 8x)

04-27-03, 07:29 AM	#3
bwkaz Registered User Join Date: Sep 2002 Posts: 2,262	It's a sort-of common problem, but the only solution I know of (turn on vesafb), I think you've tried, and IIRC, it didn't work. __________________ Registered Linux User #219692

04-28-03, 08:53 PM	#5
dougster Registered User Join Date: Mar 2003 Location: Pennsylvania Posts: 1	VesaFB fixes it on mine. After rebuilding with VESAFB and then booting the kernel with the vga=9 parameter this totally resolved the problem for me. I don't know why this is, only that doing this re-enabled the virtual terminals where none others seemed to work; i.e. the "vga16 framebuffer" doesn't work, and the default "no framebuffer" doesn't work either. Not a fix, only a workaround, although the vesafb console drivers seem stable enough and there is no big reason not to use them with a nVidia card.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
(Kotaku) Do We Really Need Video Game Consoles Anymore? [Speak Up On Kotaku]	News	Latest Tech And Game Headlines	1	06-16-12 11:35 AM
For Best Virtual Desktop: NVIDIA VGX & Windows RemoteFX	News	Latest Tech And Game Headlines	0	06-13-12 10:30 AM
Black screen after switching between graphical virtual consoles five times	rrr-wtf	NVIDIA Linux	1	05-21-12 04:40 PM
ctrl-alt-f1..f6 virtual consoles	undome	NVIDIA Linux	1	09-30-02 12:24 PM

04-26-03, 11:49 PM	#2
linuxvvhore Registered User Join Date: Apr 2003 Location: Neenah, WI Posts: 13	Is this a common problem? Anyone have any ideas?

04-28-03, 07:23 PM	#4
Jon_e Registered User Join Date: Apr 2003 Posts: 22	For some people this also happens with a TV connected. I don't know if this also happens with other types of dual display setups.

04-29-03, 07:40 PM	#6
linuxvvhore Registered User Join Date: Apr 2003 Location: Neenah, WI Posts: 13	So, if I understand correctly, I need to recompile my linux kernel with vesafb support enabled. Any tips on how to do this without configuring the kernel from scratch? Is there a file I can simply modfy to say VESAFB=yes and then rpmbuild or something? I don't like having to use stock kernels when Redhat has patches they use in the official release.

04-29-03, 08:18 PM	#7
linuxvvhore Registered User Join Date: Apr 2003 Location: Neenah, WI Posts: 13	Erm, well., maybe vesafb support is compiled in by default on the RH kernels. However, I'm still having problems. "vga=9" doesn't work for me. I look in /usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20/Documentation/fb/vesafb.txt and see this table of values: \| 640x480 800x600 1024x768 1280x1024 ----+------------------------------------- 256 \| 0x301 0x303 0x305 0x307 32k \| 0x310 0x313 0x316 0x319 64k \| 0x311 0x314 0x317 0x31A 16M \| 0x312 0x315 0x318 0x31B None of these look like "9" to me. I tried some of the 640x480 and 800x600 modes, but neither of them seemed to fix my gettys problem. What am I missing?