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
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
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
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
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
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:
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
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
> 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
(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!
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
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
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...
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
*** 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
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:
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:
> 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
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.
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
(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.
> 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
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
(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
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
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
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.