Bug 31459

Summary:	DRM unstable on G200; recommend disabling by default
Product:	[Retired] Red Hat Linux	Reporter:	Ed McKenzie <eem12>
Component:	XFree86	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-03-13 06:33:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ed McKenzie 2001-03-11 20:48:25 UTC

IME, accelerated 3D on matrox G200 is quite unstable (I'd hesitate to call
its current state "beta"), and I don't think it should be enabled by
default in the 7.1 release.  To wit:

- I can't leave xscreensaver running all night in 'random screensaver'
mode; I always come back in the morning and find it locked up displaying a
3D screensaver.

- 3D in a window will always lock up the Xserver if that window is left
fully occluded for any length of time.

- Resizing windowed 3D apps isn't as surefire a way to crash the Xserver,
but it works some of the time.

- Lockups seem to leave the rest of the system running, but alas, killing
XFree leaves the console in an unusable state. Running the Xserver on
matroxfb with a software cursor makes it possible to recover the console,
but if sysrq isn't enabled, this is only possible remotely.

Anyway, I think drm should be disabled by default for G200 cards in 7.1
final, especially since the default screensaver is 'random'. Too much black
magic is needed to use drm without destabilizing the entire system.
Non-root users shouldn't be able to crash the system with such ease.

Comment 1 Mike A. Harris 2001-03-13 03:38:23 UTC

XFree86 and Mesa are closely linked.  If the Mesa you're using is not
the proper one, these lockups can occur.  I've just recently discovered
this, and am now making XFree dependant on a specific release of Mesa
to solve the problem, but for now you should try out Mesa 3.4-11 and
XFree86-4.0.2-12.1.  I also recommend the latest kernel which fixes some
DRM issues, at least on r128 cards.

Does this fix it for you?

Comment 2 Ed McKenzie 2001-03-13 05:05:03 UTC

I don't see Mesa-3.4-11 in rawhide, but I'm testing 3.4-10 with
XFree86-4.0.2-12.1 and kernel-2.4.2-0.1.25. Will report back in a few days

Comment 3 Mike A. Harris 2001-03-13 05:19:16 UTC

You _MUST_ use Mesa 3.4-11 or you _WILL_ have problems.  ;o)
Mesa 3.4-10 is built against older XFree86 and will explode.

For the updated Mesa package:
ftp://people.redhat.com/people/Mesa

My newer XFree packages (as in from now on) will have a dependancy on the
proper Mesa in order to make sure people upgrade Mesa when upgrading X.
I think this will fix a lot of problems being reported.
Does the new Mesa 3.4-11 fix the problem?

Comment 4 Ed McKenzie 2001-03-13 05:27:28 UTC

s/people/mharris/

Rebuilding binary RPM. Stay tuned for updates

Comment 5 Ed McKenzie 2001-03-13 06:33:47 UTC

Things do generally seem alot more stable. GL apps can now be fully hidden and
re-exposed without locking up X, and it now takes ten instances of gloss to lock
up XFree (it took only four or five before):

Mar 13 01:16:48 eem12 kernel: [drm:mga_fire_primary] *ERROR* num_dwords == 0
when dispatched

...

Also, running a GL app while selecting a 3D screensaver so it previews in the
Control Center locks up X reproducibly (in this case, 'gloss' and 'GLPlanet'.)

This is all on a Matrox G200, btw, not riva128. Full-screen apps are generally
working quite nicely, except for the odd rendering error. Windowed apps are
almost as good; pop-up menus seem to interfere with GL rendering (see RMB menu
in gloss.)

All in all, things are looking much nicer than they were in Wolverine. Thanks.

Comment 6 Mike A. Harris 2001-03-15 17:10:38 UTC

Ok great, I'm closing this bug then because it appears to be more or less
fixed.  Please file a new bug report if there are still issues you find.
Also, the "r128" is the ATI Rage 128 driver, not Nvidia riva128.  Just
thought I'd let you know that..

Glad it works much better for you! New version to be realeased soon which
may fix even more stuff for you..