Bug 74796 - (G550) anaconda graphic install corruption
(G550) anaconda graphic install corruption
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks: 82777
  Show dependency treegraph
 
Reported: 2002-10-01 15:12 EDT by Joe Ceklosky
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-24 13:49:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XFree86 log file (22.56 KB, text/plain)
2002-12-07 19:09 EST, Anders Montonen
no flags Details
XF86Config and logs (12.47 KB, application/octet-stream)
2003-01-01 11:30 EST, Anders Montonen
no flags Details

  None (edit)
Description Joe Ceklosky 2002-10-01 15:12:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; SunOS 5.8 sun4u)

Description of problem:
During a graphics based install with a Matrox G550 the screen display is
'unstable'.  The sides are wiggling and the display cuts in and out.  The
install is fine and the normal X server is fine once installed.  It appears like
anaconda is using a BAD timing value.  I an using a Nanao T2-17-TS monitor
during the install

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


How reproducible:
Always

Steps to Reproduce:
1.Install redhat 8.0 in graphic mode
2.
3.
	

Expected Results:  stable screen display

Additional info:

The install is fine, but the screen 'wigs' out every once in a while.
Text mode install is OK as a work around.
Comment 1 Michael Fulbright 2002-10-02 15:13:56 EDT
Mike did you see problems testing with your G550?
Comment 2 Mike A. Harris 2002-10-06 01:07:00 EDT
I haven't tested the G550.  I will do so, and try to reproduce however.
Comment 3 Mike A. Harris 2002-11-24 04:47:43 EST
Please attach config+log file.
Comment 4 Joe Ceklosky 2002-11-24 08:15:38 EST
The problem is with the graphic anaconda install, NOT once it's installed.
I think you already have the X11 config file it's using for the install, right?
Comment 5 Anders Montonen 2002-12-07 19:09:49 EST
Created attachment 87844 [details]
XFree86 log file
Comment 6 Anders Montonen 2002-12-07 19:11:13 EST
I think I have the same problem. When using any resolution other than 1024x768
or 1600x1200 XFree86 will use some monitor timings it invented regardless of
default modes or XF86Config settings. For example, I have in my XF86Config the
following modeline:
ModeLine     "1280x1024" 157.5 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync
which *should* give me a 1280x1024 screen using a horizontal frequency of 91kHz
and a vertical frequency of 85Hz. Instead, I get 113kHz/105Hz (which my monitor
can't handle). I get this mode for that resolution regardless of the contents of
my XF86Config file, even limiting the max vertical frequency doesn't help. The
logfile doesn't show anything unusual either, at least to my eyes.
Comment 7 Mike A. Harris 2002-12-15 05:00:29 EST
Sorry, but XFree86 doesn't "invent" mode timings.  The XFree86 X server is
compiled with built in modelines that are generated from VESA GTF standard
official modeline timing values.  These *are* the default modes.  It does
not use any other modes unless they are added to the X server at compile
time, or in the config file at run time.

I'm unable so far to reproduce any problem.  You may wish to report this
to the xpert@XFree86.org mailing list for discussion and/or the
xfree86@xfree86.org bug report address for developer attention.

Also, you did not supply your config file as I had asked above.

The attached log file looks hand edited.  Please provide the correct
up to date complete log file, and config file, so that I can see the entire
thing and know that my local testing is using an identical setup.  Also
attach your /var/log/messages.
Comment 8 Anders Montonen 2003-01-01 11:29:06 EST
"Sorry, but XFree86 doesn't "invent" mode timings."

Well, it definitely doesn't use the autoprobed timings *or* those found in
/etc/X11/XF86Config.

"I'm unable so far to reproduce any problem.  You may wish to report this
to the xpert@XFree86.org mailing list for discussion and/or the
xfree86@xfree86.org bug report address for developer attention."

I may have to do that, but IME most projects say "it's a vendor problem, don't
talk to us." FWIV, I have no problems whatsoever under Windows 2000.

"The attached log file looks hand edited."

I assure you it was not.

"Please provide the correct up to date complete log file, and config file, so
that I can see the entire thing and know that my local testing is using an
identical setup.  Also attach your /var/log/messages."

Will do. The system log shows a session where I started the machine after
applying the latest errata (as of jan-01-2003), ran redhat-config-xfree86 to
select the 1280*1024 resolution, opened a root session on a second console and
in the first console started XFree86 and shut it down again. According to my
monitor's OSD, the hfreq/vfreq actually used was 114kHz/106Hz.
Comment 9 Anders Montonen 2003-01-01 11:30:23 EST
Created attachment 89035 [details]
XF86Config and logs
Comment 10 Mike A. Harris 2004-09-24 13:49:14 EDT
We believe this issue to be resolved in our currently shipping
OS releases.  Please upgrade to Fedora Core 2 or later, and if this
issue turns out to still be reproduceable, please file a bug report
in the X.Org bugzilla located at http://bugs.freedesktop.org in the
"xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.



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