Bug 144867 - Xwindows locks with radeon DRI enabled
Summary: Xwindows locks with radeon DRI enabled
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
: 152312 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-12 04:31 UTC by David A. Cafaro
Modified: 2015-01-04 22:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-29 05:21:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Photo of locked display (52.68 KB, image/jpeg)
2005-04-08 02:55 UTC, David A. Cafaro
no flags Details

Description David A. Cafaro 2005-01-12 04:31:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
When starting Xorg (Xwindows) the computer screen will lock, and can
not be brought down (ctrl-alt-backspace does nothing, can't switch
screens either).

In the 2.6.10 kernel, the screen comes up all funky looking, with a X
windows mouse cursor that responds to the touchpad movement.  The
system stops at this point and though the mouse continues to move
fine, there is no response to the keyboard (cannot ctrl-alt-backspace
or reboot via keyboard).  It is still possible to ssh into the machine
and poweroff the system, but kill commands to the xserver seem to fail
to return the screen to the console.

In the 2.6.9 kernel, the screen stays blank and the entire system locks.

Removing the "load DRI" line clears the problem and normal Xwindows
functionality returns.

Version-Release number of selected component (if applicable):
kernel-2.6.9-1.667, kernel-2.6.10-1.737_FC3, xorg-x11-6.8.1-12.FC3.21

How reproducible:

Steps to Reproduce:
1. run startx with radeon driver and dri enabled

Additional info:

ATI Radeon Mobility M6 LY

Comment 1 David A. Cafaro 2005-01-14 20:01:44 UTC
Alright I tried re-installing and doing all updates except the xorg
related ones.  Using kernel-2.6.10-1.741_FC3 and the older xorg-x11
that comes with FC3 initialy I still get the same screen lock.  BUT
the 2.6.9-1.667 does not lock the screen and it works normally.

So something in both the kernel-2.6.10-1.741_FC3 package and the
xorg-x11-6.8.1-12.FC3.21 independently cause this lock up (system can
still be rebooted, vie alt-ctl-del, but that's about it).  I'll
experiement further, but it's a slow process.

Comment 2 David A. Cafaro 2005-01-14 20:57:43 UTC
Confirmed the following:

kernel-2.6.10-1.741_FC3 + xorg-x11-6.8.1-12.FC3.21 + DRI = Locks

kernel-2.6.10-1.741_FC3 + xorg-x11-6.8.1-12.FC3.21 - DRI = Works

kernel-2.6.10-1.741_FC3 + xorg-x11-6.8.1-12 + DRI = Locks

kernel-2.6.10-1.741_FC3 + xorg-x11-6.8.1-12 - DRI = Works

kernel-2.6.9-1.667 + xorg-x11-6.8.1-12.FC3.21 = Works

kernel-2.6.9-1.667 + xorg-x11-6.8.1-12 = Works

Not sure why the 2.6.9 kernel is working now, and not before.  The
2.6.10 now seems to be the only common factor in the lock ups.  Will
experiment more.

Comment 3 David A. Cafaro 2005-04-08 02:55:43 UTC
Created attachment 112845 [details]
Photo of locked display

Comment 4 David A. Cafaro 2005-04-08 02:57:54 UTC
This problem still occurs in the 2.6.11-1.7_FC3.i686.rpm from FC3 test.

At this point any kernel after 2.6.9 with DRI enabled causes the xserver to fail
to load correctly and to lock out keyboard actions.  The image displayed is a
distored image of the systems boot graphic (ie during bios startup).  The mouse
still responds and the Xwindows X cursor is present (though not the window
mangers normal arrow cursor).  So you can move the mouse, see it move, but no
clicks do anything, and you can't switch consoles, or force the xserver to
shutdown.  The system fails to respond to the keyboard.  I can ssh in from a
remote system and cleanly shutdown the system.  There are no error messages in
the xorg log files.  The last messages are the mouse/touchpad being initialized
and that's it (as expected).  I've included a camera shot of the laptops screen
after the xserver has failed (posted above).

I'm currently trying to compile a stock 2.6.11-6 kernel to test with and see if
this is an upstream issue.

Comment 5 David A. Cafaro 2005-04-08 03:05:58 UTC
Also forgot to add this is on a Sharp MM20 Laptop (based on a Transmeta Efficeon
processor).  I also found the following bug which seems to have the same issue:


Comment 6 David A. Cafaro 2005-04-08 11:39:17 UTC
I have confirmed that this is repeatable with a stock kernel downloaded
from kernel.org.  All other systems seem to start up fine, but the same messed
up image, moving mouse pointer and unresponsive keyboard as above is present.

Comment 7 David A. Cafaro 2005-04-12 13:50:04 UTC
Just confirmed, it's still broken with kernel 2.6.11-1.14_FC3.  Just tried the
update, and it locks the same way.  Can still ssh in remotely and cleanly

Comment 8 David A. Cafaro 2005-04-18 17:22:54 UTC
Ok, I tried something new, and narrowed the issue down to something with the AGP
driver used.  By using Option "BusType" "PCI" and forcing the xorg to use the
AGP card as a PCI card, everything works as expected.  The only issue being that
it is slower than Using AGP mode. 

I also filed a bug upstream with kernel.org since I found the same issue with a kernel I compiled from them.  That bug can be found here:

Comment 9 Dave Jones 2005-07-15 20:07:03 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 10 David A. Cafaro 2005-07-20 14:05:17 UTC
Unfortunately, the problem persists with the latest kernel.  Currently running
kernel-2.6.12-1.1372_FC3 with xorg-x11-6.8.2-1.FC3.13 on Fedora Core 3.  Same
issue as before, still get the moving mouse on a black screen with screwed up
images at the very top.  No keyboard response, but the system isn't locked, can
ssh in and cleanly shutdown the system.  With Option "BusType" "PCI" set the
system will boot into xwindows with DRI enabled.  With out setting it to "PCI"
then the screen locks as described above.  

I have not tried FC4 on this system yet.

Comment 11 Dave Jones 2005-08-04 01:12:17 UTC
*** Bug 152312 has been marked as a duplicate of this bug. ***

Comment 12 Dave Jones 2006-01-16 22:38:44 UTC
This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.

Comment 13 David A. Cafaro 2006-01-16 23:38:32 UTC
This problem is still happening in FC4.  I just installed FC4 on this laptop
again and have found that DRI does not work in AGP or PCI mode.  Current packages:

2.6.14-1.1656_FC4 and xorg 6.8.2-37.FC4.49.2

I have yet to try using a stock 2.6.15 kernel from kernel.org yet.

Comment 14 Dave Jones 2006-02-03 06:59:12 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Comment 15 David A. Cafaro 2006-03-26 22:01:12 UTC
Ok, the solution to this has been tracked down, please see this kernel bug
report for the solutions.


Quick summary:
Narrowed down to a missing function in the efficeon-agp driver.  Patch has been
developed and tested succesfully.

Glad to have it working again, and a big thanks to all that narrowed this down
and fixed it!  Look forward to seeing this patch in future kernels.

Comment 16 H. Peter Anvin 2006-04-19 19:21:34 UTC
This bug does also exist in FC5.

Comment 17 Dave Jones 2006-07-29 05:21:04 UTC
Should be fixed in the latest errata for both FC4 & FC5.

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