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