Bug 5781 - radeon driver locks up
radeon driver locks up
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
7.0.0
x86 (IA32) Linux (All)
: high normal
Assigned To: Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-01 17:02 UTC by Dave Jones
Modified: 2007-02-22 12:59 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Jones 2006-02-01 17:02:29 UTC
I hit ctrl-alt-f1 and flipped to tty1 from X, and did some work, and then hit
alt-F7 to return to X.   The box just froze.   Even capslock lights on keyboard
don't work.

I can ssh into however.
My /var/log/Xorg.0.log has a few hundred..

(EE) SIGIO not blocked at xf86eqEnqueue

at the end.


Here's the backtrace of the server.
Loaded symbols for /lib64/libresolv.so.2

0x00002b9ea58ff019 in RADEONINPLL ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
(gdb) bt
#0  0x00002b9ea58ff019 in RADEONINPLL ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#1  0x00002b9ea58ff7ff in RADEONINPLL ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#2  0x00002b9ea590523e in RADEONEntPriv ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#3  0x00002b9ea5905367 in RADEONEntPriv ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#4  0x00002b9ea5905a48 in RADEONEnterVT ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#5  0x00002b9ea63a0446 in xf86ForceHWCursor ()
   from /usr/lib64/xorg/modules/libramdac.so
#6  0x000000000047b840 in xf86InitFBManagerArea ()
#7  0x000000000048761b in xf86XVScreenInit ()
#8  0x0000000000476004 in xf86Wakeup ()
#9  0x000000000044ca90 in WakeupHandler ()
#10 0x000000000054a49b in WaitForSomething ()
#11 0x0000000000448dec in Dispatch ()
#12 0x0000000000432bc5 in main ()
(gdb) Quit
(gdb)
#0  0x00002b9ea58ff019 in RADEONINPLL ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#1  0x00002b9ea58ff7ff in RADEONINPLL ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#2  0x00002b9ea590523e in RADEONEntPriv ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#3  0x00002b9ea5905367 in RADEONEntPriv ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#4  0x00002b9ea5905a48 in RADEONEnterVT ()
   from /usr/lib64/xorg/modules/drivers/radeon_drv.so
#5  0x00002b9ea63a0446 in xf86ForceHWCursor ()
   from /usr/lib64/xorg/modules/libramdac.so
#6  0x000000000047b840 in xf86InitFBManagerArea ()
#7  0x000000000048761b in xf86XVScreenInit ()
#8  0x0000000000476004 in xf86Wakeup ()
#9  0x000000000044ca90 in WakeupHandler ()
#10 0x000000000054a49b in WaitForSomething ()
#11 0x0000000000448dec in Dispatch ()
#12 0x0000000000432bc5 in main ()
(gdb) Quit
Comment 1 Dave Jones 2006-02-01 17:20:25 UTC
I forgot to mention what this is..

05:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
Comment 2 Michal Jaegermann 2006-02-10 13:09:00 UTC
I found the same messages "SIGIO not blocked at xf86eqEnqueue" and complete
server lockups using "ATI Radeon 9500 AD" with version 7.0 server while
running GL programs (mesa-6.4.2) on an x86_64 machine.  I tried various binaries
from /usr/libexec/xscreensaver/.  Most of the will actually run while producing
various warnings in such style:

***************************************************************************
No ctx->FragmentProgram._Current!!
*********************************WARN_ONCE*********************************
File r300_render.c function r300_get_num_verts line 188
user error: Need more than 2 vertices to draw primitive QS !
***************************************************************************

with a number of needed vertices varying quite widely.  Some of them
will lock up in a hard to predict manner and "SIGIO..." message can be
later found in logs. OTOH /usr/libexec/xscreensaver/noof is quite good at
locking up X server and after a short while of running that such outcome
is pretty much guaranteed.

BTW - with DRI turned on in a configuration file a line 'Option "AGPMode" "8"'
in xorg.conf is required or a server will lock up before starting and showing
any picture.  Values other than 8 are not good enough.
Comment 3 Alex Deucher 2006-03-25 04:43:02 UTC
can you try the radeon driver from xorg cvs (HEAD or the ati-1-0-branch)?
Comment 4 Erik Andren 2006-04-19 16:45:09 UTC
Ping to the bug submitter. Did testing a more current driver resolve your issue?
Comment 5 Erik Andren 2006-05-02 16:17:34 UTC
Closing this bug due to the lack of activity. If the problem still persists with
a current version of xorg and the ati 1-0-0 driver, please reopen!
Comment 6 John Schmitt 2006-05-17 06:42:45 UTC
I started experiencing random lock ups when I upgraded my machine to
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/5/i386/xorg-x11-drv-ati-6.5.8.0-1.i386.rpm
to get dual-head support on my Thinkpad T30.  I'm running Linux xxxxxxxx
2.6.16-1.2111_FC5 #1 Thu May 4 21:16:58 EDT 2006 i686 i686 i386 GNU/Linux
Comment 7 John Schmitt 2006-05-20 09:28:19 UTC
I checked out HEAD this week and built it.  I copied it from my build directory
to /usr/lib/xorg/modules/drivers/radeon_drv.so and added -ignoreABI to
/etc/kde/kdm/kdmrc and launched X.

It seems that it locks up less frequently, but it does still lock up.  I tried
it with and without the AGP and Accel options in xorg.conf.
Comment 8 Andrew D. Stadler 2006-05-31 14:55:48 UTC
My system:  IBM ThinkPad T30 with Radeon 7500 and 1400x1050 internal LCD, connected to external 
1600x1200 VGA LCD.  This system has been working reliably for months with FC3, in dual-head mode.

Updated to FC5 and found that baseline configuration no longer supported dual-head mode.

Per advice at http://www.redhat.com/archives/rhl-list/2006-May/msg02069.html I too updated my 
ATI driver to xorg-x11-drv-ati-6.5.8.0-1.i386.rpm.  Other than this module my system is 100% 'up-
to-date' per PUP.

Symptoms:  Boots correctly into dual-head mode (no problems with rhgb).  Seems to run fine for a 
while, but eventually crashes.  Complete hang - can't even SSH into it.

Note, one reliable way to hang it is to enter XScreenSaver 4.24 Preferences and click the "Mode" drop-
down list (which seems to default to "Random Screen Saver").  The 5-element list displays and the 
system is immediately frozen.  SSH remote access is dead too.
Comment 9 Andrew D. Stadler 2006-05-31 15:13:14 UTC
Note, per FreeDesktop bug 7019, the hang may be related to 24 bit mode.  I switched both monitors to 16 
bit mode and the reliable crash (XScreenSaver 4.24 Preferences) is *resolved*.
Comment 10 Andy Markov 2006-06-04 17:34:19 UTC
The problem is not related to 24-bit mode. I have 3-card (Radeons) 3-monitors 
setup, all running at 16-bit depth. Works in FC4, freezes with same xorg.conf in
FC5. 
Comment 11 Andrew D. Stadler 2006-06-08 10:07:59 UTC
In a similar bug being tracked at fedora bugzilla (#190751) I was asked if DRI
was running.  I tried the configuration matrix and noted the following.  (In
case it helps here)

It looks like DRI is disabling itself on my machine for two different reasons. 
Here are the modes I tested.

16 bpp, single head:  DRI enabled
24 bpp, single head:  DRI disabled:

(EE) RADEON(0): Static buffer allocation failed.  Disabling DRI.
(EE) RADEON(0): At least 17325 kB of video memory needed at this resolution and
depth.
(**) RADEON(0): RADEONInitMemoryMap() :
(**) RADEON(0):   mem_size         : 0x01000000
(**) RADEON(0):   agp_size         : 0x0a1b41f0
(**) RADEON(0):   agp_base         : 0x0a1b41f0
(**) RADEON(0):   MC_FB_LOCATION   : 0xe8ffe800
(**) RADEON(0):   MC_AGP_LOCATION  : 0xffffffc0

16 or 24 bpp, dual head:  DRI Disabled:

(WW) RADEON(0): Direct Rendering Disabled -- Dual-head configuration is not
working with DRI at present.
Please use the radeon MergedFB option if you want Dual-head with DRI.


I don't have any experience with MergedFB and I haven't tried that
configuration.  Should I?
Comment 12 Alex Deucher 2006-06-08 11:07:00 UTC
(In reply to comment #11)
> In a similar bug being tracked at fedora bugzilla (#190751) I was asked if DRI
> was running.  I tried the configuration matrix and noted the following.  (In
> case it helps here)
> 
> It looks like DRI is disabling itself on my machine for two different reasons. 
> Here are the modes I tested.
> 
> 16 bpp, single head:  DRI enabled
> 24 bpp, single head:  DRI disabled:
> 
> (EE) RADEON(0): Static buffer allocation failed.  Disabling DRI.
> (EE) RADEON(0): At least 17325 kB of video memory needed at this resolution and
> depth.

You don't have enough videoram to enable 3D at the desktop size you specified.

> 
> 16 or 24 bpp, dual head:  DRI Disabled:
> 
> (WW) RADEON(0): Direct Rendering Disabled -- Dual-head configuration is not
> working with DRI at present.
> Please use the radeon MergedFB option if you want Dual-head with DRI.
> 
> 
> I don't have any experience with MergedFB and I haven't tried that
> configuration.  Should I?

If you want direct rendering with dualhead, you'll need to use mergedfb.
However, if you don't have enough vram for 3D with a single head config, I doubt
you'll have enough for dualhead.

Comment 13 Andrew D. Stadler 2006-06-09 10:22:59 UTC
Just to be clear, I don't want or need 3D or any other acceleration (not that I
wouldn't mind having it) - I mainly use this system to run eclipse and write
code.  I just want to be able to use dual-head again without system lockup.  :)
 The notes about DRI and radeonFB were simply in response to a question someone
posed to me.
Comment 14 John Schmitt 2006-06-22 17:47:11 UTC
I'm still suffering with this.  A few minutes ago I updated to the development 
version of the ATI driver (xorg-x11-drv-ati-6.6.1-1 & 
xorg-x11-server-Xorg-1.1.0-2) for FC5.  My machine locked up hard as soon as 
KDE had loaded.  I rebooted again and it seems more stable.  I just fired up 
firefox (which often coincided with a lockup) and also noof.  I'll see how it 
works out and report back.
Comment 15 Andrew D. Stadler 2006-06-22 22:13:11 UTC
Can you clarify what "noof" means?  "Nooo" crashes yet? Or perhaps "poof - it crashed"?
Comment 16 John Schmitt 2006-06-23 00:00:57 UTC
I'm referring to /usr/libexec/xscreensaver/noof.  See comment #2 by Michal
Jaegermann (https://bugs.freedesktop.org/show_bug.cgi?id=5781#c2) suggested it.
Comment 17 Andrew D. Stadler 2006-06-23 08:29:07 UTC
Sorry :) I thought "noof" was a result, not a test....   

By the way, with (xorg-x11-drv-ati-6.6.1-1 & xorg-x11-server-Xorg-1.1.0-2) are you running dual-
head, and if so how are the results?
Comment 18 John Schmitt 2006-06-23 09:44:56 UTC
In reply to comment #17: yes I am running dual-head and it works well.  
Comment 19 Michal Jaegermann 2006-06-23 10:20:36 UTC
For what is worth with my current test setup, which is using module
version 4.1.0 of radeon_drv compiled for 7.1.0 (Fedora "rawhide",
package versions xorg-x11-server-Xorg-1.1.0-22 and xorg-x11-drv-ati-6.6.1-1)
and R300 AD [Radeon 9500 Pro] graphics card, I do not see anymore lockups
with 'noof'.  Or at least they do not happen quickly. :-)

When running /usr/libexec/xscreensaver/noof from a terminal window I see:

*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 486
Software fallback:ctx->Line.SmoothFlag
***************************************************************************

and after that this runs without apparent problems.

OTOH I still need "AGPMode" set explicitely to 8 or I end up with locked
up X server.  More details about that at:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194105
Comment 20 Andrew D. Stadler 2006-06-23 13:43:11 UTC
I'm sorry to report that I upgraded to (xorg-x11-drv-ati-6.6.1-1 & xorg-x11-server-Xorg-1.1.0-2) 
and experienced the same spurious lockups while in Dual-Head mode.   I was not able to use the 
system for more than about 15 minutes at a time before it would hang.  I am having to switch back to 
single-head for now.

To reiterate, my system is:  IBM ThinkPad T30 with Radeon 7500 and 1400x1050 internal LCD, 
connected to external 1600x1200 VGA LCD.  This system has been working reliably for many months 
with FC3, in dual-head mode (as my primary development platform).

Is it possible to confirm that this bug is playing any role in active driver development?  And if so, is 
there anything else we can do to assist in debugging it (e.g. is there a development version that would 
log more information before crashing so badly?)

Comment 21 Michel Dänzer 2006-06-25 07:41:49 UTC
(In reply to comment #20)
> 
> This system has been working reliably for many months 
> with FC3, in dual-head mode (as my primary development platform).
> 
> Is it possible to confirm that this bug is playing any role in active driver
development?  And if so, is 
> there anything else we can do to assist in debugging it

As it seems to be a regression, isolating the guilty change(s) with git bisect
would be great.
Comment 22 Andrew D. Stadler 2006-06-26 06:47:31 UTC
I wouldn't even know where to begin in terms of knowing which versions to
obtain, or, how to build them reliably.  I am, however, more than happy to
participate in such a test, in terms of installing and trying out various
flavors of the driver.  I try to be a very careful and thorough bug reporter,
because it's what I demand from people who are reporting bugs in my code too.

So...  If anyone is out there who can feed me regression-test drivers, I'm happy
to test them and maybe we can narrow in on this bug.
Comment 23 Erik Andren 2006-07-28 10:21:16 UTC
Help yourself by bisecting the driver.
http://www.freedesktop.org/wiki/UsingGit?action=highlight&value=bisect
Comment 24 Timo Jyrinki 2007-02-22 02:51:13 UTC
The original problem with an X300 card is probably fixed. There are other bugs about lockups available like bug 2362 and bug 5986.
Comment 25 Andrew D. Stadler 2007-02-22 12:59:42 UTC
I am no longer having crashes in dual-head mode on my Thinkpad T30.
FC6 (latest), kernel 2.6.19-1.2911.fc6, X 7.1.1, ati driver 6.6.3.