After upgrading X to 1.5, switching to virtual terminal with C-M-F1 shows a blank screen with cursor blinking. I'm using nvidia-drivers-180.29 and evdev. After exiting X, terminals work as expected.
The same here, xorg-server-1.5.3-r5, nvidia-drivers-173.14.18 (older versions doesn't support my GeForce 7300GT). I investigated a bit and I found so far: 1) With nvidia driver it gets copletely blank screen, but it seems, I can type on it. After X server exit I can use VT as usual, but all VT's I tried to switch to are filled with blinking paragraph sign on grey background. 2) With nv driver I'm able to switch to VTs, they are filled with that gibberish (blinking paragraph sign on grey background), but I can reset the terminal and work as usual. 3) With vesa driver everything is ok. BTW I found a lot of similar cries for (mostly) nvidia cards in other bugsystems, like RH or ubuntu.
Additional note: if my attempts to switch to VT are too fast, all input dies and I can reboot machine only remotely or via programmed acpid. I use kdb and mouse for input devs, but not evdev.
Update: I tried Option BackingStore "False" as was recommended in some reports, but it is useless. Really, I'm lurking in the twilight.
Please post your "emerge --info", the version of nvidia-drivers you are using and attach your xorg.conf file as well.
(In reply to comment #4) > Please post your "emerge --info", the version of nvidia-drivers you are using Version of nvidia-drivers was already posted by both reporters: > I'm using nvidia-drivers-180.29 > nvidia-drivers-173.14.18 (older versions doesn't support my GeForce 7300GT)
Created attachment 187025 [details] emerge --info
Created attachment 187026 [details] xorg.conf Note: default config file (generated by Xorg --configure) have the same issue.
Originally my kernel was compile with FB support as module, it was disabled by default, by nvidiafb module was automatically loaded. Its unload doesn't help. I recompiled kernel with no FB support at all, but this won't help also. I have no errors in Xorg.conf and only single warning: (WW) NVIDIA(GPU-0): Failed to determine GPU name I always had it for this GPU, so this is not an issue.
Same/similar issue here. Switching to a virtual terminal shows me a normal screen with a blinking cursor in the upper-left edge which stays in the upper-left edge, no matter what. I can login and type some commands, but when the screen is full, the screen does not scroll up. If I type ctrl-l to clear the screen, depending on how many lines I'm "out of screen", the command prompt appears as many lines below the top of the screen (which can still be "out of screen"). In any case, switching to another vt and back shows the screen as it should be (but still with a blinking cursor in the upper-left edge and a messed up scrolling behaviour). If I start X using the "startx" command, after closing X, the virtual terminals appear to be normal. However, if I start X using "/etc/init.d/xdm start", the virtual terminals keep messed up, even after a "/etc/init.d/xdm stop". linux kernel 2.6.28.9 (as before the xorg upgrade) nvidia-drivers-96.43.11 (as before the xorg upgrade) xorg-server-1.5.3-r5 (on a GeForce FX 5500) more (emerge --info) needed?
I found a workaround for my problem: http://bbs.archlinux.org/viewtopic.php?id=61517 http://www.nvnews.net/vbulletin/showthread.php?t=120492 1. compiled VESA static in the kernel (needed at startup so no module) 2. added vga=789 in lilo.conf 3. lilo 4. upgraded to x11-drivers/nvidia-drivers-173.14.15 5. created /etc/modprobe.d/nvidia_console-workaround with: options nvidia NVreg_UseVBios=0 6. update-modules 7. reboot By the way, I'm using 2 screens (monitor and TV) and 2 X-servers for 2 users which are normally simultaneously logged in, and of course the consoles ;-)
(In reply to comment #10) > I found a workaround for my problem: > http://bbs.archlinux.org/viewtopic.php?id=61517 > http://www.nvnews.net/vbulletin/showthread.php?t=120492 Is there any way to fix this for plain console without framebuffer?
(In reply to comment #10) > I found a workaround for my problem: > 4. upgraded to x11-drivers/nvidia-drivers-173.14.15 > 5. created /etc/modprobe.d/nvidia_console-workaround with: > options nvidia NVreg_UseVBios=0 I'm not sure that it will work for older cards : I tried with nvidia-drivers-96.43.11, and "modprobe nvidia" failed ("nvidia: Unknown parameter `NVreg_UseVBios'") T.
(In reply to comment #12) > I'm not sure that it will work for older cards : > I tried with nvidia-drivers-96.43.11, and "modprobe nvidia" failed ("nvidia: > Unknown parameter `NVreg_UseVBios'") I also got that message with nvidia-drivers-96.43.11, that's why I upgraded to nvidia-drivers-173.14.15 ;-)
(In reply to comment #10) > 1. compiled VESA static in the kernel (needed at startup so no module) > 2. added vga=789 in lilo.conf > 3. lilo > 4. upgraded to x11-drivers/nvidia-drivers-173.14.15 > 5. created /etc/modprobe.d/nvidia_console-workaround with: > options nvidia NVreg_UseVBios=0 > 6. update-modules > 7. reboot This worked for me, although not with VESA. I used UVESAFB instead, and had to disable vesa. I also needed v86d, and the UseVBios option.
Is this still an issue?
(In reply to comment #15) > Is this still an issue? I found I had to change framebuffer in the kernel to CONFIG_FB_UVESA and then the problem went away. I'm also now running nvidia-drivers-190.42-r1 and xorg-server-1.6.5 without problems.
(In reply to comment #15) > Is this still an issue? Yes, it still fails if (S)VGA console is used (not framebuffer). Mine setup is (almost) the latest: xorg-server-1.6.5, nvidia-drivers-190.42, vanilla-sources-2.6.31.5 (own build). This is nvidia proprietary driver specific issue. I can't reproduce it with nv or nouveau from git. I made some research and it seems I found the reason. I noticed that nvidia loads fb and wfb xorg submodules. On single screen setup (have not tested with twin view) this can be disabled via Disable "fb" and Disable "wfb" directives in the Modules section. And after this switching to vga virtual terminal works perfectly. But this solution doesn't work with dual screen setup. As far as I understand, nvidia module engaged by Xorg for the second screen the second time. And this second time 'Disable (w)fb' directives are overriden/ignored and switching to VGA VT fails again. This seems to be doublefault for both nvidia driver unconditionally loading fb and wfb and Xorg for ignoring Disable "module" directive the second time.
(In reply to comment #15) > Is this still an issue? Yes, here it's still an issue too, so I think this one should be reopened. linux kernel 2.6.30.9 x11-base/xorg-server-1.6.3.901-r2 x11-drivers/nvidia-drivers-173.14.20 But the workaround using VESA and NVreg_UseVBios=0 still works :)
Bugzie, since uses report its still issue.
(In reply to comment #17) > (In reply to comment #15) > > Is this still an issue? > > Yes, it still fails if (S)VGA console is used (not framebuffer). Mine setup is > (almost) the latest: > xorg-server-1.6.5, nvidia-drivers-190.42, vanilla-sources-2.6.31.5 (own build). > > This is nvidia proprietary driver specific issue. I can't reproduce it with nv > or nouveau from git. > > I made some research and it seems I found the reason. I noticed that nvidia > loads fb and wfb xorg submodules. On single screen setup (have not tested with > twin view) this can be disabled via Disable "fb" and Disable "wfb" directives > in the Modules section. And after this switching to vga virtual terminal works > perfectly. > > But this solution doesn't work with dual screen setup. As far as I understand, > nvidia module engaged by Xorg for the second screen the second time. And this > second time 'Disable (w)fb' directives are overriden/ignored and switching to > VGA VT fails again. This seems to be doublefault for both nvidia driver > unconditionally loading fb and wfb and Xorg for ignoring Disable "module" > directive the second time. > You will need to use TwinView and not a multi-screen or Xinerama setup to get this to work. You will still need to use the NVreg_UseVBios workaround as well. You card's video bios is doing bad things and can't be used or trusted.
(In reply to comment #18) > (In reply to comment #15) > > Is this still an issue? > > Yes, here it's still an issue too, so I think this one should be reopened. > > linux kernel 2.6.30.9 > x11-base/xorg-server-1.6.3.901-r2 > x11-drivers/nvidia-drivers-173.14.20 > > But the workaround using VESA and NVreg_UseVBios=0 still works :) > Your card has a bad video BIOS basically. I'd suggest contacting the manufacture and seeing if you can get a flash update.
I should note, you guys should be attaching the output from nvidia-bug-report.sh. E-mailing NVIDIA @ linux-bugs@nvidia.com with your issue and output from nvidia-bug-report.sh. In addition, start X as follows: startx -- -verbose 5 -logverbose 5 And attach your Xorg.0.log And lastly, do not use Xorg -configure. NVIDIA has a utility that will behave correctly with their cards and its called nvidia-xconfig
(In reply to comment #20) [...] > You will need to use TwinView and not a multi-screen or Xinerama setup to get > this to work. You will still need to use the NVreg_UseVBios workaround as well. > You card's video bios is doing bad things and can't be used or trusted. I can't use TwinView. It is awesomely ugly on two completely different monitors: LCD and CRT with different pixelsize, geometry and colorspace. I need different screens as an independent workspaces.
(In reply to comment #22) > I should note, you guys should be attaching the output from > nvidia-bug-report.sh. E-mailing NVIDIA @ linux-bugs@nvidia.com with your issue > and output from nvidia-bug-report.sh. This bug was reported to nvidia ages ago and nothing changed so far. > And lastly, do not use Xorg -configure. NVIDIA has a utility that will behave > correctly with their cards and its called nvidia-xconfig I do not use both of them. nvidia-xconfig brokes another things like non-standard keyboard layouts. There is nothing difficult in writing xorg.conf yourself and manual from nvidia drivers describes this in a great detail.
(In reply to comment #23) > (In reply to comment #20) > [...] > > You will need to use TwinView and not a multi-screen or Xinerama setup to get > > this to work. You will still need to use the NVreg_UseVBios workaround as well. > > You card's video bios is doing bad things and can't be used or trusted. > > I can't use TwinView. It is awesomely ugly on two completely different > monitors: LCD and CRT with different pixelsize, geometry and colorspace. I need > different screens as an independent workspaces. > Well then you're going to need to correctly setup independent devices and configure them with XRandR and not use Xinerama. Xinerama has some serious issues and has been discontinued by xorg upstream. To use XRandR, instead of TwinView, certain cards manufactured by third party providers require the NVreg_UseVBios hack. Really there's nothing to be fixed here. The issue boils down to not using the recommended configuration and using an alternative configuration which works with certain configuration parameters set. This is also compounded by the fact that your hardware is obviously on the list of problematic boards. scarabeus: You reopened the issue so I'll let you decide what to do with it.
(In reply to comment #25) > Well then you're going to need to correctly setup independent devices and > configure them with XRandR and not use Xinerama. Xinerama has some serious > issues and has been discontinued by xorg upstream. You completely misread my message. I do not use Xinerama at all. I configured independent devices to use different X Screens. Just spend your time into looking for mine xorg.conf. Well, it slightly changed since them, but changes are irrelevant to this case. > Really there's nothing to be fixed here. The issue boils down to not using the > recommended configuration and using an alternative configuration which works > with certain configuration parameters set. This is also compounded by the fact > that your hardware is obviously on the list of problematic boards. There is nothing unrecommended and discouraged in Dual Screen setup. Please point me to NVidia official documentation if otherwise. It seems you are just trying to close long standing (almost) unsolvable bug.
(In reply to comment #26) > (In reply to comment #25) It should be absolutely no surprise that NVIDIA has always recommended their TwinView configuration over a dual screen configuration in xorg.conf. The answer showing that should be a simple Google Search or looking through their forums. As far as trying to close off this bug, you are correct. I am trying to close off this bug because the issue is simply something that I nor anyone on the internet can magically fix. You have an issue with your physical hardware, more specifically your video BIOS. NVIDIA has introduced a configuration work around for people in your situation and through the course of this ticket you and others have shown that it fixes your issue. Now most people would accept the fact that in the Linux world you have to do some manual configuration sometimes and be happy doing that. To top that off I provided you with another potential solution that you should strongly consider and that is to contact your hardware manufacture for a repair or a new video BIOS.
I'm sorry for bumping this, but this is NOT nVidia bug, it's Xorg! I wa using an old 1.3 xorg-server till last weekend and everything worked, then I only changed xorg-server to 1.5 (along with its drivers) and this bug occured, so don't tell me nvidia saw xorg 1.5 ant went berserk... I tried this when 1.5 got stable and the bug occured so i stayed by the 1.3 at the time. More info: it only occurs when I want to use 2 separate screens on my dual-head-card. If I only configure one screen, everything works.
> NVIDIA has introduced a configuration work around > for people in your situation and through the course of this ticket you and > others have shown that it fixes your issue. Once again, the "NVreg_UseVBios hack" doesn't work for old cards which need nvidia-drivers-96.43-xx (even with the recent 96.43.14). T.
(In reply to comment #28) > I'm sorry for bumping this, but this is NOT nVidia bug, it's Xorg! I wa using > an old 1.3 xorg-server till last weekend and everything worked, then I only > changed xorg-server to 1.5 (along with its drivers) and this bug occured, so > don't tell me nvidia saw xorg 1.5 ant went berserk... As I wrote before this is double fault for both nvidia drivers and xorg. Now it is fixed on the xorg side and I *can* switch to plain console virtual terminal from X server. My setup: xorg-server-1.7.2, nvidia-drivers-190.42-r3.
