I forgot to mention what this is..

05:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]

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.

can you try the radeon driver from xorg cvs (HEAD or the ati-1-0-branch)?

Ping to the bug submitter. Did testing a more current driver resolve your issue?

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!

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

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.

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.

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*.

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. 

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?

(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.

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.

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.

Can you clarify what "noof" means?  "Nooo" crashes yet? Or perhaps "poof - it crashed"?

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.

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?

In reply to comment #17: yes I am running dual-head and it works well.  

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

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?)

(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.

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.

Help yourself by bisecting the driver.
http://www.freedesktop.org/wiki/UsingGit?action=highlight&value=bisect

The original problem with an X300 card is probably fixed. There are other bugs about lockups available like bug 2362 and bug 5986.

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.