Escalated to Bugzilla from IssueTracker
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.
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.
Adam Jackson waiting for updated MGA driver from Matrox. Plans to include in U8.
(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.
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).
That's all of the -100.EL rpms :)
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
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.
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
File uploaded: XFree86.0.log This event sent from IssueTracker by ltroan issue 88935 it_file 57774
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
Created attachment 126444 [details] XFree86.0.log
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
(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.
(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?
Hello Adam. The customer reports: This is a transient phenomenon. It stops immediately when the Window movement stops.
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.
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.
(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.
(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?
*** Bug 186939 has been marked as a duplicate of this bug. ***
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