Bug 922 - X locks up when switching to console
Summary: X locks up when switching to console
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high critical
Assignee: Eric Anholt
QA Contact:
: 1033 (view as bug list)
Depends on:
Blocks: 351
  Show dependency treegraph
Reported: 2004-07-26 07:19 UTC by Andrei Lahun
Modified: 2005-09-25 15:29 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

Radeon render patch (6.14 KB, patch)
2004-08-07 18:56 UTC, HUI YU
no flags Details | Splinter Review
fix for !XF86DRI and for context issues (4.92 KB, patch)
2004-08-11 01:37 UTC, Eric Anholt
no flags Details | Splinter Review

Description Andrei Lahun 2004-07-26 07:19:22 UTC
After update from Xorg CVS at the end of June i discovered that, when
i switch to console from X , Xserver start to use 100% cpu, and the only way is
to kill it and then restart.
I find out if disable renderAcceleration (Option "RenderAccel" "Off"), 
problem disappear.
My card is Radeon IGP320M, kernel 2.6.7,no frame buffer, all suspicious options
(like "4k stack", "regparam") disabled.
Comment 1 Eric Anholt 2004-07-30 08:39:24 UTC
I'll take this one, since I added the render accel to the tree.  We do need to
get this (and the breakage of the text and 3d apps mix) fixed before release, or
turn render accel back off by default.
Comment 2 Kevin E. Martin 2004-08-06 13:08:01 UTC
I've just checked in a change to disable Render acceleration by default as was
discussed on today's release wranglers call.  When this code is known to work
properly, we can re-enable it.
Comment 3 HUI YU 2004-08-07 18:56:59 UTC
Created attachment 586 [details] [review]
Radeon render patch

Here is a patch I put together for fixing following render problems with 
radeon driver in current CVS code:
1. MMIO mode support should work now.
2. Hang on IGP chips -- caused by TCL bypass not being set.
3. VT switching hang -- caused by 3D code in RADEONEnterServer.
4. 3D render corruption -- caused by 3D code in RADEONEnterServer.

I'm still experiencing random lockup in certain 3D games with R200/RV250 
chips, it appears to be render acceleration related (context switching 
problem). But I haven't figured out the exact cause.

In general, new render xaa code looks good, it's more efficient than 
before, just need more time to get driver support more stable.
Comment 4 Eric Anholt 2004-08-09 12:32:43 UTC
Looks pretty good on reading it, except for a couple of notes:
- The render stuff in radeon_accelfuncs.c needs to have the #if defined(XF86DRI)
and the XXX comment removed
- Context switching is still apparently an issue, and I'm concerned about
removing the setting of context owner in enterserver.  However, given bug 770
and another I can't seem to find right now, we need to be looking at context
switching in general, and that may be a blocking bug.
- I trust you to set up the TCL disabling properly -- I was trying to base off
of what I read in the DRI driver, but I didn't really have more info than that.
Comment 5 Kevin E. Martin 2004-08-09 12:40:03 UTC
Eric, I can go ahead and make the changes that you suggest.  Do you see any
problems with me checking in Hui's patch so that we can get more testing?  If
not, I will take care of it with my next check-in later today.
Comment 6 Eric Anholt 2004-08-09 13:14:56 UTC
Sounds good to me.  I've got the change in my current build.  I'll see if anyone
has any clues about the context switching issues during the dri-devel meeting
and I guess try to work on it once I get a couple of FreeBSD things done. 
Either way, the current diff plus removing the XF86DRI and XXX comment is better
than the previous situation.
Comment 7 Kevin E. Martin 2004-08-09 15:45:01 UTC
The patch has now been applied with the changes that Eric suggested.

I'm leaving this one open since there are still some issues that need to be
resolved -- see comments #3 and #4.
Comment 8 Michel Dänzer 2004-08-10 08:22:36 UTC
I still don't like the 3D state handling and propose the following scheme
instead (sorry, no time for a patch ATM):

* Mark 3D state as invalid in ScreenInit() and EnterServer() (if SAREA ctxOwner
isn't the server's context number)
* Upload 3D state in SetupTexture() only if marked invalid, mark it as valid and
set SAREA ctxOwner to server's context number

The 3D rendering problems are probably due to known (and unfortunately deeply
rooted...) bugs with multiple contexts in the r200 3D driver, or has anyone seen
them with R100 chips as well?
Comment 9 Eric Anholt 2004-08-10 12:02:20 UTC
I agree with that.  I'm currently trying to look at the r200 context issues, but
it's my first real attack on the radeon/r200 drivers, so it's slow going.
Comment 10 Eric Anholt 2004-08-11 01:37:20 UTC
Created attachment 601 [details] [review]
fix for !XF86DRI and for context issues

Attached an untested patch to fix up the context switch handling according to
Michel's suggestions, along with fixing the !XF86DRI build.  It would have been
tested, but I'm too tired right now, and want to have this around to point
people with !XF86DRI build troubles to for the night.
Comment 11 Kevin E. Martin 2004-08-11 07:09:21 UTC
Mike Harris also fixed the !XF86DRI case in bug 1033 in a slightly different way.
I'll mark that bug as a dup of this one.
Comment 12 Kevin E. Martin 2004-08-11 07:10:38 UTC
*** Bug 1033 has been marked as a duplicate of this bug. ***
Comment 13 Kevin E. Martin 2004-08-11 22:00:33 UTC
Patch tested on R100, RV100 and R200.  All worked fine so patch checked in.
Comment 14 Kevin E. Martin 2004-08-12 18:29:16 UTC
Are there other changes necessary here?  If not, let's close this one.
Comment 15 Eric Anholt 2004-08-12 23:52:54 UTC
The actual issue reported should be fixed, so mark it fixed.  Will open a new
bug for current Render concerns.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.