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 might run in to this problem.
static void radeonWaitIrq(radeonContextPtr radeon)
{
int ret;
+ int tries = 5;
do {
ret = drmCommandWrite(radeon->dri.fd, DRM_RADEON_IRQ_WAIT,
&radeon->iw, sizeof(radeon->iw));
- } while (ret && (errno == EINTR || errno == EAGAIN));
+ } while (ret && (errno == EINTR || errno == EAGAIN || (errno ==
EBUSY && --tries)));
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 indefinitely on
EBUSY instead of EAGAIN?
I would agree, but mu knowledge is limited.
(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 dependent on HZ?
3*HZ is always 3 seconds no matter what HZ is (provided its the same
value used to compile the kernel).
Rune Petersen
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
