On Sun, Jan 18, 2004 at 07:24:44PM +0100, Michel Dänzer wrote:

On Sun, 2004-01-18 at 18:28, Sven Luther wrote:

quoted

On Sun, Jan 18, 2004 at 05:33:21PM +0100, Michel Dänzer wrote:

quoted

On Sun, 2004-01-18 at 15:44, Sven Luther wrote:

quoted

quoted

The freeze happens when i first launch glxinfo, or when i first start
moving a window around (using a debian/unstable default gnome desktop).
I don't remember well, but i think it would also freeze when let running
for a time, but i am not sure.

It would be quite interesting to know, see below.

But then, maybe it has something to do with the GL screensaver or
something such. The problem is that i have this box on the analog entry
of my dual entry monitor, and mostly work on the box connected to the
DVI connector, so it usually died while i was not looking.

quoted

quoted

quoted

The box is still available trough ssh, but killing the X server
doesn't restore the fbdev console, and freeze the box.

Sounds like a typical chip lockup, possibly caused by the chip not
reading from the CP ring what we're writing to it.

Well, not sure. Compared to the pegasos 1 situation, where nothing
showed up on the screen, except the hardware cursor, Things seem to work
out fine at first, and only certain operation make it happen. The gdm
prompt comes up, you can log in, then once logged in, you can open a
gnome-terminal, and even do some stuff. Once you try moving the window
though, it starts moving, but then quickly freezes.

Because the RENDER extension isn't accelerated, that might be the first
time the ring is heavily used.

Yep. Altough this problem doesn't occur for the Radeon 7500 on the same
board. I believe it may be triggered by some problem which is present in
the R200 code path, and which is present in the R100 software T&L (since
i think the 7000 and 7200 lack a T&L engine).

It might also occur when the ring wraps around; whether or not it also
happens when the server is idling would give a hint about this, or even
better instrumenting the wraparound handling code in the DRM.

Ok, i will look into this and do some experiments. What is the size of
the ring anyway ? 4K or something such ?

quoted

I believe there is maybe more a problem with the CPU and the graphic
chip being in disacord over the size of the CP ring.

I'd expect problems everywhere if that code wasn't correct.

Mmm.

quoted

Come to think of it, i have three negative tries (Radeon 7000, 7200 and
9200SE) and one positive (Radeon 7500), or at least claimed such, the
glxgears numbers obtained with the Radeon 7500 where not all that high
(maybe 300 or so), but still higher than the software only numbers i
obtain on my box with Radeon 9200 SE.

PCI GART isn't very fast in general, it's even mysteriously slow on some
systems, see the dri-devel list archives.

Ok. There is no other chance anyway, since there is no true AGP bus on
these boxes. The nortbridge used is a communication controller after
all.

quoted

Also, the Radeon 9200 SE has only 64bit memory interface. I don't know
about 7000 and 7200, but maybe this is also the case for them, while the
7500 could have 128bit memory interface ? Not sure, will investigate.

I doubt that matters.

I doubt it too. But then, if the chip measures data in multiples of the
memory words or something such, it may have an influence.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/