Red Hat Bugzilla – Bug 70190
Installer creates wrong monitor values for hsync/vrefresh in /etc/XF86Config
Last modified: 2007-04-18 12:44:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724
Description of problem:
graphic card: nvidia geforce 2 mmx
monitor: belinea 106020
manual X11 configuration with anaconda suggests wrong values for vertical and
even if you edit the suggested values, the /etc/X11/XF86Config gets the wrong
after installation the first thing to do is to edit /etc/X11/XF86Config and edit
the monitor settings to the correct values. For the belinea 106020 this would be
30-96kHz for hsync and 50-160Hz for vrefresh -- the installer has inserted
totally wrong values: from minus 2 million something to minus 2 million and
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install RedHat Linux with bootable CDROM
2.use "linux text" for installation
3.select new installation
4.dont select any special in menus, only accepting defaults
5.set up X11 configuration
6.dont accept suggested values and set the correct ones
Actual Results: in /etc/X11/XF86Config hsync and vrefresh contain both negative
X11 checks the sanity of its monitor values before it starts -- so no monitor
should be harmed through this massively wrong values. also the Xserver isnt able
to start so you have to edit XF86Config by hand and edit the wrong monitor values.
Expected Results: the X11 configuration tool should suggest sane values (minus
two million something _is_ insane) and if the user edit these values by hand (in
the text installer) then the edited values have to be used and not the
pre-edited insane values.
This Bug report applys to RedHat 7.3.93 (Limbo)
In RedHat 7.3 (Valhalla) X11 configuration with text installer worked correctly.
The X11 configuration tool suggests the folling values HorizSync/VertRefresh
VendorName "Monitor Vendor"
ModelName "Monitor Model"
DisplaySize 270.933333333 203.2
X11 doesn't accept negative values and after installation you aren't able to
boot into X or even start X if you don't alter /etc/X11/XF86Config manually.
This Bug is somehow linked to bug 70186 in which the attempt to start the
graphical installation tool failed.
Created attachment 69169 [details]
[installer] failed start of graphical installer (same happens after installation) -> X.log
Created attachment 69170 [details]
output from "lspci -vv"
Created attachment 69171 [details]
output from "lspci -vvn"
I've added more checking which should avoid this case completely.
still the same problem in Version 7.3.94 (null)
Happens for me too, running ddcprobe from (null) [admittedly against
kudzu-0.99.52-1 from 7.3] gives:
Monitor DDC probe results
Width (mm): 320
The workaround added on Aug 6 is irrelevant (checks only in the x config screen,
long after the XF86Config for running GUI installer has been created);
I'll try the workaround added on Aug 21 (monitor.py from rawhide rhpl-0.51)
OK, I found it. Not all strange things are hardware bugs...
In my case, as can be confirmed by running ddcprobe from 7.3 (the binary,not the
python script), the monitor doesn't supply the frequency ranges via ddc. In
7.3., anaconda used this ddcprobe and parsed its output (correctly).
In (null), frequency ranges support was added to kudzu and the original
dcprobewas replaced by a python script calling kudzu. The code added to kudzu
is wrong and accesses a NULL pointer when the monitor doesn't return the
frequency range AND the monitor is not in MonitorsDB. Under normal conditions
it would segfault, alas ddc probing is done by calling the BIOS in vm86 mode,
which maps stuff at virtual address 0, so kudzu continues and returns rubbish.
Please reassign this bug to kudzu, patch attached (or is there any procedural
reason why should I file a new bug about this?)
Created attachment 76144 [details]
Patch for kudzu
OK. problem solved.
Installed Red Hat Linux 8.0 today without this issue.