Bug 138539 - (Radeon 7000 DRI SMP) deadlock
(Radeon 7000 DRI SMP) deadlock
Status: CLOSED DUPLICATE of bug 138108
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-09 15:14 EST by Daniel Levine
Modified: 2015-01-04 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:06:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X server log from the crashed session (46.25 KB, text/plain)
2004-11-27 22:29 EST, Hugo Van den Berg
no flags Details

  None (edit)
Description Daniel Levine 2004-11-09 15:14:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803

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)

How reproducible:
Always

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.

Additional info:

Can provide other information if guidance is provided.
Comment 1 Hugo Van den Berg 2004-11-14 16:19:57 EST
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.
Comment 2 gene c 2004-11-14 16:53:05 EST
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.
Comment 3 Hugo Van den Berg 2004-11-14 17:08:40 EST
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
SMP safe.

Im running with the stock FC3 SMP kernel and the FC2 xorg-x11 stuff ->
no problems anymore
Comment 4 Hugo Van den Berg 2004-11-15 04:59:53 EST
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.
Comment 5 Warren Togami 2004-11-15 15:59:20 EST
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
may help.
Comment 6 Daniel Levine 2004-11-15 16:38:24 EST
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 
that.
Comment 7 Warren Togami 2004-11-15 18:42:46 EST
You mean ATI Radeon 7000?

Try this...
1) Edit /etc/X11/xorg.conf
2) Comment out the line that reads
Load  "dri"

Any better?
Comment 8 gene c 2004-11-15 21:54:17 EST
I also have ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE


lspci -n
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)

lspic -vv
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: [58] 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-
FW- Rate=x1
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Comment 9 Warren Togami 2004-11-15 22:06:47 EST
Those with Radeon 7000, please try after disabling DRI as described in
Comment #7.  Does this workaround this issue?
Comment 10 Daniel Levine 2004-11-16 11:57:23 EST
Sorry,

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?

Thanks,

Dan
Comment 11 Warren Togami 2004-11-16 16:15:53 EST
No, xfree86 is an irrelevant and dead project.  This sounds to be a
SMP kernel issue, not the X server's fault.
Comment 12 Mike A. Harris 2004-11-16 21:14:47 EST
Same issue?  bug #138108
Comment 13 gene c 2004-11-16 23:28:25 EST
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!

gene/
Comment 14 gene c 2004-11-16 23:30:26 EST
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?

g/
Comment 15 Hugo Van den Berg 2004-11-18 09:25:25 EST
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
7000 driver.
Comment 16 Mate Wierdl 2004-11-19 17:12:13 EST
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?

Thx
Comment 17 Mate Wierdl 2004-11-22 11:27:15 EST
I can confirm that commenting  out  
 
load "dri" 
 
in xorg.conf is a fine workaround; my system seems stable after 48 
hours of quite heave usage. 
Comment 18 Hugo Van den Berg 2004-11-22 16:29:22 EST
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
from 6.8.1.
Comment 19 Warren Togami 2004-11-22 17:42:35 EST
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.
Comment 20 Kristian Høgsberg 2004-11-23 17:35:13 EST
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 ***
Comment 21 Mate Wierdl 2004-11-23 22:59:50 EST
Bugzilla does not let me access (look at) bug #138108. 
Comment 22 Matt Britt 2004-11-25 01:41:53 EST
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
Comment 23 Hugo Van den Berg 2004-11-27 22:29:57 EST
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.
Comment 24 Hugo Van den Berg 2004-11-27 22:31:53 EST
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.
Comment 25 gene c 2004-12-03 07:54:34 EST
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.

Thank you.

g/
Comment 26 Red Hat Bugzilla 2006-02-21 14:06:52 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.