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 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.
So is mine...
(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).
Ah right. I think I misinterpreted something. That said, 3 seconds
sounds like a rather long time, why would there still be timeouts?
Its not that long time for a benchmark.
Depends on how much work you can queue up. Of course, you could do
something like draw 65000 screen-sized quads with a single rendering
command (with a complicated fragment shader attached), which could take
a bit long...
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 ioctl (it
could also drop the lock before it retries). Which probably really is
what was intended, just that it checks for EAGAIN instead of EBUSY
(though the code does not drop and retake the lock) by mistake.
Roland
-------------------------------------------------------
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
