http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #36 from Arren Lex <[EMAIL PROTECTED]> 2008-05-18 18:17:47 PST ---
Interestingly enough, I don't experience a lockup when running this test case
on an X300SE, either before or after this patch (commit
0a96173cc38e506728d4c3f2dd383b
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #35 from Michel Dänzer <[EMAIL PROTECTED]> 2008-04-08 01:03:34 PST
---
(In reply to comment #34)
> Or improve the error handling.
That's tricky to get right though, and can cause different problems. E.g. if
something gets an erro
http://bugs.freedesktop.org/show_bug.cgi?id=15203
Markus Amsler <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #33 from Michel Dänzer <[EMAIL PROTECTED]> 2008-04-07 09:27:22 PST
---
(In reply to comment #32)
> Could someone with commit right in xf86-video-ati increase the default timeout
> from 1 to 10?
Done.
On the DRM side, I
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #32 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-03 06:28:18 PST
---
Just did some extensive testing with timeout increased by factor 10. No crashes
whatsoever. It looks like all Wow related lockups on my machine are because of
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #31 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-02 06:01:37 PST
---
Created an attachment (id=15628)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15628)
Handle error in BEGIN_RING macro
Is this an acceptable patch? Retu
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #30 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-02 03:34:50 PST
---
Created an attachment (id=15627)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15627)
Wait forever fix
Currently I have this patch in my tree. It's no i
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #29 from Michel Dänzer <[EMAIL PROTECTED]> 2008-04-02 02:14:48 PST
---
I think the best intermediate solution would be to increase the timeout. In the
long run, the error should be propagated and handled properly everywhere. The
l
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #28 from Michel Dänzer <[EMAIL PROTECTED]> 2008-04-02 01:48:07 PST
---
(In reply to comment #27)
> I would rather we just disable the writeback than adding some work around[...]
Disabling writeback is just a workaround...
--
C
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #27 from Oliver McFadden <[EMAIL PROTECTED]> 2008-04-01 22:19:10
PST ---
I would rather we just disable the writeback than adding some work around
(increase the timeout, etc); we've got enough problems that I'd rather not add
more
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #26 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-01
13:08:32 PST ---
(In reply to comment #25)
> I know now whats happening. If the ring buffer gets low on space
> radeon_wait_ring is called. If writeback is enabled radeon_
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #25 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 12:27:49 PST
---
I know now whats happening. If the ring buffer gets low on space
radeon_wait_ring is called. If writeback is enabled radeon_wait_ring can run
into the -EBUSY t
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #24 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 09:42:10 PST
---
Disabling writeback with no_wb=1 also makes the lockup disappear. And no, it's
not an april fools joke :).
Resolving this should be easy now.
--
Configure b
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #23 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 07:49:50 PST
---
You're right, it's the ring pointer update size. Values less than or equal 8
work fine, greater or equal 9 causes crashes. Perhaps increasing it further
would
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #22 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-01
05:23:51 PST ---
I fail to see what's wrong with this commit. Clearly we shouldn't update the
ring pointer for every command read (which just causes almost as much data
tr
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #21 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 01:15:59 PST
---
The mask patch didn't help
With 318157.. reverted texsub runs fine with tris=1000. I notice the pattern in
the triangles too.
I looked at RADEON_CP_RB_CNTL
Wit
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #20 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-31 21:11:52
PST ---
Another thing I just noticed: on fglrx this demo appears to render a single
solid triangle (eg, there isn't any depth fighting) but on R300 DRI there is a
lo
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #19 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-31 21:04:01
PST ---
Btw, I just did another test with the test program from this bug report, and
I've found something interesting.
I'm using a GARTSize of 64 and I've reverted
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #18 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-31 20:31:27
PST ---
Created an attachment (id=15593)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15593)
Added masks for CP_RB_CNTL
--
Configure bugmail: http://bugs.f
http://bugs.freedesktop.org/show_bug.cgi?id=15203
Oliver McFadden <[EMAIL PROTECTED]> changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #16 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-31 18:53:10 PST
---
Yeah, I meant the ring buffer. My theory wasn't that bad after all :)
It's definitely a regression introduced with
commit 31815730732a5d2a446aa316a5b4d837766
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #15 from Michel Dänzer <[EMAIL PROTECTED]> 2008-03-31 04:04:58 PST
---
(In reply to comment #14)
> Currently my favorite theory is that it has to do with the command buffer
> running out of space.
If you mean the ring buffer, I t
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #14 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-30 15:55:11 PST
---
Yeah, I'm sure, checked twice. Lockup always within 2-3 seconds.
Currently my favorite theory is that it has to do with the command buffer
running out of spac
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #13 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-30 09:32:23
PST ---
Are you sure you're using the latest DRM from Git? I've already merged the
R300_CMD_WAIT patch, so you don't need to worry about manually patching
anymore;
j
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #12 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-29 15:32:57 PST
---
Created an attachment (id=15568)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15568)
Emitting wait
(In reply to comment #10)
> (In reply to comment #9)
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #11 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-29 10:53:25
PST ---
Created an attachment (id=15563)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15563)
r300: Correctly translate the value for the R300_CMD_WAIT command
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #10 from Michel Dänzer <[EMAIL PROTECTED]> 2008-03-28 15:11:24 PST
---
(In reply to comment #9)
> Emitting wait doesn't help.
What exactly did you try?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #9 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-28 13:56:19 PST
---
Emitting wait doesn't help.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Yo
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #8 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-27 22:23:03
PST ---
I would rather *NOT* see this patch committed to Mesa, as it really just hides
the issue: we're doing something wrong, which should be fixed.
This must be a
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #7 from Michel Dänzer <[EMAIL PROTECTED]> 2008-03-27 11:19:26 PST
---
Synchronously waiting for idle on each flush is a pretty large hammer... does
just emitting wait for idle commands to the CP instead help as well?
--
Configu
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #6 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-27 10:52:37 PST
---
Its has a 30% performance impact on Wow, but only 1% on glxgears. It also
doesn't fix the Wow lockup I was after in the first place. It's also possible
that it
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #5 from Jerome Glisse <[EMAIL PROTECTED]> 2008-03-27 07:39:36 PST
---
(In reply to comment #4)
> Created an attachment (id=15493)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15493) [details]
> mesa patch
>
> This patch ma
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #4 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-26 17:37:02 PST
---
Created an attachment (id=15493)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15493)
mesa patch
This patch makes the lockup gone. I have absolutely no c
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #3 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-26 06:17:14 PST
---
Created an attachment (id=15472)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15472)
drm log with RADEON_FIFO_DEBUG
--
Configure bugmail: http://bugs.
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #2 from Oliver McFadden <[EMAIL PROTECTED]> 2008-03-26 04:51:08
PST ---
I just tested this on my development box (r300-vertprog-branch, ATI
Technologies
Inc RV410 [Radeon X700 Pro (PCIE)) and I can reproduce the lockup.
The first
http://bugs.freedesktop.org/show_bug.cgi?id=15203
--- Comment #1 from Markus Amsler <[EMAIL PROTECTED]> 2008-03-25 13:17:05 PST
---
Created an attachment (id=15456)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15456)
drm log where system didn't freeze.
--
Configure bugmail: http://
36 matches
Mail list logo
