Bug 63005 - RFE: monitor DDC probing fails in kickstart install with monitor missing from the database
RFE: monitor DDC probing fails in kickstart install with monitor missing from...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
Blocks: 61590
  Show dependency treegraph
Reported: 2002-04-09 01:24 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.105-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-05 11:17:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2002-04-09 01:24:27 EDT
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):

How reproducible:

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

Additional info:
Comment 1 Michael Fulbright 2002-04-09 12:50:07 EDT
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?
Comment 2 Alexandre Oliva 2002-04-09 14:17:51 EDT
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.
Comment 3 Michael Fulbright 2002-04-09 14:55:25 EDT
Let know what you find out and I'll look into it more.
Comment 4 Alexandre Oliva 2002-04-09 18:25:01 EDT
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.
Comment 5 Michael Fulbright 2002-04-10 12:39:44 EDT
Thanks I'll check into this further.
Comment 6 Michael Fulbright 2002-04-10 14:05:28 EDT
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?
Comment 7 Alexandre Oliva 2002-04-10 16:32:24 EDT
Yeah, they were incorrect, I'm afraid.

What I got from the kickstart install was:

        HorizSync   31.5-37.9
        VertRefresh 50.0-61.0

whereas with a manual install I (believe I) get this:

        HorizSync   30 - 92
        VertRefresh 50 - 160
Comment 8 Jeremy Katz 2002-04-10 17:52:33 EDT
If you run ddcprobe, do you actually get the correct values?
Comment 9 Alexandre Oliva 2002-04-10 17:56:40 EDT
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.
Comment 10 Alexandre Oliva 2002-04-10 18:02:36 EDT
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.
Comment 11 Alexandre Oliva 2002-04-10 18:19:51 EDT
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
Comment 12 Alexandre Oliva 2002-04-10 18:44:42 EDT
Same problem with text-mode kickstart install.  Haven't tried lowres or nofb,
but I suspect the same problem would occur.
Comment 13 Michael Fulbright 2002-04-15 19:45:06 EDT
This works in text mode for me.
Comment 14 Alexandre Oliva 2002-07-31 18:03:12 EDT
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.
Comment 15 Alexandre Oliva 2002-08-01 13:00:11 EDT
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.
Comment 16 Alexandre Oliva 2003-02-17 16:42:19 EST
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.
Comment 17 Alexandre Oliva 2003-06-17 14:33:07 EDT
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?
Comment 18 Michael Fulbright 2003-06-18 16:33:35 EDT
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.
Comment 19 Alexandre Oliva 2003-10-19 16:44:46 EDT
Apparently we are not.
Comment 21 Jaakko Heinonen 2003-10-21 06:14:32 EDT
> 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.
Comment 22 Bill Nottingham 2004-01-29 01:06:00 EST
Added, will be in 1.105-1.
Comment 23 Alexandre Oliva 2004-02-13 11:32:08 EST

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.  

Oops :-)
Comment 24 Bill Nottingham 2004-02-13 15:30:57 EST
Fixed in CVS, please kick if not rebuilt before FC2. :)
Comment 25 Jaakko Heinonen 2004-02-13 18:29:55 EST
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.
Comment 26 Alexandre Oliva 2004-02-13 21:49:35 EST
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 :-(
Comment 27 Alexandre Oliva 2004-02-20 22:58:37 EST
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.
Comment 28 Alexandre Oliva 2004-02-24 16:30:53 EST
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
updates filesystem?
Comment 29 Jeremy Katz 2004-03-04 18:18:16 EST
Yeah, you can put any of the files from hwdata in an updates.img
Comment 30 Alexandre Oliva 2004-04-21 09:36:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.