Bug 183388 - Matrox Driver Integration to RedHat Distribution
Matrox Driver Integration to RedHat Distribution
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: XFree86 (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
David Lawrence
: Desktop, FutureFeature
: 186939 (view as bug list)
Depends On:
Blocks: RHEL3U8CanFix 185135 185138 186939
  Show dependency treegraph
 
Reported: 2006-02-28 14:48 EST by Issue Tracker
Modified: 2010-10-22 00:19 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHEA-2006-0461
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-20 10:34:19 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.0.log (38.61 KB, text/plain)
2006-03-21 19:01 EST, Larry Troan
no flags Details

  None (edit)
Description Issue Tracker 2006-02-28 14:48:24 EST
Escalated to Bugzilla from IssueTracker
Comment 2 Larry Troan 2006-02-28 14:51:46 EST
Escalating this to bugzilla for tracking purposes. 

Not putting it on RHEL3U8Proposed because there is no current open source
solution for RH to include the MGA driver in RHEL3.  
Comment 5 Larry Troan 2006-03-02 13:54:40 EST
DESCRIPTION:

Some new generation hardware uses the Matrox Pilot graphics controller from
ServerEngines and will be offered with both Red Hat RHEL3 and RHEL4. 

ServerEngines explains that the standard VESA driver has big disadvantages
against the Matrox G200e mga driver so it is important for vendors using this
hardware to use the Matrox driver. 

This means RHEL3 U8 should include this driver since RHEL3 will be going into
maintenance shortly.  A separate distribution and installation of the Matrox
driver based on RHEL3 U8 will be very difficult to handle for us and for our
customers. A Matrox driver integration to the RedHat distribution is therefore
also important for RedHat 3.0 U8.
Comment 8 Larry Troan 2006-03-02 14:12:23 EST
Adam Jackson waiting for updated MGA driver from Matrox. Plans to include
in U8.
Comment 15 Adam Jackson 2006-03-13 15:55:56 EST
(In reply to comment #14)
> Adam,
> 
> Per your comment #11 and comment #13, are there specific rpm's on porkchop we
> need to make available to Fujitsu-Siemens for testing? All of the -100.EL's?
> More? Less?

Everything in -100.EL, yes.  It's not sufficient to update just the server
component because it will attempt to pull in the -100.EL version of the libs
too, etc.
Comment 16 Larry Troan 2006-03-13 16:08:53 EST
Adam has a set of test Xfree86 rpm's that contain the new Matrox mga driver at 
http://people.redhat.com/ltroan/fixes/RHEL3U8G200e/

I asked him for clarification as to which rpms are required -- Per his comment
#15 above, all of the 1000.EL rpms are required. 

Adam reports one problem has been reported with this code:
> there is a noticable delay during server startup during memory sizing 
> (~15 seconds!), but otherwise works fine in limited testing.  

Please test and respond with comments here. Recommend you test with the latest
RHEL3 U6 or U7 code loaded on your system. Note that RHEL3 U7 is due out on RHN
tomorrow (Tuesday, 3/14).
Comment 17 Larry Troan 2006-03-13 16:12:10 EST
That's all of the -100.EL rpms :)
Comment 18 Issue Tracker 2006-03-20 07:59:42 EST
Have you (Adam, that is) pushed the mga patch to x.org already? If yes, can
you give us a reference to the patch on an x.org mailinglist or similar?


Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by ltroan 
 issue 88935
Comment 19 Larry Troan 2006-03-20 08:23:03 EST
Per my comment #16 and comment #17 above, patched files for XFree86 are on my
people page http://people.redhat.com/ltroan/fixes/RHEL3U8G200e/ and Adam would
like you to test them. He had not submitted the corresponding RHEL4U4 (xorg)
patches as of 3-13.

Please test and verify these proposed patches provide a functional MGA driver on
RHEL4U7 which was available on RHN on 3-15.

Comment 20 Issue Tracker 2006-03-21 18:56:28 EST
Here is our feedback: 

XFree86-4.3.0-100.EL on EL3.0U7:

Works in general,  but when the X server starts, the monitor shows garbage
for >10s, and the TFT screen complains "frequency out of range". After
that, X works normally. (XFree86.0.log attached). 



Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by ltroan 
 issue 88935
Comment 21 Issue Tracker 2006-03-21 18:56:48 EST
File uploaded: XFree86.0.log

This event sent from IssueTracker by ltroan 
 issue 88935
it_file 57774
Comment 22 Issue Tracker 2006-03-21 18:57:04 EST
Our QA and the ServerEngines colleagues pointed us at the related problem
of making the g200e card known to the system configuration tools, in
particular "system-config-display"  / "redhat-config-display". 

It was reported that these tools, when called, revert a manually fixed
configuration file from "mga" to "vesa" for this chip.




This event sent from IssueTracker by ltroan 
 issue 88935
Comment 23 Larry Troan 2006-03-21 19:01:09 EST
Created attachment 126444 [details]
XFree86.0.log
Comment 24 Larry Troan 2006-03-21 19:11:39 EST
Therewas some confusion about what rpm's to install and in what order off my
people page. Adam responds:

On Mar 21, 2006, at 4:00 PM, Larry Troan wrote:
> Adam,
>
> Can you provide guidance to ServrEngines?
All of these RPMS should be installed simultaneously:
# rpm -Uvh XFree86*4.3.0-100.EL.i386.rpm

- ajax
Comment 25 Adam Jackson 2006-03-21 21:28:20 EST
(In reply to comment #20)
> Here is our feedback: 
> 
> XFree86-4.3.0-100.EL on EL3.0U7:
> 
> Works in general,  but when the X server starts, the monitor shows garbage
> for >10s, and the TFT screen complains "frequency out of range". After
> that, X works normally. (XFree86.0.log attached). 

ah, so it's not just me.  i'd seen this on one machine but matrox hadn't been
able to reproduce it.

the issue occurs, afaict, during the memory sizing probe, where the driver pokes
out into vram at 1k intervals looking for the end of vram.  changing the probe
stride to 4k cuts the startup delay by a bit under a factor of 4 so this seems
pretty likely, and shouldn't cause any major problems since it's unlikely vram
will be sized in less than 4k multiples.  64k would probably be safe for that
matter, as being the vesa bank size i think.

the code i'm pushing to Xorg has the stride changed to 4k, but i'll see if i can
debug it a little closer to figure out why it's even taking that long.
Comment 32 Adam Jackson 2006-04-19 15:43:27 EDT
(In reply to comment #30)
> Hello Adam.
> 
> Customer writes:
> we found another issue with the new driver.
> 
> First, the screen is garbled for ~10s when X is started (this was
> communicated earlier).

This should be sorted in the latest builds.

> Second, the screen displays artefacts when rectangular regions are copied,
> e.g. when moving windows on the screen. The artefacts look like ragged,
> flickering vertical stripes about 60 pixels horizontally apart. They are
> hardly visible at screen refresh rates ~60 Hz, but very annoying at 75 Hz
> and above. The only thing that helps is setting the option
> "XaaNoScreenToScreenCopy", but that makes moving windows very slow.

I'm unable to reproduce this locally.  Might be an issue with running out of
memory bandwidth.  Are these transients or do they stick around when then window
is done moving?
Comment 33 David Juran 2006-04-21 08:24:24 EDT
Hello Adam.

The customer reports:

 This is a transient phenomenon. It stops immediately when the Window movement
stops.
Comment 36 Mike A. Harris 2006-04-25 09:41:18 EDT
XFree86-4.3.0-102.EL is now available for download via ftp
at the following URL:  ftp://people.redhat.com/mharris/testing/3.0E

After upgrading all of the packages, please test the driver as per above
and report back success/failure and any relevent details.
Comment 42 Mike A. Harris 2006-05-04 06:52:55 EDT
XFree86-4.3.0-104.EL is now available for download via ftp at the following URL:
 ftp://people.redhat.com/mharris/testing/3.0E

The problem reported above has been reproduced by Ray Strode in the Westford
office, and a runtime workaround for the problem has been determined.

To apply the workaround, edit the X server config file and add the following
option to the device section of the config file:

        DacSpeed "65"

This has been confirmed to work around this issue.
Comment 54 Zack Cerza 2006-06-26 13:15:51 EDT
(In reply to comment #53)
> Also, I'm not sure if this 'DacSpeed "65"' trick is supposed to work, but if I
> try it here, it prevents X from starting at all.

Apparently the quotes around "65" were the problem. Works as advertised.

Once hwdata is updated, then I can mark VERIFIED.

Comment 55 Mike A. Harris 2006-06-26 18:12:39 EDT
(In reply to comment #54)
> (In reply to comment #53)
> > Also, I'm not sure if this 'DacSpeed "65"' trick is supposed to work, but if I
> > try it here, it prevents X from starting at all.
> 
> Apparently the quotes around "65" were the problem. Works as advertised.
> 
> Once hwdata is updated, then I can mark VERIFIED.

ajax has already committed changes to cvs hwdata for this, however I don't
know if he built a new package and updated errata request, etc.

Ajax?

Comment 63 Larry Troan 2006-07-14 15:15:10 EDT
*** Bug 186939 has been marked as a duplicate of this bug. ***
Comment 64 Red Hat Bugzilla 2006-07-20 10:34:19 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2006-0461.html

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