Description of problem: The xorg-x11-6.8.2-37.FC4.48.1 update recently released for Fedora Core 4, contained a security fix, as well as a number of bug fixes and hardware support updates. One of the bugs this update addressed, was a PCI config space contention issue which has been present in the X server forever, but which has only recently become a major issue with current generation computer systems. Previously, the X server would read/write to the PCI config registers directly on its own, instead of using safe arbitrated access mechanisms provided by the Linux kernel. If some other kernel driver or userland code running as root were to access the PCI config space registers at the exact same time the X server starts up, the result would be a system that randomly hung, or any number of other spurious and transient problems. The only way to safely solve the PCI config space contention issue permanently, was to change the X server to access PCI config space via the kernel, so that the kernel is fully in control of access, and can thus ensure no 2 things access the hardware simultaneously, thus preventing contention from causing system lockups and other odd spurious crashes or other behaviour. The upstream X sources have had the ability to use the OS PCI config space access mechanisms for quite a long time now, however it was never enabled by default upstream before for x86 class hardware. The initial solution was to simply enable this code as the default for all Linux platforms, as it is the only "safe" way to access PCI config space without contention. The xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch was implemented to solve the PCI config space contention problem, by changing the defaults in the X source many months ago. This change was also made upstream by X.Org to CVS. After a few weeks of testing in rawhide, etc. it was discovered that there were some problems in the X code to use native OS access mechanisms, and those issues were addressed upstream and also in Fedora Core as well. This is more or less what shipped in Fedora Core 4's first xorg update, and it seemed to work fairly well, however we did receive a number of bug reports from Matrox, Intel and some other users which over time we were able to pinpoint down to the pciconfig patch. Deeper investigation indicated that the X server code for using native OS pci config access needed some additional changes to the X server due to some bad assumptions in the X server's PCI code. The patch was updated and the known issues were resolved. Later, it was determined that some Matrox hardware still had problems with the pciconfig patch. An investigation was done into the matter, which showed that the Matrox video BIOS was accessing hardware registers outside of PCI config space. The X server PCI handling code did not anticipate this type of usage scenario, and an optimization present in the code caused the Matrox BIOS to trigger a false assumption in the code. This issue was fixed, however it was unclear just how many video BIOSes out there might be affected by the problem, or by other problems also yet undiscovered. At this point, the pciconfig patch was updated to fix all known problems that could be linked to it, and it was tested internally on a variety of video hardware and systems. No further regressions were discovered, and a number of users had been affected by the previous regressions, so the updated pciconfig patch was considered a critical bug fix and was added to the queue for the next update. After releasing the latest update (xorg-x11-6.8.2-37.FC4.48.1) along with the other bugfixes, some users have reported a regression in video hardware support, in particular on Intel i8xx/i9xx systems, but also on some other video hardware as well. We have immediately investigated these issues internally, and were able to reproduce the problem on a system and diagnose the cause of the issue to another small bug in the X server's PCI config space handling code. The pci-config patch has been updated with this fix, and is currently being re-tested on various video hardware internally. Once we've resolved any regressions that are detected during our internal testing, we will provide new rpms for users to test and provide feedback. Once we've received enough feedback from testers that the testing rpms resolve the regressions they've experienced, we will release a new official update for Fedora Core 3 and 4.
*** Bug 168562 has been marked as a duplicate of this bug. ***
*** Bug 168734 has been marked as a duplicate of this bug. ***
*** Bug 168561 has been marked as a duplicate of this bug. ***
*** Bug 168564 has been marked as a duplicate of this bug. ***
*** Bug 168662 has been marked as a duplicate of this bug. ***
For everyone who has experienced this problem with the latest Fedora Core 4 update, please test these beta rpms for FC4, and report status back here: http://people.redhat.com/krh/xorg-x11/fc4 Setting status to "NEEDINFO"
I saved all the files from http://people.redhat.com/krh/xorg-x11/fc4 to ~/temp, did a "cd temp" and a "sudo rpm -Uvh *", rebooted, and everything is fine once again on my Pentium 4 with integrated Intel 82915G/GV/910GL Express Chipset Family Graphics Controller. glxgears runs at 1411 FPS.
Works for me too on FC3 with 855GME on hp dv1000. Problem solved. Thumbs up.
Works for me fc4/855GM.
Works for me: Fedora Core 4, i810, Compaq Presario 2210US. Thanks to the devs for the quick fix.
yes, it works for i810 device in xorg.conf. however, I believe there may be some refresh rate issues. the screen is not filling all the way to the edges, as if I were running at 75hz instead of 85hz. WinXP and the old xorg drivers dont seem to have this problem. any ideas what further information I could produce?
(In reply to comment #11) > yes, it works for i810 device in xorg.conf. > > however, I believe there may be some refresh rate issues. the screen is not > filling all the way to the edges, as if I were running at 75hz instead of 85hz. > WinXP and the old xorg drivers dont seem to have this problem. File a new separate bug report for that, and include the exact version-release of xorg in the bug report. You mention "the old xorg drivers", but that alone is not that useful to us unless we know the exact Fedora release, and exact rpm version-release of xorg for comparison purposes. Part of the security update was also a complete update of the Intel i810 driver to add hardware support for newer cards. It's possible there might be some unexpected problems from that, but that should be handled in a separate report. This bug report here is specifically for the problem of Intel and other video hardware breaking due to the pci-config patch issues. > any ideas what further information I could produce? File a bug report for that issue and we'll try to diagnose/etc. further in the new report. Thanks for testing!
Rpms from http://people.redhat.com/krh/xorg-x11/fc4 are working fine with i830M chip.
(In reply to comment #12) > (In reply to comment #11) > > yes, it works for i810 device in xorg.conf. > > > > however, I believe there may be some refresh rate issues. the screen is not > > filling all the way to the edges, as if I were running at 75hz instead of 85hz. > > WinXP and the old xorg drivers dont seem to have this problem. > > File a new separate bug report for that, and include the exact > version-release of xorg in the bug report. You mention "the old xorg > drivers", but that alone is not that useful to us unless we know the > exact Fedora release, and exact rpm version-release of xorg for > comparison purposes. > > Part of the security update was also a complete update of the Intel i810 > driver to add hardware support for newer cards. It's possible there > might be some unexpected problems from that, but that should be handled > in a separate report. This bug report here is specifically for the > problem of Intel and other video hardware breaking due to the pci-config > patch issues. > > > any ideas what further information I could produce? > > File a bug report for that issue and we'll try to diagnose/etc. further > in the new report. > > Thanks for testing! Cheers! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168764
RPMS for x86_64, ppc, etc. also now available at: xorg-x11-6.8.2-1.FC3.45.1 is now available for download via ftp at the following URL: ftp://people.redhat.com/mharris/testing/fc3 xorg-x11-6.8.2-37.FC4.49.1 is now available for download via ftp at the following URL: ftp://people.redhat.com/mharris/testing/fc4
Works for me on a Dell Optiplex GX270 with an integrated Intel Extreme Graphics 2 card. scanpci entry: pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2572 Intel Corp. 82865G Integrated Graphics Device Thanks for the quick fix!
Rpms from http://people.redhat.com/krh/xorg-x11/fc4 are working fine for me... # scanpci pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x2560 Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge pci bus 0x0000 cardnum 0x01 function 0x00: vendor 0x8086 device 0x2561 Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge Thank you!
*** Bug 168765 has been marked as a duplicate of this bug. ***
I downloaded and installed the updates on my FC4 system. X displays again, but the display looks very coarse. Hope this will be fixed for the final bugfix release.
The updates seems to work with one important exception; The background menu, usually accessed by rightclicking on the background, has disapeared.
Thanks, the update fixed i855 support on my system. (Also seems to have fixed issue whereby DRI was hosed following suspend/resume.) Great job!
The updates works with my Dell Latitude D500 (i855GM) too.
It works on Dell Inspiron 500m too. Going to the console and back, when X is displayed on an external screen only, crashed X though.
xorg-x11-6.8.2-37.FC4.49.1.i386.rpm still does not start on Asus M5N with I855GME chipset, same problem as with FC4.48.1. No problem with FC4.45.1.
Works with i845 with no refresh problems
It fixes the problem on my Dell Latitude X200 (i830).
Works for me too: Fedora Core 4, i915GM chip(with i810 driver), Panasonic CF-W4. Thanks for the quick fix!
The .49.1 rpm works again on integrated intel chip: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03) Ran simple tests with XVideo, glxgears, xscreensaver, x11perf at the same time without problems.
Works for me. Dell 300m, Intel 82852/855GM Integrated Graphics Device. Thanks.
the .49.1 update seems to be working properly on my HP/Compaq workstation with Intel 915 chipset.
Fixed my problems, Acer travelmate 4500, Intel 82852/855GM Integrated Graphics Device. Great job, thanks.
Mike's test version still has this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168844 This seems to have appeared with 48.1, so it would be appropriate that it disappear at the same time as the other problems introduced by 48.1.
Hearing about the problem via the fedora list, I did not update my system from the previous X version until today. downloading the rpms for FC4 from the site listed in this bug report and then using up2date with a local repository installed the rpms. Rebooting the system confirms that the proposed rpms do not cause failure on an Intel 856G videocard. Earlier tests on a computer with an Intel 815 video were not effected by the last released version of xorg-x11. I tested on FC3 and FC4 with no failures on that particular system. Why was this card not effected? It is an onboard videocard. Anyway, thanks for the prompt fix.
(In reply to comment #33) > Mike's test version still has this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168844 > > This seems to have appeared with 48.1, so it would be appropriate that it > disappear at the same time as the other problems introduced by 48.1. Yep, that regression will be fixed too before the next update. rpm sucks, film at 11. ;o)
Mike's new version works for me with a Matrox G550 on FC$
test rpms work beautifully with my i830 on a Vaio R505GL. Thanks for the lightning fast fix.
Test rpms 49.1 worked fine on my x86 machine with Intel Corp. 82865G Integrated Graphics Device
Test rpms 49.1 worked fine on my FC4 x86 machine with Intel Corp. 82865G Integrated Graphics Device
(In reply to comment #35) > (In reply to comment #33) > > Mike's test version still has this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168844 > > > > This seems to have appeared with 48.1, so it would be appropriate that it > > disappear at the same time as the other problems introduced by 48.1. > > Yep, that regression will be fixed too before the next update. rpm sucks, > film at 11. ;o) Gulp. Never promise things to people. It turns out that we had a slightly different order of events happen. ;o) - Fixed this bug - Put up rpms for you guys to test - Got testing feedback - High fived each other - the fedora update was pushed, but we weren't all aware of it, however there is update lag time between the push and availability - I wasn't aware of the previous step - I promised we would fix that other bug before the update - I was going to do the update tonight with that fix - I found out the update already went out the door. ;o) So.... this bug is fixed, but the library post script bug is not fixed. We're not going to do another update right now just for that one bug however, so it will remain present for now until there is a big enough reason to do another update. We'll track that in the actual bug report for that issue, not here. ;o) Anyhow, the erratum is released for this. Er. oops, I mean the "update" is released. Fedora pedantic semantics. ;o) Fixed in xorg-x11-6.8.2-37.FC4.48.1
On my Dell Optiplex GX270 with integrated Intel 865G graphics controller this is still an open issue. As I wrote earlier, the display has become very coarse in this update, even at my usual 1024x768 resolution. Vertical straight lines appear kind of wavy, with alternating vertical pixels shifted one pixel left and right. I had no such problem with the xorg release that came on the FC4 CDs.
Test rpms 49.1 work on an Acer TravelMate 382TMi with 855GM in single head, clone and dualhead modes (with the exception of different resolutions on the two heads, but this is an old problem related to the machine's BIOS). However, there is a regression related to i855crt. Recently, it used to be possible to enable the external pipe after starting X with 'i855crt on 1024x768@60', but with the 49.1 build, I'm back to a situation where the pipe is enabled, but colors are corrupted on the CRT. 'i855crt on rawpipe' display the the same kind of "wavy/fuzzy" CRT output as in comment #41.
(In reply to comment #40) > Fixed in xorg-x11-6.8.2-37.FC4.48.1 Something doesn't seem right. The summary of this bug says the regression was introduced in xorg-x11-6.8.2-37.FC4.48.1, so it couldn't have been fixed in that same version. FC4.48.1 was released on Sept. 16th according to the file time stamp on http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/ . There was a new update for FC3 (xorg-x11-6.8.2-1.FC3.45.1) released on Sept. 20th, but there seems to be no corresponding update that has been released for FC4.
In reply to comment #41 by Robert. I have an Intel 865G on a Dell GX270 with A04 BIOS and noticed a shift in the display to the left. I readjusted the display for a 70 horizontal to get the display in line. the vertical offset was not in need of adjustment. Otherwise, running 1280x1024@24 looks pretty decent. The LCD display that I have attached seems to display similar to what it displayed previously. From my view, the scanning is off a bit for the 865G card. If you see fuzziness, it is most likely there. With the glxgears output, I get 16897 frames in 5 seconds and spikes of 10279 frames in 5 seconds.
The .49 update from http://people.redhat.com/krh/xorg-x11/fc4 works fine for me on a Toshiba laptop with: pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x3582 Intel Corp. 82852/855GM Integrated Graphics Device
This bug needs to be reopened - unofficial update doesn't count... Up2date keeps on breaking more and more systems installing broken stuff... Dupes keep on procreating...
Ok, now to add even more confusion... (In reply to comment #40) > (In reply to comment #35) > > (In reply to comment #33) > > > Mike's test version still has this bug: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168844 > > > > > > This seems to have appeared with 48.1, so it would be appropriate that it > > > disappear at the same time as the other problems introduced by 48.1. > > > > Yep, that regression will be fixed too before the next update. rpm sucks, > > film at 11. ;o) > > Gulp. Never promise things to people. > > > It turns out that we had a slightly different order of events happen. ;o) > > - Fixed this bug > - Put up rpms for you guys to test > - Got testing feedback > - High fived each other > - the fedora update was pushed, but we weren't all aware of it, however there > is update lag time between the push and availability > - I wasn't aware of the previous step > - I promised we would fix that other bug before the update > - I was going to do the update tonight with that fix > - I found out the update already went out the door. - Except the update went to FC-3 final, and FC-4-testing, so it isn't actually released for FC-4 yet. > ;o) > > So.... this bug is fixed, but the library post script bug is not fixed. > We're not going to do another update right now just for that one bug > however, so it will remain present for now until there is a big enough > reason to do another update. We'll track that in the actual bug report > for that issue, not here. ;o) > > Anyhow, the erratum is released for this. Er. oops, I mean the "update" > is released. Fedora pedantic semantics. ;o) > > Fixed in xorg-x11-6.8.2-37.FC4.48.1 No Mike, it was fixed in xorg-x11-6.8.2-37.FC4.49.1 ... <sigh> I got the wrong release number from our buildsystem as I was looking in "official updates" place instead of "testing updates", as I was unaware the update accidentally went to 'testing'. So, here's where things stand right now: - The current testing update xorg-x11-6.8.2-37.FC4.49.1 does fix the problem for FC4. It has bug regression bug #168844 however. - I am currently rolling xorg-x11-6.8.2-37.FC4.49.2 with a fix for bug #168844 in it. - Assuming that there are no more buildsystem glitches, miscommunications, or other invocations of Murphy's law, I am hoping to submit the xorg-x11-6.8.2-37.FC4.49.2 build as an official FC4 update tonight to our update system. - Assuming there are no infrastructural problems, the update will hopefully be rolled out to FC4 users by tomorrow. It's been a hectic week it has been for all of our team, but hopefully we are past all of the mayhem now. ;) Thanks again to everyone who has tested everything and provided feedback. I'll update this report again, once I've submitted the release to the fedora-update tool.
From User-Agent: XML-RPC xorg-x11-6.8.2-37.FC4.49.2 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Thanks for all the hardwork!
Updated xorg to 49.2 on FC4. However, the wavy/fuzzy vertical lines problem still persists.
(In reply to comment #50) > Updated xorg to 49.2 on FC4. However, the wavy/fuzzy vertical lines problem > still persists. Could you do me a favour and have a look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168764 ? I have an 865 chipset too. (and a Dell monitor) Mike (or other xorg-X11 experts), is wavy lines/fuzziness a symptom of incorrect refresh rate? I'll have a dig around in my bios to see if there are any options which might be causing incompatibilities and report back.
Upgrading from 45 to 49.2 on FC4 works 'mostly': switching from a vt to X works, switching back from X to a vt works, but switching back again to X from a vt leaves me with a black screen. Logging in remotely and re-starting X doesn't help. Other than that, the system continues to run fine... This is on a Sony PCG-R600HMP with an Intel 82830 CGC chipset.
Upgraded from Fresh install of FC4 to 49.2. Now I just get a Black Screen when trying to load X. I can go from X to a vt fine, but when go from vt to X it is Black Screen again. Have Intel 845 chipset.
Neither xorg-x11-6.8.2-37.FC4.49.1 nor xorg-x11-6.8.2-37.FC4.49.2 has fixed the problem for me. When starting X the computer either freezes or I get just a black screen with X taking 100% CPU (SIGINT will not kill X, SIGKILL will kill X, but the vt does not come back). I tracked the problem down by removing my old xorg.conf, and starting from scratch with system-config-display. A fresh created xorg.conf works fine. After lots of testing I found the problem: Option "MonitorLayout" "LFP+CRT,NONE" Several settings for MonitorLayout will prevent X from working correctly with the new release, while the old release had no such problem. However, it does not seem to be critical for me, even after removing the line the i855crt tool for switching the external VGA-port on and off works (not sure, but I think it did not work with the old release without above line). One good thing about the new release: DRI now works after suspend to disk. I would suggest to create a new xorg.conf in case of problems. 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) Asus M5678N centrino notebook
I removed the xorg.conf and created a new one using system-config-display. I can only get into X at 800x600 (16 and 24bit). If I try to go any higher (1024x768 or 152x864)I get the black screen again. Compaq Evo 510 w/ Intel 845 chipset.
The xorg-x11-6.8.2-37.FC4.49.2 update fixes the issue reported in this report. That has been confirmed now by countless users enough to consider this specific issue resolved. There remains a possibility that there are further regressions that are yet undiscovered in the pci-config patches, or that there may be problems with one of the other updates, although we are currently unaware of any further such regressions. Users who upgrade and still have a problem even with this release are experiencing a separate issue, and should report a brand new bug in bugzilla against the proper Fedora Core release. Be sure you are using the latest update before reporting a new bug, and in the new bug report, please describe the new problem in full detail, and indicate the exact xorg-x11 version-release you are experiencing the problem with. Also indicate which other xorg-x11 updates you have experienced the problem with, and indicate what version-release was the last one that did not exhibit the regression you are now experiencing. We will investigate any new bugs that are reported to us as new incidents individually. Thanks everyone for your testing efforts and for your bug reporting. Setting status to ERRATA.
*** Bug 168919 has been marked as a duplicate of this bug. ***
*** Bug 168937 has been marked as a duplicate of this bug. ***
Any hope for FC3 rpm's? mharris/testing/fc3/ is empty now.
Errata was already released for both FC3 and FC4.
sorry, my bad. I was installing the not-latest set of update rpm's. yes, xorg-x11-6.8.2-1.FC3.45.2.i386.rpm (and friends) fixes it for fc3 on my dell x200 laptop.