From: Roland S. <rsc...@hi...> - 2006-05-27 17:11:46
|
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? (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? Roland |