Aapo Tahkola wrote:
Jerome Glisse wrote:
On 6/1/05, Adam K Kirchhoff <[EMAIL PROTECTED]> wrote:
Nicolai Haehnle wrote:
What you can do: Please, test the attached
patch.drm-cmdbuf-more-pacifiers,
and report if there are any regressions (I don't believe there are any)
and/or if it removes certain lockups you are seeing.
Well, it's hard for me to judge this patch :-) I played Q3A for just
over 20 minutes without a single lockup, something I don't think I've
accomplished before. I quit that and then tried UT... Which lasted for
all of a minute or two before locking up. I rebooted and tried again
and got a lockup after only a few minutes.
If you're feeling adventurous, I'd appreciate it if you could also try
this
patch in combination with the patch.remove-userspace-pacifiers patch I
posted earlier, though this patch appears to be dangerous still (even
though I do not understand why).
Well, my last attempt with this patch resulted in immediate lockups.
Think it's still worth me testing this path in conjunction with the
above patch?
You should test it as this patch makes our driver behave more like
fglrx. I will test it too, latter this day...
Jerome Glisse
Well, I'm not getting the immediate lockups that I got before with just
the patch.remove-userspace-pacifiers. But I'm still getting seemingly
random lockups with patch.remove-userspace-pacifiers +
patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no
noticable improvements. I can still play UT and Q3A from anywhere
between 2 to 20 minutes.
I thought I'd try a little experiment. I compiled the driver on my
FreeBSD installation thanks to all the great work that had been done on
that in the past. I then created a chrooted development environment in
/compat/linux and compiled the linux version of the driver. Installed
it in the compatability environment. Both Q3A and UT started up and ran
on FreeBSD. And both locked up within the same general time frame I'm
seeing under Linux. Not sure if this helps diagnose the problems any
further, but I thought some people might be interested in hearing that
linux OpenGL apps work on r300 hardware on FreeBSD.
I did some figuring on the CB_DPATH problem.
After little testing it turns out that the lock up with
progs/demos/isosurf goes away when the pacifier sequences are applied to
clearbuffer.
Im starting to think that this sequence is needed whenever overwriting
certain states rather than whenever 3d operation begins and ends.
Any brave souls left? (patch attached)
You guys seem to be getting closer...
When I had X + xfce4 + quake3 running (with this patch +
patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X
locked up within 2 minutes.
However, X + quake3 (no window manager), I went thirty minutes before my
first problem. Quake3Arena crashed, and X quit. There was some message
on the terminal about radeon_wait and "IRQ 16". Being a fool, I typed
'dmesg' before writing down the error. Of course nothing showed up in
dmesg, and the error from X (or Q3A) was no longer in the buffer.
There was no lockup.
I started X up again (without rebooting). Went another thirty minutes
playing Q3A. Same thing happened, except that the terminal never came
back up. I ssh'ed in, and neither Q3A nor X were running. So I rebooted.
And here I sit.
Another thing I noticed. When playing Q3A with a window manager
running, every 10-30 seconds the screen goes black for a second. The
game continues, even in darkness, but this doesn't happen when running
without a window manager. I have no idea if it's related, but I thought
I'd pass it along.
Adam
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
