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.
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 drm_agp_alloc. 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. :(
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?
Same failure mode (except ENODEV instead of EBUSY) with a 2.6.12-1.1380_FC3 kernel.
Ian, I've taken a look at this and I can see why things are failing. Catch me later on IRC.
Is there combination of DRI kernel module and X server known to work properly with this chipset? Alex
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.
Created attachment 3713 [details] Full xserver log
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.
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.
This patch works for me as well.
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.
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.