Bug#236187: xserver-xfree86: [r128] GL lockups
On Sun, Mar 07, 2004 at 06:21:11PM +0100, Michel Dänzer wrote:
> On Sun, 2004-03-07 at 17:38, Daniel Jacobowitz wrote:
> >
> > Downgrading to xserver-xfree86 4.2.1-16 has eliminated the problem so
> > my money is on the 4.3.0 r128 driver.
>
> If you agree that your problem seems related to
> http://bugs.xfree86.org/show_bug.cgi?id=271, can you try the workarounds
> discussed there?
I'll give it a try. Looking at the code in 4.2.1 and 4.3.0 (you
probably know all this already, I'm just educating myself):
In 4.2.1 R128CCEWaitForIdle calls drmR128WaitForIdleCCE. The inner
function issues the ioctl up to 32 times, and the outer function calls
the inner function 2_000_000 times. That's 64M calls before it tries
to reset. The ioctl is DRM_IOCTL_R128_CCE_IDLE.
In 4.3.0 R128CCEWaitForIdle calls drmCommandNone. The inner function
makes only one ioctl before giving up. The outer function loops 32
times. The ioctl is DRM_IO (DRM_COMMAND_BASE + DRM_R128_CCE_IDLE),
which is the same.
Both versions pass CCEusecTimeout to the DRM module. So what am I
missing? Where'd the other 2_000_000 calls go? It went right here:
- do {
- ret = drmR128WaitForIdleCCE(info->drmFD);
- if (ret && ret != -EBUSY) {
- xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
- "%s: CCE idle %d\n", __FUNCTION__, ret);
- }
- } while ((ret == -EBUSY) && (i++ < R128_TIMEOUT));
+ /* The ioctl already has a timeout */
+ ret = drmR128WaitForIdleCCE(info->drmFD);
+ if (ret && ret != -EBUSY) {
+ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "%s: CCE idle %d\n", __FUNCTION__, ret);
+ }
And yes, looking the source to the DRM module I'm running, it does
honor the timeout. Which defaults to 10_000, so the old working
timeout was 10K * 2M * 32, and the new not working timeout is 10K * 32.
And the max settable timeout is 100K * 32. So it seems pretty clear
that, however long it takes to return to idle, it's longer than this
vastly reduced timeout.
I'm going to try your suggested changes now, along with some
instrumentation to see how long resets are really taking.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: