Bug 73479 - (Radeon) Return to Castle Wolfenstein -> hard lockup
Summary: (Radeon) Return to Castle Wolfenstein -> hard lockup
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: All Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-09-05 06:38 UTC by louisgtwo
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-30 04:20:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description louisgtwo 2002-09-05 06:38:07 UTC
While playing the linux version of wolfenstein on null with a Radeon 7500
graphics card, the system occasionally freezes. Sometimes it doesn't start
gameplay at all. I have to reboot with the power button. I think it's a DRM bug.
The XFree86 log has:

drmOpenDevice: open result is -1, (no such device).

AUDIT: Thu Sep 5 02:02:01 2002: 872 X: client 5 rejected from local host

How can I debug this further?

Comment 1 Arjan van de Ven 2002-09-05 06:42:51 UTC
is this an smp machine?
also does "dmesg" show anything weird (like an oops) at the end ?

Comment 2 louisgtwo 2002-09-05 08:00:16 UTC
My box is a P4 UP i850 running kernel-2.4.18-14.i686.rpm. dmesg does not show
anything bad after startup,

agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected Intel i850 chipset
agpgart: AGP aperture is 128M @ 0xe8000000
[drm] AGP 0.99 on Intel i850 @ 0xe8000000 128MB
[drm] Initialized radeon 1.1.1 20010405 on minor 0

This might be a XFree86 bug, I can't tell.

Comment 3 Mike A. Harris 2002-09-05 08:11:15 UTC
It is definitely a bug with either XFree86 or DRM.  If the machine locks
hard, then it almost certainly has to be a DRM bug.  I have reproduced
this before on a Serverworks chipset (OSB4) with Radeon 64 DDR.

I do not think it is hardware related.  Also, it is aparently fixed in
DRI-CVS, but last I recall hearing, it just got fixed along the road,
and nobody knows exactly what the problem was or when it got fixed.
It is possible the bug exists in DRM still, and X just no longer
triggers it too.

I will chat with Kevin Martin about this and see if we can perhaps
figure it out.  I can't run Wolf3D on Radeon either anymore.  ;o)

The Wolf3D demo works fine though.

Comment 4 Mike A. Harris 2002-09-05 08:16:44 UTC
Tim Smith might be interested in peeking at this one too..  He seems
very good at debugging nasty X problems with DRI.  ;o)

Comment 5 Mike A. Harris 2002-09-05 10:15:22 UTC
Where else in the world can one get a job where one is payed to
play cutting edge 3D video games to solve customer problems?

I love my job.

Comment 6 Mike A. Harris 2002-09-05 15:02:32 UTC
Adding Kevin to CC...

Comment 7 Mike A. Harris 2002-09-05 18:44:38 UTC
Tim Smith wrote a patch to test for this...  Will test soon.

Comment 8 louisgtwo 2002-09-05 22:55:49 UTC
Would wolf3D run with 3d disabled? It will be a dog but if theirs no lockups
then we know it's a DRM issue.

Comment 9 louisgtwo 2002-09-12 02:05:21 UTC
I ran across this patch as dri.sourceforge.net and thought it might
be useful here.

Summary: Radeon lockups with to many cliprects. This patch fixes bug
'[565927] ATI Radeon freezes system'.

In function radeonClear when number of clipping rectandles exceeds
RANEON_NR_SAREA_CLIPRECTS the driver enteres infininite loop having
hardware lock and hangs XServer which waits for this lock (I think
so ;-)).

File to be patched

(this is not in unified diff form)

<          nr = rmesa->sarea->nbox;
<          for ( i = 0 ; i < nr ; i++ ) {
<            depth_boxes[i].f[RADEON_CLEAR_X1] = (float)b[i].x1;
<            depth_boxes[i].f[RADEON_CLEAR_Y1] = (float)b[i].y1;
<            depth_boxes[i].f[RADEON_CLEAR_X2] = (float)b[i].x2;
<            depth_boxes[i].f[RADEON_CLEAR_Y2] = (float)b[i].y2;
<            depth_boxes[i].f[RADEON_CLEAR_DEPTH] = 
>          for ( --n; n >= 0; n-- ) {
>            depth_boxes[n].f[RADEON_CLEAR_X1] = (float)b[n].x1;
>            depth_boxes[n].f[RADEON_CLEAR_Y1] = (float)b[n].y1;
>            depth_boxes[n].f[RADEON_CLEAR_X2] = (float)b[n].x2;
>            depth_boxes[n].f[RADEON_CLEAR_Y2] = (float)b[n].y2;
>            depth_boxes[n].f[RADEON_CLEAR_DEPTH] = 

Comment 10 Mike A. Harris 2003-06-06 00:25:47 UTC
Please attach a unified diff as a bugzilla file attachment and I'll
have a look.

Comment 11 Mike A. Harris 2004-08-30 04:20:43 UTC
Fedora Core 2, wolf seems to work on Radeon hardware ok without any
lockups, so I'm assuming this problem was fixed in CVS and made it
into newer X releases.

If you do encounter the problem again however, please file a bug
report in X.Org bugzilla at http://bugs.freedesktop.org in the
"xorg" component.  Make sure when attaching patches to bugzilla
reports in freedesktop.org or Red hat bugzilla to always generate
unified diffs, and to attach them using bugzilla file attach
feature in order for the patches to be reviewed by an engineer.


Setting status to "CURRENTRELEASE"

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