Bug 70190 - Installer creates wrong monitor values for hsync/vrefresh in /etc/XF86Config
Installer creates wrong monitor values for hsync/vrefresh in /etc/XF86Config
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kudzu (Show other bugs)
8.0
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
Brock Organ
:
Depends On:
Blocks: 67217 70186
  Show dependency treegraph
 
Reported: 2002-07-30 19:19 EDT by Need Real Name
Modified: 2007-04-18 12:44 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-28 18:01:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
[installer] failed start of graphical installer (same happens after installation) -> X.log (1.20 KB, text/plain)
2002-08-06 16:24 EDT, Need Real Name
no flags Details
output from "lspci -vv" (7.59 KB, text/plain)
2002-08-06 16:26 EDT, Need Real Name
no flags Details
output from "lspci -vvn" (6.74 KB, text/plain)
2002-08-06 16:26 EDT, Need Real Name
no flags Details
Patch for kudzu (448 bytes, patch)
2002-09-14 08:37 EDT, Miloslav Trmac
no flags Details | Diff

  None (edit)
Description Need Real Name 2002-07-30 19:19:51 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
horizontal frequencies.

even if you edit the suggested values, the /etc/X11/XF86Config gets the wrong
values.
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
something more


Version-Release number of selected component (if applicable):


How reproducible:
Always

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
values
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.

Additional info:

This Bug report applys to RedHat 7.3.93 (Limbo)

In RedHat 7.3 (Valhalla) X11 configuration with text installer worked correctly.
Comment 1 Need Real Name 2002-08-06 16:21:46 EDT
The X11 configuration tool suggests the folling values HorizSync/VertRefresh

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync   -268377405--268374161
        VertRefresh -268374161--268370092
        Option "dpms"
        DisplaySize    270.933333333 203.2
EndSection

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.
Comment 2 Need Real Name 2002-08-06 16:24:12 EDT
Created attachment 69169 [details]
[installer] failed start of graphical installer (same happens after installation) -> X.log
Comment 3 Need Real Name 2002-08-06 16:26:12 EDT
Created attachment 69170 [details]
output from "lspci -vv"
Comment 4 Need Real Name 2002-08-06 16:26:39 EDT
Created attachment 69171 [details]
output from "lspci -vvn"
Comment 5 Michael Fulbright 2002-08-06 19:05:52 EDT
I've added more checking which should avoid this case completely.
Comment 6 Need Real Name 2002-08-20 15:06:36 EDT
still the same problem in Version 7.3.94 (null)
Comment 7 Miloslav Trmac 2002-09-13 20:56:10 EDT
Happens for me too, running ddcprobe from (null) [admittedly against
kudzu-0.99.52-1 from 7.3] gives:
Monitor DDC probe results
ID: ACTb013
Name: peacock
Width (mm): 320
Height(mm): 240


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)
tomorrow.
Comment 8 Miloslav Trmac 2002-09-14 08:36:43 EDT
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?)
Comment 9 Miloslav Trmac 2002-09-14 08:37:55 EDT
Created attachment 76144 [details]
Patch for kudzu
Comment 10 Need Real Name 2002-11-28 18:04:27 EST
OK. problem solved.

Installed Red Hat Linux 8.0 today without this issue.

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