I encountered the same issue on a PE 1850 _after_ applying all the updates. 
Switching to a UP kernel stopped the crashing.  Running an SMP kernel in rc3
(i.e no  X running) also stopped the crashing.  The version of the SMP kernel
seemed to have no effect. ( tried 2.6.10-1.770_FC3smp, 2.6.11-1.14_FC3smp, and
2.6.9-1.667smp)

I then downgraded the xorg packages to the pre-update versions (6.8.1-1) and the
problem disappeared. 

It appears the problem is related to the latest xorg updates and smp kernels.

hmm, can I get an lspci output from both of you please ?

From the Dell PowerEdge Mailing list...

On Fri, Apr 15, 2005 at 03:56:47PM -0500, Paul_Maia wrote:
>    Hi all...
>    I have the following system:
>    PE2850 (a backup for one of my web servers),
>    2 - 2.8g Processors,
>    1g Ram,
>    PERC 4/DC. 4 - 18g drives as a 4 stripe RAID 5
> 
>    Seems to run just fine, except that is, until I right-click and select
>    lock console. After about 5 seconds, it will cause the 2nd proc to get an
>    error on the front panel and the system freezes solid:
> 
>            E07F0, PROC1, IERR
>    The issue is 100% re-creatable. I looked on the web for the error, it says
>    that the proc is bad or needs re-seating.

One other instance of IERR we've seen is related to the X server, that it's
doing PCI config space access by directly poking I/O ports CF8 and CFC without
using the kernel-provided access methods that provide mutual exclusion from
something else (like lspci) accessing those same ports simultaneously. 
Everything else uses the kernel-provided access methods, the X server should also.

This option needs to be set in your /etc/X11/xorg.conf file in
ServerFlags:

   Section "ServerFlags"
        Option "PciOsConfig" "1"
  EndSection


Mike Harris, Red Hat's xorg package maintainer, has looked into fixing this for
RHEL3 and RHEL4 in the source code.  I'm sure the same fix will need to get
backported into Fedora.

Thanks,
Matt

--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing
lists @ http://lists.us.dell.com

lspci output as requested....

[root@testbed2 ~]$ lspci
00:00.0 Host bridge: Intel Corp. E7520 Memory Controller Hub (rev 09)
00:02.0 PCI bridge: Intel Corp. E7525/E7520/E7320 PCI Express Port A (rev 09)
00:04.0 PCI bridge: Intel Corp. E7525/E7520 PCI Express Port B (rev 09)
00:05.0 PCI bridge: Intel Corp. E7520 PCI Express Port B1 (rev 09)
00:06.0 PCI bridge: Intel Corp. E7520 PCI Express Port C (rev 09)
00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
(rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
(rev 02)
00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
01:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06)
01:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06)
02:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06)
05:00.0 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge A (rev 09)
05:00.2 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge B (rev 09)
06:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
(rev 05)
07:08.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
(rev 05)
09:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]

(In reply to comment #2)
> hmm, can I get an lspci output from both of you please ?
> 

Here you go...

[51] [fury2] $lspci
00:00.0 Host bridge: Intel Corp. E7520 Memory Controller Hub (rev 09)
00:02.0 PCI bridge: Intel Corp. E7525/E7520/E7320 PCI Express Port A (rev 09)
00:03.0 PCI bridge: Intel Corp. E7525/E7520/E7320 PCI Express Port A1 (rev 09)
00:04.0 PCI bridge: Intel Corp. E7525/E7520 PCI Express Port B (rev 09)
00:05.0 PCI bridge: Intel Corp. E7520 PCI Express Port B1 (rev 09)
00:06.0 PCI bridge: Intel Corp. E7520 PCI Express Port C (rev 09)
00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
(rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
(rev 02)
00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
01:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06)
01:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06)
02:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06)
04:00.0 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge A (rev 09)
04:00.2 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge B (rev 09)
05:04.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller
(Copper) (rev 01)
05:04.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller
(Copper) (rev 01)
0a:00.0 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge A (rev 09)
0a:00.2 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge B (rev 09)
0b:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
(rev 05)
0c:08.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
(rev 05)
10:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]

Experiencing the same problems also on a PowerEdge 2800, tried the fix suggested
in Comment 3, no go.  Using kernel 2.6.11-1.14_FC3smp, xorg-x11 version
xorg-x11.x86_64 6.8.2-1.FC3.13

lspci output as requested in comment 2:

[root@rr ~]# lspci
00:00.0 Host bridge: Intel Corp. E7520 Memory Controller Hub (rev 09)
00:02.0 PCI bridge: Intel Corp. E7525/E7520/E7320 PCI Express Port A (rev 09)
00:03.0 PCI bridge: Intel Corp. E7525/E7520/E7320 PCI Express Port A1 (rev 09)
00:04.0 PCI bridge: Intel Corp. E7525/E7520 PCI Express Port B (rev 09)
00:05.0 PCI bridge: Intel Corp. E7520 PCI Express Port B1 (rev 09)
00:06.0 PCI bridge: Intel Corp. E7520 PCI Express Port C (rev 09)
00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
(rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
(rev 02)
00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
01:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06)
01:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06)
02:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 08)
02:05.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 08)
03:0b.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
04:00.0 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge A (rev 09)
04:00.2 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge B (rev 09)
07:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 07)
07:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 07)
08:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 07)
0c:00.0 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge A (rev 09)
0c:00.2 PCI bridge: Intel Corp. 6700PXH PCI Express-to-PCI Bridge B (rev 09)
0d:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
(rev 05)
0e:08.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
(rev 05)
0f:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit
Ethernet PCI Express (rev 01)
12:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]

Actually there are 2 modification needed to avoid the race condition.  You 
need to change

Section "ServerFlags"
  Option "PciOsConfig" "1"
EndSection

As mentioned by Matt earlier and you also have to modify the DEVICE section 
with adding a NoINT10 option:

Section "Device"
  :
  Option "NoINT10"
  :
EndSection

Since the access to the PCI config registers from Xserver can also be 
triggered by the contents of Video BIOS if it is "called".  The above changes 
in the config file should avoid.

Hello, thats my xorg.conf with the recommendations above.
Its a fresh installed system. It crashes continuously after
log in (init5).

Who is exactly the "troublemaker", kernel or x11? 
Just not to downgrade innocents. Thanks. 

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "ServerFlags"
        Option "PciOsConfig" "1"
EndSection     


Section "Files"

        RgbPath      "/usr/X11R6/lib/X11/rgb"
        FontPath     "unix/:7100"
EndSection

Section "Module"
        Load  "dbe"
        Load  "extmod"
        Load  "fbdevhw"
        Load  "glx"
        Load  "record"
        Load  "freetype"
        Load  "type1"
        Load  "dri"
EndSection

Section "InputDevice"

        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "de"
        Option      "XkbVariant" "nodeadkeys"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
EndSection

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Unknown monitor"
        HorizSync    31.5 - 37.9
        VertRefresh  50.0 - 70.0
        Option      "dpms"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Option "NoINT10"
        Driver      "radeon"
        VendorName  "Videocard vendor"
        BoardName   "ATI Radeon 7000"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     16
                Modes    "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes    "800x600" "640x480"
        EndSubSection
EndSection

Section "DRI"
        Group        0
        Mode         0666
EndSection

(In reply to comment #1)
> I encountered the same issue on a PE 1850 _after_ applying all the updates. 
> Switching to a UP kernel stopped the crashing.  Running an SMP kernel in rc3
> (i.e no  X running) also stopped the crashing.  The version of the SMP kernel
> seemed to have no effect. ( tried 2.6.10-1.770_FC3smp, 2.6.11-1.14_FC3smp, and
> 2.6.9-1.667smp)
> 
> I then downgraded the xorg packages to the pre-update versions (6.8.1-1) and the
> problem disappeared. 
> 
> It appears the problem is related to the latest xorg updates and smp kernels.


I just had the opportunity to do the same.  I downgraded the xorg packages
from 6.8.2-1 back to 6.8.1-1 and was able to boot in init state 5 on the
2.6.10-1.770_FC3smp kernel.  My system has not crashed even loggin in to 
the console.

It clearly is a problem associated with xorg and not the kernel.

Kim

I have just purchased a PowerEdge 2800 and installed FC3 with no problems, 
logging in to init5 X fine until I ran the yum updates. Now the login causes a 
race condition before the desktop has completed loading.

I noticed Dell are now including the above advice on a flyer with the server 
and say they are working with Red Hat on a resolution.

However, applying the changes to xorg.conf made no difference. Can someone 
please confirm if the changes worked for them?  If so, could you please post a 
complete xorg.conf file for copying/reference?

My additions as per Dell's advice:

# Top of file

Section "ServerFlags"
        Option "PciOsConfig" "1"
EndSection

# And lower down added last 'Option "NoINT10"'

Section "Device"
        Identifier  "Videocard0"
        Driver      "radeon"
        VendorName  "Videocard vendor"
        BoardName   "ATI Radeon 7000"
        Option "NoINT10"
EndSection

If not the above, can anyone offer any advice on the easiest way to downgrade 
xorg and ensure yum doesn't update until a fix is found? (Sorry if this part 
is off-topic)

Thank you,

James

(In reply to comment #10)

For anyone finding this post and needing to back out xorg to an earlier version 
to prevent this problem, the following worked for me:

Take the following RPMS from the Red Hat FC3 CD's/DVD:

xorg-x11-6.8.1-12.i386.rpm
xorg-x11-font-utils-6.8.1-12.i386.rpm
xorg-x11-libs-6.8.1-12.i386.rpm
xorg-x11-Mesa-libGL-6.8.1-12.i386.rpm
xorg-x11-Mesa-libGLU-6.8.1-12.i386.rpm
xorg-x11-tools-6.8.1-12.i386.rpm
xorg-x11-twm-6.8.1-12.i386.rpm
xorg-x11-xauth-6.8.1-12.i386.rpm
xorg-x11-xfs-6.8.1-12.i386.rpm

Put them all in one directory and run:

rpm -Uvh --oldpackage *.rpm 

Rebooting will ensure the correct version on xorg is loaded at the console.

To prevent yum upgrading these packages again until the issue is fixed, 
edit /etc/yum.conf add the following line at the bottom of the list in the 
[main] directive:

exclude=*xorg*

HTH

James

I noticed that 2.6.11.27_FC.i686 just came out recently.  Does this version fix
the xorg problem, I'm not going to try it myself because I cannot afford the
downtime.  Until i hear otherwise I'm going to stick with xorg 6.8.1.

Just wondering.

I have the same problem on Dell POwerEdge 1850. Did any one tried FC4?
I don't think any kernel upgrades would fix this bug - the problem is with the 
xorg-x11. FC4 uses 6.8.2-37

Leon

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Interesting.  I had left YUM update enabled, and it installed this very kernel
version automatically.  When the system locked up again because of the X issue,
GRUB loaded the new 2.6.12 kernel... which promptly caused a kernel panic after
tring to load INIT.

I may post more info later, but (1) I'm writing my thesis right now and can't be
bothered with one problem after another, and (2) the server is in the basement,
and is actively being used.  It's just as easy not to run X at this point.

The new kernel may have fixed the problem.  Time will tell, and I'm still using
the original version of xorg that came with FC3 (responding to other comments on
this list, I excluded xorg from my yum updates).  So far, with
2.6.12-1.1372_FC3smp and xorg-x11 6.8.1-12, the system hasn't crashed, and I've
been able to use X functionally for a longer time period than I had before.

To get the kernel to work, however, I had to upgrade the udev and mkinitrd
packages (see bugs 163437 and 160652) by filching them from the x86_64 FC4
distribution.  Then, I needed to re-make the initrd file for the new kernel as
described in those bugs.

This is a lot of hoop-jumping, and hopefully new FC3 versions of udev and
mkinitrd will be released shortly.  In the meantime, I can with some caution
confirm that this solution will work.

Thanks to the RedHat folks who have been working to solve this. :)

I am happy to report that the new kernel (2.6.12-1.1372_FC3smp) solved my 
problem with Poweredge 1850. In order to make it work I had to upgrade to the 
latest mkinitrd (4.1.18.1-1) The system is up since last Friday afternoon.
It used to hang within 5 minutes after starting X applications.
I am using 6.8.2-1.FC3.34 version of xorg-x11.

Thanks everybody for help!

After installing the new kernel 2.6.12-1.1372smp x86_64 (with mkinitrd
4.1.18.1-1) and upgrading to the new version of Xorg that I had previously
disabled in yum.conf, I'm having more problems than ever.  Whereas before I
could get by using X for about 10-15 minutes, now I can barely get in and start
firefox before it dies.  Most of the time, it freezes during startup (typically
around "starting nautilus," though not always) and I can't even get that far.

After downgrading to the original Xorg version that came with FC3 (6.8.1-12), it
appears that nothing has changed--X still locks up, even more than it did
before.  Is anyone else having this problem?

I have done a yum update -- so other factors may be at work here.

Strangely, when using the FC4 udev/mkinitrd with the new kernel, I had only one
time where X crashed (but it still crashed).  Is there any way this bug can be
reopened?

Thank you all for your advseâ¦..

I have a PowerEdge 2800, I freshly installed FC3 did all yum updates except 
xorg packages.  I excluded them in the yum.conf file:

exclude = xorg 

The server is working and stable.  However, I would like to remove 
the âexclude = xorgâ.  Has fedora resolved the problem with kernel/xorg?  Will 
the server be stable with FC4 instead of FC3?  Your guidance is greatly 
appreciated.  

Hello,

I've the same problem with a Dell Power Edge 2850 which I recently installed and
then updated to the latest set of packages using up2date. Kernel version is
2.6.12-1.1381_FC3smp
X11 version is
xorg-x11-6.8.2-1.FC3.45.2

Now, overnight the system crashes and shows E07F0 on the front panel with IERR
for both PROC1 and PROC2.

Adding the ServerFlags clause with Option "PciOsConfig" "1"
and Option "NoINT10" in the Device section causes the system to freeze as soon
as X is started on boot.

It doesn't look like the bug is fixed??

I have the exact same problem as Tom Crummey in Comment #23 above. I have a
brand new Poweredge 2850 with RHEL4 .. I am running with init level 3 as a
temporary workaround.

Is this bug going to remain "CLOSED" ?

I thought this bug had been resolved, but after a system reboot on Friday 
(after an uptime of a number of months) it has crashed repeatedly. Has a new 
version of xorg been released that has re-introduced the bug? I've had to 
revert back to the original version on the FC3 disks until I know why this has 
come back again.

James