I've recently got myself an HP Presario r3004 notebook, with an AMD64 processor
and an nVidia Geforce4 440 Go 64M video card. I'd missed the fact, now
apparently well-known, that the VESA VBE didn't have a mode for 1280x800 (the
16:10 LCD resolution), and that the nv driver would corrupt the video modes such
that you coulnd't switch back to text mode: the text mode would be garbled, and
there was no known way to recover from that, other than a reboot. Switching
back to the nv-started graphics mode still worked.
After some investigation, I found out that, having an external monitor connected
to the system, even if turned off, the problem would not occur: text mode would
work just fine. After that, even if you disconnected the monitor, everything
would keep working, until the next reboot.
I also found out that Fn-F4, the hotkey (only visible to the BIOS) used to
switch between internal, external, both or none displays when using VESA video
modes, had no effect when the external monitor was not connected. Actually,
*almost* no effect, as you'll see below. The information that follows applies
to the case of not having an external monitor connected, and not ever having had
one since the last reboot.
As it turns out, if you press this hotkey after a reboot *before* the nv driver
ever starts, the corruption problem does not occur any more, until you reboot.
If you start the nv driver without having pressed this key, stop X, then blindly
start X with the vesa driver, the graphics mode will be garbled as well, but
pressing Fn-F4 while in this garbled graphics mode, and then switching to text
mode (either by terminating X or by pressing Ctrl-Alt-F1), the problem is fixed
The problem is not fixed, however, by pressing Fn-F4 while in a graphics mode
started by the nv driver, nor is it fixed by pressing Fn-F4 in text mode after
the nv driver started. It has to be either before nv ever starts, or in a vesa
graphics mode. From then on, one can use the nv driver as many times as wanted,
without video mode corruption.
I've talked to Mike Harris, and he says this might be a bug in the BIOS, that
fails to initialize the video card completely, but also in the nv driver, that
doesn't completely initialize it either. Fn-F4 would actually take the final
initialization step (probing for an external monitor?). I don't quite see why,
then, Fn-F4 wouldn't fix the problem from a corrupted text mode, but would from
a corrupted graphics mode. Not that I know a lot about video modes and video
cards, mind you :-)
I hope this information helps figuring out what could possibly be wrong.
Mike had suggested me to post differences between Xorg.0.log before and after
fixing the problem. The only line that changes is the one that contains the log
file name and the timestamp. The log file after the problem is fixed contains
an additional line, however, that says:
@@ -488,6 +488,7 @@
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.
(II) NV(0): ... none found
+(--) NV(0): CRTC 1 is currently programmed for DFP
(**) NV(0): Forcing display type to DFP as specified
(**) NV(0): Forcing CRTCNumber 1 as specified
(II) NV(0): Using DFP on CRTC 1
Yes, my config file specifically chooses display #1 and says it's a DFP. The
complete config file is available from the web page in the URL: field.
I too observe this problem with my HP Pavilion zv5000z (HP produces similar
machines with several different names and model numbers).
If I do a "modprobe rivafb" before starting X, the problem is eliminated. In
fact, the modprobe can recover from the problem after it has happened.
I just did:
1) startx; text consoles are now scrambled
2) shut down X
3) modprobe rivafb; text console becomes unscrambled
5) shut down x
The differences between the two /var/log/Xorg.0.log files:
-(II) PCI: stages = 0x03, oldVal1 = 0x80010004, mode1Res1 = 0x80000000
+(II) PCI: stages = 0x03, oldVal1 = 0x800000fc, mode1Res1 = 0x80000000
+(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
+(II) Mouse0: ps2EnableDataReporting: succeeded
This seems to have been fixed in Fedora Core 3's update of X to what they call
6.8.2-1. I presume that the fix came from upstream (xorg). Thanks!
Also fixed in xserver-xorg 6.8.2.dfsg.1-0pre1v1 for Debian, which are the
packages that are supposed to go into experimental.
X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-0pre1v1 20050623145528
Release Date: 9 February 2005