Error message on RV710: reserve failed for wait

Jerome Glisse jglisse at redhat.com
Thu Oct 7 11:32:56 PDT 2010


----- "Jean Delvare" <khali at linux-fr.org> wrote:

> Hi again,
> 
> On Thu, 30 Sep 2010 15:18:27 +0200, Jean Delvare wrote:
> > I am running kernel 2.6.36-rc6 on a Radeon HD4350 (RV710), and I
> see
> > the following error messages in the logs:
> > 
> > Sep 30 14:09:27 endymion kernel: [21556.560593] radeon 0000:07:00.0:
> ffff88007c334000 reserve failed for wait
> > Sep 30 14:09:29 endymion kernel: [21558.253859] radeon 0000:07:00.0:
> ffff88007c334000 reserve failed for wait
> > 
> > Sometimes that's just one or two of these, sometimes a bunch of
> them. I
> > didn't notice any major problem so far. What kind of issue may
> result
> > from this error? I see the message comes from function
> radeon_bo_wait()
> > but I have no idea what this function does.
> 
> Problem still present in 2.6.36-rc7. I have investigated it myself,
> and
> here's what I found.
> 
> The error code returned by ttm_bo_reserve() to radeon_bo_wait() when
> I
> get this error message is EBUSY. This can only happen when
> ttm_bo_reserve() isn't allowed to wait (no_wait=true). The only
> caller
> passing no_wait=true is radeon_gem_busy_ioctl(). So, as a summary, I
> see an error message in the kernel log whenever
> radeon_gem_busy_ioctl()
> tries to process some ioctl but can't get access to some kernel data
> it
> needs. Sorry for being vague here but I'm not familiar with the code
> at
> all, so that's the best I can say.
> 
> I don't know who exactly is calling radeon_gem_busy_ioctl(), as it
> can
> only be reached through a function pointer. I presume this is the X11
> radeon driver, in user-space?
> 
> Jerome, you wrote that part of the code, maybe you could suggest a
> course of action? Is it OK for the radeon kernel driver to return
> -EBUSY to user-space in that case? If it is OK, then the error
> message
> shouldn't be printed, or maybe it should be degraded to a debugging
> message. If it isn't OK, what can be done to avoid it?
> 
> Thanks,
> -- 
> Jean Delvare

Your analyze is correct we should not print the error message.
I let you do a patch to remove the error message. Thanks for
looking into this.

Cheers,
Jerome


More information about the dri-devel mailing list