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:
Also, rebuilding 6.2.8-43 without the native-pciscan patch works.
Oops, brain not in gear. s/6.2.8/6.8.2/ throughout.
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.
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
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.
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?
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
Created attachment 117065 [details] screenshot exhibiting the problem
Created attachment 117066 [details] log from (broken) xorg-x11-6.8.2-43
Created attachment 117067 [details] log from (working) xorg-x11-6.8.2 without troublesome patch
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).
It's an SMP machine?
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
Created attachment 117103 [details] Experimental patch to fix linux-native-pci-scan Can someone test this patch?
Created attachment 117105 [details] Experimental patch to fix linux-native-pci-scan (v2) This one is better.
I will test the patch on a G550 car.
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.
Oliver, The native patches do no fix the problems on the G550. I installed your rebuilts rpm's. Thanks
Oliver, That is supposed to read DO NOT
Joe, you don't see any change at all? Or is it still broken, but in a different way?
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.
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.
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
Yes, John. Can you please test my binaries rpm? Thanks.
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
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.
Iain, would you change "g400" by "g450/g550" in the summary so that people can find this bug report more easily.
Created attachment 117116 [details] Experimental patch to fix linux-native-pci-scan (v3) I messed an interval in pciCfg1outb().
*** Bug 161215 has been marked as a duplicate of this bug. ***
New binary rpms (-43.ob3) at http://olivier.baudron.free.fr/RPMS/i386/Test/
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.
Oliver, I will retest with the ob3 builds on my G550. Thanks
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?
Hi Oliver I have tested (rebuilt) linux-native-pci-scan (v3) on Athlon64 FC4 i386 G550 All is still well Great Thanks John
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.
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.
*** Bug 163674 has been marked as a duplicate of this bug. ***
(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.
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.
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
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!
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
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.
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
(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!
also confirming that -45 is working for me with the G450
fix with -45 and glibc works also for Matrox G200
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.
Good news, thanks for testing. We'll do a FC4 update next week.
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?
*** Bug 160420 has been marked as a duplicate of this bug. ***
*** Bug 162699 has been marked as a duplicate of this bug. ***
*** Bug 166530 has been marked as a duplicate of this bug. ***
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?
(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 where release announcements are posted. Hope this helps.
*** Bug 159838 has been marked as a duplicate of this bug. ***
*** Bug 160784 has been marked as a duplicate of this bug. ***
*** Bug 163453 has been marked as a duplicate of this bug. ***
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).
*** Bug 167497 has been marked as a duplicate of this bug. ***
(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"