Am Dienstag, 30. Mai 2006 14:33 schrieb Roland Scheidegger:
Michel Dänzer wrote:
On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
Looks like quite some more work is needed to detect real lockups but not
just randomly reseting the chip when there is none (which can itself
On Wed, 2006-05-31 at 16:40 +0200, Roland Scheidegger wrote:
Michel Dänzer wrote:
Indeed. The X server's GetTimeInMillis() might be more convenient
than gettimeofday() (and would also work with an elfloader X server
;).
Ah yes. That was just a quick hack :-). The question is, what should
On Tue, 2006-05-30 at 14:33 +0200, Roland Scheidegger wrote:
Michel Dänzer wrote:
On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
Looks like quite some more work is needed to detect real lockups but not
just randomly reseting the chip when there is none (which can itself
Michel Dänzer wrote:
Indeed. The X server's GetTimeInMillis() might be more convenient
than gettimeofday() (and would also work with an elfloader X server
;).
Ah yes. That was just a quick hack :-). The question is, what should the
timeout value be?
For determining if the chip has locked up
Michel Dänzer wrote:
On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
Looks like quite some more work is needed to detect real lockups but not
just randomly reseting the chip when there is none (which can itself
lead to lockups IME).
Maybe, or maybe it's just a matter of
Roland Scheidegger wrote:
Michel Dänzer wrote:
On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
Looks like quite some more work is needed to detect real lockups but
not just randomly reseting the chip when there is none (which can
itself lead to lockups IME).
Maybe, or maybe
On Sun, 2006-05-28 at 19:57 +0200, Roland Scheidegger wrote:
Rune Petersen wrote:
(e.g. while (ret (errno == EINTR || errno == EBUSY));)
And by looking at it, does it make sense that the timeout value in the
kernel depends on the kernel-of-the-day HZ value, rather than some
Michel Dänzer wrote:
On Sun, 2006-05-28 at 19:57 +0200, Roland Scheidegger wrote:
Rune Petersen wrote:
(e.g. while (ret (errno == EINTR || errno == EBUSY));)
And by looking at it, does it make sense that the timeout value in the
kernel depends on the kernel-of-the-day HZ value, rather than
Dieter Nützel wrote:
Am Samstag, 27. Mai 2006 19:13 schrieben Sie:
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh
Roland Scheidegger wrote:
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like that ioctl will actually never return
EAGAIN, maybe the original intention was to just wait
On Sun, 28 May 2006 19:57:40 +0200
Roland Scheidegger [EMAIL PROTECTED] wrote:
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like that ioctl will
Roland Scheidegger wrote:
(e.g. while (ret (errno == EINTR || errno == EBUSY));)
And by looking at it, does it make sense that the timeout value in
the kernel depends on the kernel-of-the-day HZ value, rather than
some hardware-dependant (probably fixed) value?
Isn't the timeout value
Aapo Tahkola wrote:
On Sun, 28 May 2006 19:57:40 +0200
Roland Scheidegger [EMAIL PROTECTED] wrote:
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like
It should probably be infinite if no hw lock is being held.
Lock should be dropped in case of longer waits so that user is given a
chance to stop the process.
Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
make sense too, the user-space driver could simply redo the
Benjamin Herrenschmidt wrote:
It should probably be infinite if no hw lock is being held.
Lock should be dropped in case of longer waits so that user is given a chance
to stop the process.
Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
make sense too, the user-space
Hi,
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps might run in to this problem.
Rune
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps might run in to this
18 matches
Mail list logo
