Red Hat Bugzilla – Bug 138539
(Radeon 7000 DRI SMP) deadlock
Last modified: 2015-01-04 17:11:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
Dell 650n with 2x2.6Mhz. P4s (hyperthreading on/off doesn't matter)
Booting with non-SMP kernel work just fine.
Chaninging to SMP kernel system boots fine to graphical login.
Login as root (or anyone else) and the preparations for the new
session start normally until Red Hat Update Icon becomes highlighted.
Screen, mouse, freeze. Power-off is only possible by holding power
button for several seconds.
Version-Release number of selected component (if applicable):
kernel-2.6.9-1.667 (base FC3 release kernel)
Steps to Reproduce:
Install FC3 release with all packages on P4 SMP system.
Login at root (or anyone else).
Actual Results: See above.
Expected Results: Normal login like uni-processor version of same kernel.
Can provide other information if guidance is provided.
I have a similar problem. This is on a dual PIII-800 (6-8-6) which was
upgraded from FC2. Booting any smp kernel (the stock fc3 2.6.9 or a
hand configured 2.6.9) makes the machine lock while doing graphical
activity. As the lockup is total I have little info gathered on the
system state. The problem is both in the Gnome and in the KDE
environment. If I don't login graphicaly and work in a text console
only the machine keeps running till doomsday even though the X server
is started. If I boot a Uniprocessor kernel the problem also disappears.
I confirm similar behaviour - SMP kernel (2.6.9-1.667) - dual P4 scsi
only system. Did update install from FC2 - then yum install of all
base packages not installed - then yum update.
Gnome _always_ dies at the "redhat network monitor" phase on the
screen - but this may be coincidental.
KDE let me login and but it crashed hard 5 minutes later.
Even Alt-sysrq had no effect - there was heaevy fan or disk activity
while machine was hung - it was also unpingable from the network.
As suggested in bug#138779, this problem can be fixed by backing out
to the x.org 6.7.0-9 packages from FC2. This suggests that it is not a
kernel, but rather an x.org problem, where xorg-x11-6.8.1-12 is not
Im running with the stock FC3 SMP kernel and the FC2 xorg-x11 stuff ->
no problems anymore
The problem does not seem to occur on a single P4 with hyperthreading.
I've been working a full morning on a P4HT machine with FC3 upgraded
from FC2. A P4HT is not a full SMP machine of course. The booted
kernel is a stock FC3 SMP kernel.
Config: Dell Inspiron 5150, NVidia Gforce Go5200/64MB, 1MB memory,
P4HT 3,06 GHz.
This is likely to be a problem with a specific video chipset/driver,
because SMP has been heavily tested with no problems on a wide variety
of hardware. If you are seeing this trouble, please provide details
about your video card. lspci -n and lspci -vvv OF THAT DEVICE ONLY
I believe my video card on the system is an ATI 7000. I was going to
replace it with an NVidia card so perhaps I'll just go ahead and do
You mean ATI Radeon 7000?
1) Edit /etc/X11/xorg.conf
2) Comment out the line that reads
I also have ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE
00:00.0 Class 0600: 8086:2531 (rev 04)
00:01.0 Class 0604: 8086:2532 (rev 04)
00:02.0 Class 0604: 8086:2533 (rev 04)
00:1e.0 Class 0604: 8086:244e (rev 04)
00:1f.0 Class 0601: 8086:2440 (rev 04)
00:1f.1 Class 0101: 8086:244b (rev 04)
00:1f.2 Class 0c03: 8086:2442 (rev 04)
00:1f.3 Class 0c05: 8086:2443 (rev 04)
00:1f.4 Class 0c03: 8086:2444 (rev 04)
01:00.0 Class 0300: 1002:5159
02:1f.0 Class 0604: 8086:1360 (rev 03)
03:00.0 Class 0800: 8086:1161 (rev 01)
03:0c.0 Class 0100: 9005:0080 (rev 02)
03:0e.0 Class 0100: 9005:008f (rev 02)
04:0b.0 Class 0200: 10b7:9200 (rev 78)
04:0c.0 Class 0c00: 104c:8020
04:0e.0 Class 0401: 1102:0002 (rev 08)
04:0e.1 Class 0980: 1102:7002 (rev 08)
1:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 1b8a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min), Cache Line Size 10
Interrupt: pin A routed to IRQ 9
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at ec00 [size=256]
Region 2: Memory at ff8f0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at c1000000 [disabled] [size=128K]
Capabilities:  AGP version 2.0
Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit-
Capabilities:  Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Those with Radeon 7000, please try after disabling DRI as described in
Comment #7. Does this workaround this issue?
Yes I meant ATI Radeon 7000. I removed the load "dri" and the SMP
version worked as well as the UP version. I'm glad others are being
helped by this report. So I assume the xfree86 guys are working this
issue and we can expect a FC3 update at some point?
No, xfree86 is an irrelevant and dead project. This sounds to be a
SMP kernel issue, not the X server's fault.
Same issue? bug #138108
Removing dri - and reebooting 2.6.9-1.667smp seems stable so far.
As an aside - what do folks use for 3-d capability in FC3 - nothing
fancy but something that works - preferable with stock FC3 - or do
people bite the binary driver bullet - and if which - nvidia?
Will let this run until and if it chooses not to behave!
One more comment:
I get loads of color bleed on fonts (didnt have this prob under fc2)
- no matter how I set the anti aliasing options - could this be
related or a separate issue?
For what it's worth, the system that gives me trouble also has a
radeon 7000 (well actually a radeon VE, but that's the same chip, it
was renamed for commercial reasons later). If you want me to test
turning off dri, let me know. For that matter, if you need any kind of
testing done, let me know.
I still don't think it's a kernel issue though. I run with xorg
6.7.0-9 from FC2, with the 2.6.9-1.667 SMP kernel and that works fine,
with DRI enabled. This could be in the DRI part of the x.org Radeon
I am the one who reported bug#138779, which is an xorg-x11 bugreport.
As I explain in that report, reverting back to FC2's xorg (while
keeping the new FC3 SMP kernel, and having 'load "dri"' in the xconf
file) solves the problem. Being a non-expert, could you explain to me
then how can the problem be still a kernel or ATI chipset bug?
Does the new FC3 xorg update solve the problem?
I can confirm that commenting out
in xorg.conf is a fine workaround; my system seems stable after 48
hours of quite heave usage.
According to what I read in other sources, there are other distros
with the same problem. Namely mandrake users have experienced this
problem since the switch to x.org 6.8.0 and have had no improvement
Has anyone tried to attach a serial console and capture a kernel panic
when it locks up? Capturing that kind of debug information would go a
long way toward solving this problem.
This is most likely a dupe of bug #138108, for which I believe we now
have a fix. xorg-x11-6.8.1-17 or later in rawhide should make the
crashes go away, and we'll be putting out an update shortly for FC3.
Please test either the udpate or the rawhide packages so we can
confirm that this is indeed the same issue. Thanks.
*** This bug has been marked as a duplicate of 138108 ***
Bugzilla does not let me access (look at) bug #138108.
Similar problem using radeon driver on Centrino Thinkpad; disabling
dri fixes it. I get lockups mostly when GLX apps are running or if
Xorg is restart.
Appropriate device string from lspci:
ATI Technologies Inc Radeon Mobility M6 LY
Created attachment 107511 [details]
X server log from the crashed session
This is the X server log from the crash after installing xorg-x11-6.8.1-19.
I have tested xorg-x11-6.8.1-19 from development. 6.8.1-17 was no
longer available, but I assume anything fixed in -17 will still be
fixed in -19.
The behavior has changed somewhat:
Boot->Login->GlxGears->Xserver crash->Login->spontaneous reboot.
Althought it's different it's hardly an improvement. Backing out to
6.7.0-10 from FC2 produces a rock solid system again.
System: Dual PIII-800 with Radeon 7000
Although I normally run a slightly modified kernel (PIII optimized and
4G/4G VM layout removed), booting the stock kernel
(2.6.9-1.681_FC3smp) also gives this result.
Unfortunately the X server left no extra goodies in the log when it
crashed. The X server log is attached.
Disabling dri also makes the problem go away, but is no option for me
as I need hardware assisted 3D.
After (admitedly brief but adequate) testing - I confirm that after
installing xorg-x11 6.8.1-12.FC3.21 my system no longer crashes with
dri turned back on using SMP kernel-2.6.9-1.681_FC3.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.