Bug 476590 - radeonhd - glxgears causes hard lockup on V5200
radeonhd - glxgears causes hard lockup on V5200
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-radeonhd (Show other bugs)
10
i386 Linux
low Severity high
: ---
: ---
Assigned To: Hans Ulrich Niedermann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-15 18:38 EST by Nigel Jones
Modified: 2009-11-28 04:36 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-28 04:36:47 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)
xorg config file (1.56 KB, application/octet-stream)
2008-12-15 18:38 EST, Nigel Jones
no flags Details

  None (edit)
Description Nigel Jones 2008-12-15 18:38:58 EST
Created attachment 327035 [details]
xorg config file

Description of problem:

Fedora 10 with latest radeonhd -- Thinkpad T60p with ati V5200 graphics appears to lock solid after 5-30s when "glxgears" or "google earth" is used

Using regular desktop (metacity). DRI / EXA enabled.

Version-Release number of selected component (if applicable):
xorg-x11-drv-radeonhd-1.2.4-1.1.20081212git.fc10.i386

seen in varying builds over last few weeks

(also varying kernels up to/including 2.6.27.9-155)

F10 Kernel is booted with "nopat nomodeset"


How reproducible:
Very.

Steps to Reproduce:
1. Enable EXA, DRI with radeonhd
2. Login
3. Start glxgears
  
Actual results:
Decent framerates (~1400 fps) reported, gears drawn successfully for a few iterations
Then system freezes hard. caps lock etc inoperable. Screen remains static. Not pingable. 

Expected results:
System continues to operate normally

Additional info:

Appears to be same problem as reported here -> http://bugs.freedesktop.org/show_bug.cgi?id=19008

However the reported duplicate bug is not the same

Real xorg.conf added -- note I use this for both radeon and radeonhd, so many radeon parms are in the file...
Comment 1 Nigel Jones 2008-12-16 02:35:17 EST
Lockup does not occur with radeon driver (thathas other problems).

Also by trial/error narrowed it down to "EXA" vs "XAA".

With EXA the crash occurs
With XAA the crash *does not occur*, although the performance is ~15% down.

All other options (except DRI) stripped from device section to prove this.
Comment 2 Hans Ulrich Niedermann 2008-12-16 08:37:12 EST
Might this be this bug? http://bugs.freedesktop.org/show_bug.cgi?id=18097
It mentions a workaround using EXANoComposite.
Comment 3 Nigel Jones 2008-12-17 01:41:26 EST
With EXANoComposite=TRUE, glxgears appears to continue running normally, when in EXA mode -- so it does seem to relate to composite acceleration in radeonhd ?
Comment 4 Nigel Jones 2008-12-17 04:05:52 EST
Update -- after running the above test I suspended, traveled to office, resumed, and used xrandr to enable second screen [DVI] (I do this every day).

Out of interest I ran glxgears, and the display locked hard before the gears themselves were even rendered -- only the frame appeared.

Paying close attention to the system, the disk light remained active for ~30s, but no flashnig caps lock etc -- so no dump. The screen was displayed, but frozen. Could not check network connectivity (DHCP)

Reverting back to XAA and will retry at next opportunity.

ANy suggestions for ways to get better debug happily taken if it helps in PD.
Comment 6 Samuel Sieb 2009-02-24 16:07:23 EST
You have this filed under xorg-x11-drv-ati, but you mention using the radeonhd driver.  Those are two different drivers, which one are you using?
Comment 7 Nigel Jones 2009-05-14 14:58:49 EDT
This bug was raised when using radeonhd. However recent developments during 2009 have made radeon driver work better. Since I'm no longer using radeonhd I suggest this bug is closed?
Comment 8 Bug Zapper 2009-11-18 04:41:22 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Vedran Miletić 2009-11-28 04:36:47 EST
Closing per comment #7.

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