Re: [r300] r300 driver locks up with Xglx

[Nicolai H. <pre...@gm...>]

On Friday 01 July 2005 16:31, Lorenzo Colitti wrote:
> Peter Zubaj wrote:
> > Some of r300 driver lockups are card dependant (and for now I have
> > only these card dependand lockups). Cards which will lock (soon or
> > later) are  9500 Pro (maybe 9500 too), 9700, 9800. What card do you=20
have ?
>=20
> According to lspci, it's an "ATI Technologies Inc RV350 [Mobility Radeon=
=20
> 9600 M10]"

That chip is actually known to work fine. Have you tried to run ordinary=20
OpenGL applications within the normal X.Org server (e.g. Glean, TuxRacer,=20
Cube, ...)? Are you seeing lockups there, too?

If the lockups happen only with Xglx, this could well be an Xglx-specific=20
software issue. In this case, you should try enabling the DRM debugging=20
options (modprobe drm debug=3D1) and have a look into the=20
dmesg/syslog/wherever kernel messages end up on your system to see what=20
happens around the the time of lockup. Also, you should obviously make sure=
=20
that all your components are recent (X.Org CVS, r300 CVS, Mesa CVS).

> > Try to load fglrx 2d driver first, then uload it and then use r300=20
driver.
>=20
> I don't use fglrx, both because it's closed source and because I don't=20
> want to litter my system with a lot of files I don't know about. Would=20
> installing it help to debug the problem or is it just a workaround? If=20

It's a workaround only. fglrx seems to perform some initializations that=20
we're missing, but so far this workaround seems to be relevant to plain=20
R300 hardware anyway (i.e. *not* RV350).

> it's only a workaround, I can simply not try to use Xglx: it doesn't=20
> work anyway...

If it's a bug on our (i.e. the driver's) side, we should fix it, whether or=
=20
not Xglx itself is in a usable state. It's likely that Xglx hits code paths=
=20
that aren't used by most programs.

cu,
Nicolai