Bug 163331 - display corrupt on matrox mga g450 g550
display corrupt on matrox mga g450 g550
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
: 159838 160420 160784 161215 162699 163453 163674 166530 167497 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-15 03:16 EDT by Iain Arnell
Modified: 2007-11-30 17:11 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-12 14:03:11 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)
screenshot exhibiting the problem (330.12 KB, image/png)
2005-07-22 11:12 EDT, Iain Arnell
no flags Details
log from (broken) xorg-x11-6.8.2-43 (39.91 KB, text/plain)
2005-07-22 11:14 EDT, Iain Arnell
no flags Details
log from (working) xorg-x11-6.8.2 without troublesome patch (39.91 KB, text/plain)
2005-07-22 11:15 EDT, Iain Arnell
no flags Details
Experimental patch to fix linux-native-pci-scan (3.52 KB, patch)
2005-07-24 06:59 EDT, Olivier Baudron
no flags Details | Diff
Experimental patch to fix linux-native-pci-scan (v2) (3.58 KB, patch)
2005-07-24 08:14 EDT, Olivier Baudron
no flags Details | Diff
Experimental patch to fix linux-native-pci-scan (v3) (3.58 KB, patch)
2005-07-25 04:59 EDT, Olivier Baudron
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 2880 None None None Never

  None (edit)
Description Iain Arnell 2005-07-15 03:16:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050704 Firefox/1.0+

Description of problem:
This is NOT bug 161242 - it is Mike's "scenario C".  

Video adapter is a Matrox G400.

After updating from 6.2.8-13 to 6.2.8-18 many months ago, the display became
corrupt and unusable.  Upgrading to 6.2.8-43 does not solve the issue.

To analyse the problem, I installed the 6.2.8-13 binaries from rawhide (saved
from yum cache).  This works fine.

I then rebuilt 6.2.8-13 using mock with fc4 configuration.  This also works fine.

Installing 6.2.8-18 binaries from rawhide causes the problem to appear.

I rebuilt 6.2.8-18 using mock, the problem still appears.

Checking the difference between releases 13 and 18, I see that the only 
significant change was the introduction of patch 9502 - 
xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch

Rebuilding 6.2.8-18 without this patch fixes the problem.

This problem may be https://bugs.freedesktop.org/show_bug.cgi?id=3096

Version-Release number of selected component (if applicable):
xorg-x11-6.2.8-18 -> 43

How reproducible:
Always

Steps to Reproduce:
1. install xorg-x11-6.2.8-18 or higher


Actual Results:  display corrupt

Expected Results:  display not corrupt

Additional info:
Comment 1 Iain Arnell 2005-07-15 04:03:21 EDT
Also, rebuilding 6.2.8-43 without the native-pciscan patch works.
Comment 2 Iain Arnell 2005-07-15 04:04:32 EDT
Oops, brain not in gear.  s/6.2.8/6.8.2/ throughout.
Comment 3 Dr J Austin 2005-07-17 09:10:51 EDT
I can confirm that this fixes my Athlon64 Matrox G550 machine
No corruption at either run level 5 Cont/Alt/F7
or at Cont/Alt/F1-6
[root@shuttle33 i386]# rpm -qa|grep ^xorg
xorg-x11-devel-6.8.2-43.jatest
...

This is what I did - I assume this is correct as it works !!!!
Down loaded and installed source rpm
rpm -i xorg-x11-6.8.2-43.src.rpm
Edited /usr/src/redhat/SPECS/xorg-x11.spec
Changed release info
Removed two references to offending patch
#Patch9337: xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch
#%patch9337 -p0 -b .use-linux-native-pciscan-by-default
Then
rpmbuild -bb xorg-x11.spec

reboot to run level 3
rpm --nodeps -e `rpm -qa |grep ^xorg`
cd /usr/src/redhat/RPMS/i386
Install the 18 "new" rpms
rpm -i *.rpm
reboot

Many thanks to Iain and Mike for the secrets.

As only a second time user of rmpbuild can someone
explain how mock becomes involved and can be used to help debugging such problems.
I have read all the rpmbuild man and mock README page and vaguely understand
what is going on but don't know when mock should be used.
Comment 4 Joe Ceklosky 2005-07-17 16:52:23 EDT
All,

Same here I rebuild xorg-x11-38 with the
xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch removed on FC4 
and the G550 is working again.  I am not sure if the BUG is with GCC and this
patch or something else.

Any thoughts from the REDHAT people (mharris?) on the native-pci patch?

Thanks
Comment 5 Joe Ceklosky 2005-07-22 08:18:54 EDT
I rebuilt the xorg-x11-43 with gcc-4.0.1-4 (which include the volitle changes).

This does NOT fix the problem with a Matrox G550 card.  The native-pci scan
continues to be the root cause of the problems with the Matrox card.  I rebuilt
xorg-x11-43 with gcc-4.0.1-4 with the native-pci scan REMOVED and the card works
fine.
Comment 6 Olivier Baudron 2005-07-22 08:57:38 EDT
Iain, I cannot reproduce your problem with my G400. Would you tell me exactly
what the symptoms are? How is the screen after X has started? Does the problem
occur when you switch to a VT?
Comment 7 Dr J Austin 2005-07-22 10:24:10 EDT
Olivier
See bug comment #10 attachment
https://bugs.freedesktop.org/show_bug.cgi?id=2991
which shows the problem on my G550 machine
from April 20th !!
I confirm that removing the native-pci patch fixes the problem

Comment 8 Iain Arnell 2005-07-22 11:12:25 EDT
Created attachment 117065 [details]
screenshot exhibiting the problem
Comment 9 Iain Arnell 2005-07-22 11:14:25 EDT
Created attachment 117066 [details]
log from (broken) xorg-x11-6.8.2-43
Comment 10 Iain Arnell 2005-07-22 11:15:30 EDT
Created attachment 117067 [details]
log from (working) xorg-x11-6.8.2 without troublesome patch
Comment 11 Iain Arnell 2005-07-22 11:41:01 EDT
The problem occurs during boot when X starts up - rhgb, greeter and desktop 
itself are all affected.  Also, simply upgrading from a working release to a 
broken one and restarting X causes problem to appear to.
But upgrading from a broken release to a working one and restarting X does
not cause the problem to go away - reboot is required.
VTs are also affected in a similar fashion if switching after broken X has 
started (ie. boot to runlevel 3, VTs are fine, switch to runlevel 5, VTs are
broken, switch back to runlevel 3, VTs are still broken).
Comment 12 Olivier Baudron 2005-07-22 11:49:12 EDT
It's an SMP machine?
Comment 13 Iain Arnell 2005-07-22 12:01:03 EDT
I should be so lucky.  Single P4:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 1.80GHz
stepping        : 4
cpu MHz         : 1798.805
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes

and

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85)
(prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G450 32Mb SDRAM Dual Head
        Flags: bus master, medium devsel, latency 128, IRQ 10
        Memory at f6000000 (32-bit, prefetchable) [size=32M]
        Memory at f4800000 (32-bit, non-prefetchable) [size=16K]
        Memory at f4000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at f4820000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [f0] AGP version 2.0

hmmn.  Just noticed that subsystem bit - maybe it's really a G450.  I can't
open her up and check the board until Monday
Comment 14 Olivier Baudron 2005-07-24 06:59:08 EDT
Created attachment 117103 [details]
Experimental patch to fix linux-native-pci-scan

Can someone test this patch?
Comment 15 Olivier Baudron 2005-07-24 08:14:47 EDT
Created attachment 117105 [details]
Experimental patch to fix linux-native-pci-scan (v2)

This one is better.
Comment 16 Joe Ceklosky 2005-07-24 09:14:27 EDT
I will test the patch on a G550 car.
Comment 17 Olivier Baudron 2005-07-24 10:01:49 EDT
I forgot to mention that the patch is against -43.
Don't remove linux-native-pci-scan.patch.

Also, if someone wants to test the patched binaries, go there:
http://olivier.baudron.free.fr/RPMS/i386/Test/

I don't have the hardware to reproduce the bug, so I can only certify that it 
does not break my G400.
Comment 18 Joe Ceklosky 2005-07-24 11:46:37 EDT
Oliver,

The native patches do no fix the problems on the G550.
I installed your rebuilts rpm's.

Thanks
Comment 19 Joe Ceklosky 2005-07-24 11:47:51 EDT
Oliver,

That is supposed to read DO NOT

Comment 20 Olivier Baudron 2005-07-24 12:11:17 EDT
Joe, you don't see any change at all? Or is it still broken, but in a different way?
Comment 21 Joe Ceklosky 2005-07-24 12:23:45 EDT
Oliver,

It might be a little better, but there is still corruptions and for example
I see like half of the cursor with corruption as the mouse moves. 

The X mode is messed up as well as the VT.

Comment 22 Olivier Baudron 2005-07-24 12:27:31 EDT
Argh, I have another report at https://bugs.freedesktop.org/show_bug.cgi?id=2880
where the patch works for a G550.

Btw, the problem involves the video bios, so it is necessary to reboot.
Comment 23 Dr J Austin 2005-07-24 14:02:58 EDT
Hi
I have double checked that the extra patch works for me
Athlon64 FC4 i386 G550 (the success of the previous comment)
The rpmbuild directory was as left following successful build

I made just 3 edits to the spec file
bumping the release number
commenting out the 2 lines referring to the new patch

rpmbuild -ba xorg-x11.spec
builds OK in just under 30mins
hundreds(thousands ?) of warnings though !!!!

reboot to run level 3
rpm --nodeps -e `rpm -qa|grep ^xorg`
cd /usr/src/redhat/RPMS/i386
rpm -i *.rpm
reboot

As expected
Corrupt screen at Cont/Alt/F7 and Cont/Alt/F1-6

reboot to run level 3
and restore previously built working rpms
reboot
All is well again !!

I have not down loaded the prebuilt rpms but
can do so if you like

Regards
John
Comment 24 Olivier Baudron 2005-07-24 14:53:37 EDT
Yes, John. Can you please test my binaries rpm? Thanks.
Comment 25 Dr J Austin 2005-07-24 15:54:52 EDT
I'm obsolete !!!! glibc-2.3.5-10
and your rpms require glibc-2.4

Will yum update glibc give me any grief ?

I will have another look tomorrow
John
Comment 26 Iain Arnell 2005-07-25 02:41:52 EDT
I checked - I really have a G450 - sorry for any confusion.

The patch in comment #15 works for me.  Compiled under both gcc-4.0.0-8 and
4.0.1-4.  The prebuilt RPMs are also working fine.  No corruption under X or VTs.
Comment 27 Olivier Baudron 2005-07-25 03:12:37 EDT
Iain, would you change "g400" by "g450/g550" in the summary so that people can
find this bug report more easily.
Comment 28 Olivier Baudron 2005-07-25 04:59:38 EDT
Created attachment 117116 [details]
Experimental patch to fix linux-native-pci-scan (v3)

I messed an interval in pciCfg1outb().
Comment 29 Stewart Adcock 2005-07-25 05:07:22 EDT
*** Bug 161215 has been marked as a duplicate of this bug. ***
Comment 30 Olivier Baudron 2005-07-25 06:24:44 EDT
New binary rpms (-43.ob3) at http://olivier.baudron.free.fr/RPMS/i386/Test/
Comment 31 Iain Arnell 2005-07-25 07:50:43 EDT
Patch from comment #28 is also working fine - fc4 gcc-4.0.0 and rawhide gcc-4.0.1.
The new ob3 binaries are also good for me.
Comment 32 Joe Ceklosky 2005-07-25 08:55:48 EDT
Oliver,
I will retest with the ob3 builds on my G550.
Thanks
Comment 33 Joe Ceklosky 2005-07-25 22:23:05 EDT
Oliver,

Retested on my G550 and we are good to go. Thanks for your work.

One odd not, but I see this also with xorg-x11 the latest from FC3.
I notice an odd flicker on my LCD screen like the refresh rate is too low on the
G550 for the monitor.  When I use the same LCD with an nvida based card it's as
steady as a rock.  Any thoughts on this?
Comment 34 Dr J Austin 2005-07-26 05:33:06 EDT
Hi Oliver
I have tested (rebuilt) linux-native-pci-scan (v3) on
Athlon64 FC4 i386 G550
All is still well
Great
Thanks John
Comment 35 Kristian Høgsberg 2005-07-28 17:51:40 EDT
Olivier, thanks for your great work with this issue.  I've built
xorg-x11-6.8.2-44 in the Red Hat build system with your patch from comment #28
added to xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch.  The new
build should be available in rawhide tomorrow, but I've also put up the RPMs here:

  http://people.redhat.com/krh/xorg-x11-6.8.2-44

so people can try it out right away.
Comment 36 Olivier Baudron 2005-07-29 03:20:51 EDT
Kristian, would you confirm to me that -44 is built with gcc-4.0.1-4 ?
I did not see any reference in the changelog.
This is of course in relation to the bug #161242 saga.
Comment 37 Colin Charles 2005-07-29 05:23:31 EDT
*** Bug 163674 has been marked as a duplicate of this bug. ***
Comment 38 Kristian Høgsberg 2005-07-29 11:17:56 EDT
(In reply to comment #36)
> Kristian, would you confirm to me that -44 is built with gcc-4.0.1-4 ?
> I did not see any reference in the changelog.
> This is of course in relation to the bug #161242 saga.

Yes, -44 is built with gcc-4.0.1-4, which has a patch to revert the volatile
behavior.  Even so, it still has your workaround from comment #63, bug #161242.
 We'll probably drop that workaround soon, but right now the priority is to get
the pci config patch tested.

Btw. the gcc version used is logged in /var/log/Xorg.0.log.
Comment 39 Kristian Høgsberg 2005-07-29 18:05:14 EDT
Well, I went ahead and disabled the volatile workaround patch in the xorg-x11
RPM.  I've removed the RPMs in comment 35 and put up -45 RPMs instead:

  http://people.redhat.com/krh/xorg-x11-6.8.2-45

These will appear in rawhide in a few days.
Comment 40 Leon Flaks 2005-07-30 11:02:27 EDT
It would be nice to have this fix available for FC4 (not only rawhide) Attempt
to install and test it fails due to glibc dependence:
libc.so.6(GLIBC_2.4) is needed by xorg-x11-6.8.2-44.i386
libc.so.6(GLIBC_2.4) is needed by xorg-x11-libs-6.8.2-44.i386

Thanks,

Leon
Comment 41 Olivier Baudron 2005-07-30 12:16:31 EDT
In reply to comment #40:
Fixes need to be tested in rawhide before it can be included in updates. This 
is especially true when the problem is hardware dependant. So, if you can test 
xorg-x11 and glibc from rawhide, your results are welcome!
Comment 42 Dr J Austin 2005-07-30 13:23:00 EDT
Being an inexperienced tester this makes me uneasy !!
Full install of FC4 i386 Athlon64 G550
Is this correct way of doing things ?
Missing dependency !!
Advice please

Down loaded 6.8.2-45 rpms  from (before I knew they were in rawhide)
http://people.redhat.com/krh/xorg-x11-6.8.2-45
cd download directory
yum --enable=development localinstall *.rpm
...
...

---> Package xorg-x11-xdm.i386 0:6.8.2-45 set to be updated
---> Package xorg-x11-sdk.i386 0:6.8.2-45 set to be updated
--> Running transaction check
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
extras                    100% |=========================| 1.1 kB    00:00
updates-released          100% |=========================|  951 B    00:00
base                      100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 1.0 MB    00:14
developmen: ################################################## 3797/3797
Added 3797 new packages, deleted 0 old in 11.48 seconds
primary.xml.gz            100% |=========================| 491 kB    00:07
extras    : ################################################## 1402/1402
Added 141 new packages, deleted 10 old in 1.60 seconds
primary.xml.gz            100% |=========================| 285 kB    00:02
updates-re: ################################################## 818/818
Added 193 new packages, deleted 0 old in 1.69 seconds
--> Processing Dependency: libc.so.6(GLIBC_2.4) for package: xorg-x11
--> Processing Dependency: libc.so.6(GLIBC_2.4) for package: xorg-x11-libs
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for glibc to pack into transaction set.
glibc-2.3.90-7.i686.rpm   100% |=========================| 116 kB    00:01
---> Package glibc.i686 0:2.3.90-7 set to be updated
--> Running transaction check
--> Processing Dependency: glibc = 2.3.5-10 for package: glibc-devel
--> Processing Dependency: glibc-common = 2.3.90-7 for package: glibc
--> Processing Conflict: glibc-common conflicts glibc > 2.3.5
--> Processing Dependency: glibc = 2.3.5-10 for package: glibc-headers
--> Processing Dependency: glibc = 2.3.5-10 for package: glibc-utils
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for glibc-common to pack into transaction set.
glibc-common-2.3.90-7.i38 100% |=========================| 641 kB    00:07
---> Package glibc-common.i386 0:2.3.90-7 set to be updated
---> Downloading header for glibc-utils to pack into transaction set.
glibc-utils-2.3.90-7.i386 100% |=========================|  81 kB    00:01
---> Package glibc-utils.i386 0:2.3.90-7 set to be updated
---> Downloading header for glibc-headers to pack into transaction set.
glibc-headers-2.3.90-7.i3 100% |=========================| 120 kB    00:01
---> Package glibc-headers.i386 0:2.3.90-7 set to be updated
---> Downloading header for glibc-devel to pack into transaction set.
glibc-devel-2.3.90-7.i386 100% |=========================|  86 kB    00:01
---> Package glibc-devel.i386 0:2.3.90-7 set to be updated
--> Running transaction check
--> Processing Dependency: glibc-devel = 2.3.5-10 for package: linuxthreads-devel
--> Finished Dependency Resolution
Error: Missing Dependency: glibc-devel = 2.3.5-10 is needed by package
linuxthreads-devel

Comment 43 Olivier Baudron 2005-07-30 15:01:37 EDT
In reply to comment #42:
> yum --enable=development localinstall *.rpm

It seems perfectly correct to me.
The problem is that linuxthreads-devel is now included in glibc-devel. And
obviously yum does not perform very well with this situation.

Solution: remove linuxthreads-devel by hand with:
rpm -e linuxthreads-devel
then restart your command with yum.
Comment 44 Dr J Austin 2005-07-30 15:34:45 EDT
see comments #42 and #43
No problems with Full install of FC4 i386 Athlon64 G550
after update details above
Cont/Alt/F7 and Cont/Alt/F1-6 problems fixed
Great - Thanks
Comment 45 Leon Flaks 2005-07-30 21:32:58 EDT
(In reply to comment #41)
> In reply to comment #40:
> Fixes need to be tested in rawhide before it can be included in updates. This 
> is especially true when the problem is hardware dependant. So, if you can test 
> xorg-x11 and glibc from rawhide, your results are welcome!

OK, I can report that the fix with -45 and glibc worked for me.
I have Intel Pentium 4, G550.

Thanks!
Comment 46 Iain Arnell 2005-08-01 04:49:39 EDT
also confirming that -45 is working for me with the G450
Comment 47 marco atzeri 2005-08-02 14:34:40 EDT
fix with -45 and glibc works also for Matrox G200 
Comment 48 Emmanuel Kowalski 2005-08-03 09:11:09 EDT
I had hit the same bug with a G550 on a new install.  
The RPMs from comment #30 (with the rawhide glibc) also solved the issue for me
and I haven't observed any problem since.
Comment 49 Kristian Høgsberg 2005-08-03 11:46:54 EDT
Good news, thanks for testing.  We'll do a FC4 update next week.
Comment 50 Joe Ceklosky 2005-08-03 20:27:32 EDT
I see that xorg 6.9 is coming out soon.  Are the pci-scan fixes for the Matroc
G550 here include in that as well?
Comment 51 Olivier Baudron 2005-08-12 11:21:30 EDT
*** Bug 160420 has been marked as a duplicate of this bug. ***
Comment 52 Olivier Baudron 2005-08-12 12:10:11 EDT
*** Bug 162699 has been marked as a duplicate of this bug. ***
Comment 53 Olivier Baudron 2005-08-24 12:55:32 EDT
*** Bug 166530 has been marked as a duplicate of this bug. ***
Comment 54 Need Real Name 2005-08-29 12:08:12 EDT
In reply to comment #49:
>We'll do a FC4 update next week.

How's that going? Has it been decided to hold the update until xorg 6.9?
Comment 55 Mike A. Harris 2005-08-30 04:36:07 EDT
(In reply to comment #54)
> In reply to comment #49:
> >We'll do a FC4 update next week.
> 
> How's that going? Has it been decided to hold the update until xorg 6.9?

A wise man once said...  "Never say you'll do something next week, when
you really mean to say you'll do it at some point in the near future..."

;o)

There will be a FC4 update, but there is no specific timeline determined
for when it will be released at this juncture.  If you'd like to be notified
when it is released, you may wish to subscribe to
fedora-announce-list@redhat.com where release announcements are posted.

Hope this helps.
Comment 56 Olivier Baudron 2005-08-30 08:20:46 EDT
*** Bug 159838 has been marked as a duplicate of this bug. ***
Comment 57 Olivier Baudron 2005-08-31 08:00:04 EDT
*** Bug 160784 has been marked as a duplicate of this bug. ***
Comment 58 Olivier Baudron 2005-08-31 14:37:25 EDT
*** Bug 163453 has been marked as a duplicate of this bug. ***
Comment 59 Olivier Baudron 2005-09-01 05:22:34 EDT
Unless someone can point to a regression with the whole pci config space access
patch, this bug may be closed as an errata is available (6.8.2-37.FC4.45).
Comment 60 Olivier Baudron 2005-09-05 07:16:47 EDT
*** Bug 167497 has been marked as a duplicate of this bug. ***
Comment 61 Mike A. Harris 2005-09-12 14:03:11 EDT
(In reply to comment #59)
> Unless someone can point to a regression with the whole pci config space access
> patch, this bug may be closed as an errata is available (6.8.2-37.FC4.45).

Indeed.  It's been over a week, and there are no reports of regressions with
the latest FC4 update.  Assuming this problem is fixed now with the update
referenced above, and closing as "ERRATA".

Anyone still experiencing a problem after updating to the latest erratum,
should file a new bug report, attach their X server log and config file,
and specify the exact xorg-x11 name-version-release they are using, as
well as the same for the kernel.

Thanks everyone for testing.

TTYL

Setting status to "ERRATA"

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