Bug 107073

Summary: EDID Monitor data produces incorrect Xserver display
Product: Red Hat Enterprise Linux 3 Reporter: John Dennis <jdennis>
Component: XFree86Assignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jeff.burrell
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHEL4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-28 02:29:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
log file when only leftmost pixels are visible
none
log file without monitor attached during init, correct display
none
diff between bad and good log files none

Description John Dennis 2003-10-14 19:48:41 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ia64; en-US; rv:1.4) Gecko/20030922

Description of problem:
This problem was observed on an HP Crestone Peak (ZX4000) IA64 system. It is
unknown at this point if this problem is architecture specific or not.

When the X server comes up only a column of the leftmost (approx) 30 pixels is
visible. It was observed this problem did not manifest itself if during Xserver
initialization the monitor (an HP 2025 Flat Panel) was NOT attached (FYI, this
can be a common occurance when using KVM's). A copy of the XFree86 log file was
captured for both the success and failure cases (attached). It was observed that
only significant difference in the log files was in the failure case EDID
monitor data was read from the monitor. Note, the monitor data cannot be read
from the monitor when the monitor is not attached as would be the case when a
KVM is in use and switched to another system.

The preferred configuration initialization is for the Xserver to "auto"
configure by reading device data reported by the device, therefore the EDID data
should be used, but it appears the EDID data is causing the problem, this makes
this a serious issue because auto configuration produces a non-working system.

Initial analysis of the log files does not reveal how the EDID data is creating
a problem. In both instances the same Horizontal and Vertical frequencies are
being used, there is a difference in the pixel clock, but it looks within range.

Just filing this bug so I can come back to it analyze more fully later.

Version-Release number of selected component (if applicable):
XFree86- 4.3.0-35.EL

How reproducible:
Always

Steps to Reproduce:
see description

Actual Results:  missing 95% of display

Expected Results:  100% of display visible

Additional info:
Comment 1 John Dennis 2003-10-14 19:50:21 UTC 
Created attachment 95173 [details]
log file when only leftmost pixels are visible
Comment 2 John Dennis 2003-10-14 19:51:33 UTC 
Created attachment 95174 [details]
log file without monitor attached during init, correct display
Comment 3 John Dennis 2003-10-14 19:54:34 UTC 
Created attachment 95175 [details]
diff between bad and good log files
Comment 4 Mike A. Harris 2003-10-15 04:23:11 UTC 
Just adding this here for easy reference when bug scanning..

(--) RADEON(0): Chipset: "ATI FireGL Z1/X1 AG (AGP)" (ChipID = 0x4147)
Comment 5 Mike A. Harris 2005-09-28 02:29:07 UTC 
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to Red
Hat Enterprise Linux 4.

Setting status to "CURRENTRELEASE".