From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401
Description of problem:
It appears that anaconda probes the monitor too late in the install process,
when it has already entered power-saving mode. The result is an incorrect
detection of the monitor, with excessively conservative values being used.
It would be nice if the monitor would be taken out of power-saving mode before
it is probed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.create a kickstart file with monitor auto-detection and with a number of
packages large enough to get the monitor to enter power saving mode before it is
2.fire up the installer
3.check the probed settings after installation
Actual Results: the probed vertical and horizontal frequencies are very limited
Expected Results: same as I get with an interactive install
The monitor is probed immediately after the first stage loader starts the second
stage (right before 'Red Hat' splash screen is seen). You can see the message
'Probing for Monitor' appear as it is happening.
What type of video card and monitor do you have, and do you have a kvm?
Hmm... You're right, I remember having seen the monitor and mouse probing
messages in interactive installs, but I was probably not paying attention when
doing the kickstart installs. I'll try again soon.
Anyway, the monitor is a Philips Brilliance 107P, and the video card is an
NVidia RIVA TNT2. Both are probed correctly and I get the correct settings when
doing interactive installs, but not when doing kickstart installs.
In interactive installs, I get the choice to bump up the resolution up to
1600x1200, even though both the video card and the monitor can go up to
1920x1440, which is actually what I use, but can't choose in the kickstart file
because it says it would take up too much video memory, and can't choose in
interactive install because it doesn't offer me the option; I always have to
tweak XF86Config-4. Should I file a separate bug report?
In a kickstart installation, the XF86Config-4 file has the resolutions I
requested (1600x1200 on one machine, 1280x1024 on another), but when booting up,
the system comes up with 800x600 because the frequency ranges were mis-detected.
I'll try to do some more investigation.
Let know what you find out and I'll look into it more.
Ok, so monitor probing does occur, and it works as far as the graphical
installer goes, but it does not seem to affect the generated XF86Config-4 file
that goes in the installed system. The same conservative settings still make it
there, which seems to imply to me that the probed monitor values are not being
used to create the installed X configuration file.
Oh, and it has nothing to do with the monitor getting into power-saving mode.
I've just completed an installation in which I kept the monitor awake all the
time, and it made no difference.
FWIW, here's the tail of ks.cfg:
#XWindows configuration information
#Probe for video card
#Probe for monitor
xconfig --depth 16 --resolution 1152x864 --defaultdesktop=GNOME --startxonboot
@X Window System
XF86Config-4 has configuration bits for the TNT2 card, but not for the `PHILIPS
107P' monitor that is probed in the beginning of the installation.
Oh, I failed to mention before: I don't have a kvm.
Thanks I'll check into this further.
I did an install today with kickstart and it put the proper HorizSync and
VeryRefresh for my monitor. It did not actually put in the monitor name, but
the numerical values were correct.
Could you confirm that the numerical values are incorrect?
Yeah, they were incorrect, I'm afraid.
What I got from the kickstart install was:
whereas with a manual install I (believe I) get this:
HorizSync 30 - 92
VertRefresh 50 - 160
If you run ddcprobe, do you actually get the correct values?
Just to confirm that, with a manual install, the DDC Probed Monitor is PHLe002,
with the sync rates above.
And yes, ddcprobe (both the one in 7.2 and the one in the skipjack-beta2
installation media) report the correct sync rates.
This is the line I get in /root/anaconda-ks.cfg after a manual install:
xconfig --card "RIVA TNT2" --videoram 32768 --hsync 30-92 --vsync 50-160 --resol
ution 1152x864 --depth 16
and this is what I get in anaconda-ks.cfg after a kickstart install:
xconfig --card "RIVA TNT2" --videoram 32768 --hsync 31.5-37.9 --vsync 50.0-61.0
--resolution 1152x864 --depth 16
when the original kickstart file had:
xconfig --depth 16 --resolution 1152x864 --defaultdesktop=GNOME --startxonboot
Just to make sure we're all on the same page, I'm installing from the CD-ROM,
with the kickstart file on a floppy disk.
Just verified that, if I put in the information probed detected during the
manual install in the kickstart file used for installation, it configures X11
Same problem with text-mode kickstart install. Haven't tried lowres or nofb,
but I suspect the same problem would occur.
This works in text mode for me.
This is back in limbo (2). I haven't tried anything else since valhalla, but I
found out that the kickstart file I used in my last attempt to duplicate the
problem actually had the correct monitor info, so it wouldn't have failed
anyway. I.e., the problem apparently never went away.
It doesn't matter whether it's an interactive or non-interactive kickstart
install: the DDC probes come up with the wrong values, even though the monitor
name is correct, and DDC probing gets the right info in redhat-config-xfree86.
In an interactive kickstart install, however, the probed values are wrong.
I've just given it a try with the current tree, and I found out why it comes up
with the wrong monitor values. In VT3, I see the following lines:
* Couldnt lookup monitor type PHILIPS 107P
* Could not probe monitor, and no fallback specified.
* Falling back to Generic VGA monitor
* Resolution reqeust 1152x864 is not supported.
* Falling back to 800x600.
It did manage to probe the monitor type, since the kickstart xconfig line was just:
xconfig --resolution 1152x864 --depth 24 --startxonboot --defaultdesktop gnome
I.e., no reference to PHILIPS 107P, that it successfully probed before starting X.
Could it just be that hwdata MonitorsDB is missing a line like this:
Philips; Philips 107P; phle002; 30.0-92.0; 50.0-160.0; 1
? Does anaconda use hwdata at all, or am I looking at the wrong database?
It wouldnt hurt to have this added to the database. However if we cannot find it
in the database we should be using the values ddcprobe returned.
Apparently we are not.
> However if we cannot find it in the database we should be using the values
> ddcprobe returned.
Confirmed to be a problem in RedHat Linux 9 and Fedora Core test3.
Added, will be in 1.105-1.
Unfortunately, there was a typo introduced in the database that was
not in the entry I proposed above. There's a comma separating
HorizSync from VertRefresh in the database, and this causes anaconda
to add two HorizSync entries and leave VertRefresh as 1-1.
Fixed in CVS, please kick if not rebuilt before FC2. :)
As far as I understood you added the Philips monitor entry but the
real problem was not fixed. The problem was that anaconda doesn't use
the values from DCC probe if a monitor is missing from the database.
Good point. I'm reopening it such that the real problem is tracked.
Too bad I'll no longer have an easy way to test it :-(
notting> Fixed in CVS, please kick if not rebuilt before FC2. :)
It was rebuilt, 1.105-1.1 is available, but it still has the typo.
Typo fixed in hwdata 0.109-1. Probing issue, status unknown. Any way
I can possibly test it now that this patch is applied? E.g., could I
remove the monitor entry from the hardware database in an installer
Yeah, you can put any of the files from hwdata in an updates.img
Ok, if the root directory of updates.img is the right place for a
MonitorsDB without the entry that would have matched, then the problem
is indeed fixed. If not, please let me know what is, and I'll
eventually test it again.