Bug 4908 - [Intel / i830] drmAddMap(backbuffer) failed
Summary: [Intel / i830] drmAddMap(backbuffer) failed
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/other (show other bugs)
Version: DRI git
Hardware: x86 (IA32) All
: high normal
Assignee: Alan Hourihane
QA Contact:
Depends on:
Reported: 2005-10-27 09:04 UTC by Ian Romanick
Modified: 2006-01-30 01:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Acquire AGP and allocate AGP memory (2.97 KB, patch)
2005-10-27 16:05 UTC, Ian Romanick
no flags Details | Splinter Review
Acquire AGP and allocate AGP memory, take 2 (2.95 KB, patch)
2005-10-27 21:33 UTC, Ian Romanick
no flags Details | Splinter Review
DRM patch (1.42 KB, patch)
2005-11-04 03:43 UTC, Alan Hourihane
no flags Details | Splinter Review
Full xserver log (70.55 KB, text/plain)
2005-11-06 00:15 UTC, Alex Baretta
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Romanick 2005-10-27 09:04:53 UTC
Using current DRM CVS with current X.org CVS, direct rendering is disabled on i830
hardware (PCI ID 8086:3577).  The telltale error in the Xorg log is:

(EE) I810(0): [drm] drmAddMap(backbuffer) failed. Disabling DRI

I suspect that this is related to the root problem of bug #4797.
Comment 1 Ian Romanick 2005-10-27 16:05:26 UTC
Created attachment 3645 [details] [review]
Acquire AGP and allocate AGP memory

This patch *really* should fix the bug.  The drmAddMap call fails because (in
the kernel) dev->agp->memory is NULL.  This field is set on the first call to

With this patch (and the '#if 1' converted to '#if 0'), the drmAgpAlloc call
fails with EINVAL.  This happens when dev->agp->acquired is FALSE.  However,
with the patch as-is, the drmAgpAcquire call fails with EBUSY.	This happens
when dev->agp->acquired is TRUE.  How can dev->agp->acquired be both TRUE and
FALSE at the same time?

I really enjoy that I've wasted an entire work day on this bug. :(
Comment 2 Ian Romanick 2005-10-27 21:33:22 UTC
Created attachment 3648 [details] [review]
Acquire AGP and allocate AGP memory, take 2

This patch fixes a couple dumb changes that I made in the previous patch
/after/ the last time I compiled it.  Duh.

In any case, I've also made another discovery about this bug.  I'm running on a
2.6.10 kernel (2.6.10-1.741_FC3 to be exact).  It isn't drm_agp_acquire that's
generating EBUSY.  It's the call to agp_backend_acquire that's generating
EBUSY.	Any ideas why agp_backend_acquire might return EBUSY?
Comment 3 Ian Romanick 2005-10-27 22:19:16 UTC
Same failure mode (except ENODEV instead of EBUSY) with a 2.6.12-1.1380_FC3 kernel.
Comment 4 Alan Hourihane 2005-10-28 01:17:26 UTC
Ian, I've taken a look at this and I can see why things are failing.

Catch me later on IRC.
Comment 5 Alex Baretta 2005-11-03 23:15:32 UTC
Is there combination of DRI kernel module and X server known to work properly
with this chipset?

Comment 6 Alan Hourihane 2005-11-04 03:43:15 UTC
Created attachment 3699 [details] [review]
DRM patch

The extra security checks that now exist in the DRM, are under the assumption
that the DRM is THE arbiter for AGP space, which is not always the case as in
the i830 driver. In this case the i830 driver manages AGP space itself,
and passes offsets back down.

The patch skips over the additional security checks for a quick fix.

Ultimately, the next thing to do is wrap the agp ioctls in the Xserver to call
libdrm's AGP wrappers when DRI is enabled, and then fallback to the
Xserver's own routines when DRI is not enabled. But we can do that after the
6.9/7.0 release.

I've not tried this patch yet, so if someone could that'd be great.
Comment 7 Alex Baretta 2005-11-06 00:15:51 UTC
Created attachment 3713 [details]
Full xserver log
Comment 8 Alex Baretta 2005-11-06 00:17:24 UTC
Comment on attachment 3713 [details]
Full xserver log

(In reply to comment #6)
> The patch skips over the additional security checks for a quick fix.
> ...
> I've not tried this patch yet, so if someone could that'd be great.

With this patch, something happens. Whether it's good, I don't know. On my
machine (IBM ThinkPad R51 with intel 82852/855GM integrated graphics device)
Xorg.0.log seems to show that direct rendering is enabled and not disabled
later on as occurred without the patch.

> (II) I810(0): [DRI] installation complete
> (II) I810(0): direct rendering: Enabled

Yet, glxinfo provides the following two alternative error descriptions,
depending on the user executing the command.

lex@alex:~$ glxinfo
name of display: :0.0
libGL error: open DRM failed (Operation not permitted)
libGL error: reverting to (slow) indirect rendering
display: :0  screen: 0

root@alex:~# glxinfo
name of display: :0.0
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering

I would guess that the first error is due to a device special file
ownership/permission problem, so that it should not be a problem. The second
error seems more meaningful.
Comment 9 Alan Hourihane 2005-11-07 05:15:42 UTC
The first just sounds like permissions in your config file are not setup
correctly, and the second sounds like you need to update your libGL library.
Comment 10 Bryan Stine 2005-11-07 21:29:19 UTC
This patch works for me as well. 
Comment 11 Daniel Kasak 2005-12-20 09:15:54 UTC
The patch doesn't seem to work for me.
I applied it against Gentoo's cvs snapshot from 2005-10-28. It appeared to apply
and compile cleanly, but I still get the same error.

It is of course possible that I don't know what I'm doing. Here's what I did,
just in case ...

Unpacked the source for x11-drm-20051028.ebuild
cd'd into drm/linux-core
Applied patch with 'patch -p1 < /path/to/patch'
Continued with building and installing

I still get [Intel / i830] drmAddMap(backbuffer) failed in my log. I will revert
to the kernel drm.
Comment 12 Alan Hourihane 2006-01-30 20:26:31 UTC
Fixed. Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.