From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020625
Description of problem:
Feedback on video during install was requested in release notes:
On my NVidia GeForce 2MX, video became garbled during the installation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Install from CDROM. Leave system idle during package installation. Video
became garbled (actually looked like it had zoomed in to a small area in the
center of the screen). I believe that I switched to a tty and back to correct
00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP]
00:0c.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100
model NC100 (rev 11)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 18)
00:11.3 USB Controller: VIA Technologies, Inc. USB (rev 18)
00:11.4 USB Controller: VIA Technologies, Inc. USB (rev 18)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio
Controller (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX] (rev b2)
Did the screensaver kick in by chance?
Well, moving the mouse didn't cause the display to correct itself. I'm pretty
sure that I had to switch VC's (there and back again) to fix the display. I
thought that there was no screensaver running during the install?
I can't find the bug # with text mode installs colors being wrong.
Just wanted to mention it's still wrong in limbo2
Could you do the following?
1) Boot into install and make sure display is garbled.
2) Put in a blank floppy.
3) mke2fs /dev/fd0
4) mkdir /tmp/a
5) mount /dev/fd0 /tmp/a
6) cp /tmp/XF86Config.text /tmp/a
7) umount /tmp/a
and then attach the file from the floppy to this bug report?
Created attachment 71824 [details]
XF86Config from install
During four installs (one upgrade, three clean), I've only seen the screen
garble once. This is the config file from the last install. (I thought I'd not
selected "sometimes" reproducable)
We've seen this to, but it surely is a X server bug.
Not sure there is much we can do to fix since its so intermittant.
Any video driver related problems need to be reproduceable without
the installer in order to effectively debug them.
Using the "nv" driver with the config file that anaconda uses during
install, can you reproduce this at all in any way? If you can cause
it to happen even intermittently, we may be able to troubleshoot
it and workaround.
Without a way of easily reproducing it though, as msf says, it isn't
likely very resolveable.
Can do. I'll start using that config file tomorrow. Primarily the difference
between the .test and the one I'm using now is the presence of "DisplaySize" in
the .test file, the bit depth, and the resolutions available.
Should I go so far as to actually run in 800x600?
Curiosity forces me to ask:
Where did the DisplaySize setting in the XF86Config.test file come from? It's
nowhere near accurate for my monitor, and seems like it could be left out.
Also, "dpms" may not be appropriate for the OS installation. Users might not
expect it at that point; they may think that it has too much computer in it, and
not enough installer.
The DisplaySize option is put in the config file by anaconda as far
as I know. I don't know what the reasoning for it is however, so
I'll leave that to msf or jeremy to answer.
>Also, "dpms" may not be appropriate for the OS installation. Users
>might not expect it at that point; they may think that it has too
>much computer in it, and not enough installer.
The above paragraph makes absolutely no sense to me. Can you repeat
that in easily digestible English perhaps?
Sorry. I meant that most installers don't turn off the monitor during
installation. It's probably no big deal... I just thought it might be
unexpected for the monitor to go into power saving state while the installer was
Not sure why DPMS would be getting activated at installation time, but
it wouldn't likely be an XFree86 bug. It would more likely be an installer
bug, but that wouldn't be related to video garbling during installation,
so that would qualify as a separate bug report.
I'm unable to acquire documentation from Nvidia however to understand
how their chips work. This issue will require Nvidia to troubleshoot the
driver and fix it.
Please test this video card with Red Hat Linux 9 and if the problem persists,
it is recommended that you file a bug report at http://bugs.xfree86.org
which will get to the nv driver maintainer whom works right at Nvidia.
Please indicate if it works or not, and if not, add a link here to your
upstream bug report so I can track the issue upstream and backport any
fixes that may be made by the maintainer.
I haven't been able to reproduce the problem.
Ok, thanks for the update. Closing CURRENTRELEASE of Red Hat Linux 9