Error message on RV710: reserve failed for wait

Error message on RV710: reserve failed for wait

[Jean Delvare]

Hi all,

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.

Here are the messages related to my Radeon card as found in the kernel
boot log:

[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
  alloc irq_desc for 30 on node -1
  alloc kstat_irqs on node -1
radeon 0000:07:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
radeon 0000:07:00.0: setting latency timer to 64
[drm] initializing kernel modesetting (RV710 0x1002:0x954F).
[drm] register mmio base: 0xFBEE0000
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon 0000:07:00.0: VRAM: 512M 0x00000000 - 0x1FFFFFFF (512M used)
radeon 0000:07:00.0: GTT: 512M 0x20000000 - 0x3FFFFFFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 1024276 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
  alloc irq_desc for 64 on node -1
  alloc kstat_irqs on node -1
radeon 0000:07:00.0: irq 64 for MSI/MSI-X
radeon 0000:07:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RV710 Microcode
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Enabling audio support
failed to evaluate ATIF got AE_BAD_PARAMETER
[drm] Default TV standard: NTSC
[drm] Default TV standard: NTSC
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]	VGA
[drm]	DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]	Encoders:
[drm]	  CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm]	HDMI-A
[drm]	HPD1
[drm]	DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]	Encoders:
[drm]	  DFP1: INTERNAL_UNIPHY
[drm] Connector 2:
[drm]	DVI-I
[drm]	HPD4
[drm]	DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c
[drm]	Encoders:
[drm]	  CRT1: INTERNAL_KLDSCP_DAC1
[drm]	  DFP2: INTERNAL_UNIPHY2
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0142000
[drm] vram apper at 0xD0000000
[drm] size 8294400
[drm] fb depth is 24
[drm]	 pitch is 7680
checking generic (d0000000 1000000) vs hw (d0000000 20000000)
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
Console: switching to colour dummy device 80x25
Console: switching to colour frame buffer device 240x67
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.6.0 20080528 for 0000:07:00.0 on minor 0

The only thing out of the ordinary I could spot is the "failed to
evaluate ATIF" message, but apparently it is only a debug message, so I
doubt it is related (but it would certainly be nice to solve that
problem too.)

Let me know if I can provide more information, or help in any way with
debugging this issue.

Thanks,
-- 
Jean Delvare

Re: Error message on RV710: reserve failed for wait

[Jean Delvare]

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

For completeness, I also saw these error messages when running kernels
2.6.34.4+ and 2.6.35.5+, so this isn't something new in 2.6.36.

-- 
Jean Delvare

Re: Error message on RV710: reserve failed for wait

[Jean Delvare]

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

Re: Error message on RV710: reserve failed for wait

[Jerome Glisse]

----- "Jean Delvare" <khali@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