No 3D acceleration on Intel Mobile 4 Series Graphics Card, Fedora 12

[kjrdel]

I'm a Fedora 12 user on an HP Pavilion dv4 laptop. I'm currently using kernel 2.6.32.11-99.fc12.x86_64, graphics driver xorg-x11-drv-intel-2.9.1-1.fc12.x86_64, and mesa 7.7-4. My graphics card is an Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07).

I've been having some problems getting my 3D acceleration to work. Although it worked correctly in Fedora 11, I have not been able to get it to work yet in Fedora 12. The output of glxinfo shows:

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
................................................
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.7-devel

Running glxinfo with LIBGL_DEBUG=verbose shows:

libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL error: dlopen /usr/lib64/dri/i965_dri.so failed (/usr/lib64/dri/i965_dri.so: undefined symbol: drm_intel_bo_busy)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so

I found a similar message here: http://groups.google.com/group/linux...79407136c0068a

However, I'm not sure if this is the same problem I have. What does the drm_intel_bo_busy message mean?

I've had this problem ever since I upgraded from Fedora 11 to Fedora 12 in Dec. 2009.

Thanks for any insight and/or suggestions.

Ken

---------- Post added at 10:35 PM CDT ---------- Previous post was at 10:20 PM CDT ----------

To verify some of the information already given in the previous post:

> Output of command: glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Software Rasterizer

> Output of command: rpm -qa | grep -i -e libdrm -e mesa -e xorg-x11-drv-intel -e xorg-x11-server | sort
libdrm-2.4.18-2.fc12.i686
libdrm-2.4.18-2.fc12.x86_64
libdrm-devel-2.4.18-2.fc12.x86_64
mesa-dri-drivers-7.6-0.13.fc12.i686
mesa-dri-drivers-7.6-0.13.fc12.x86_64
mesa-dri-drivers-7.7-4.fc12.i686
mesa-dri-drivers-7.7-4.fc12.x86_64
mesa-dri-drivers-experimental-7.7-4.fc12.x86_64
mesa-libGL-7.7-4.fc12.i686
mesa-libGL-7.7-4.fc12.x86_64
mesa-libGL-devel-7.7-4.fc12.x86_64
mesa-libGLU-7.7-4.fc12.i686
mesa-libGLU-7.7-4.fc12.x86_64
mesa-libGLU-devel-7.7-4.fc12.x86_64
mesa-libGLw-6.5.1-8.fc12.x86_64
xorg-x11-drv-intel-2.9.1-1.fc12.x86_64
xorg-x11-server-common-1.7.6-1.fc12.x86_64
xorg-x11-server-devel-1.7.6-1.fc12.x86_64
xorg-x11-server-utils-7.4-13.fc12.x86_64
xorg-x11-server-Xorg-1.7.6-1.fc12.x86_64

Note: I use mesa-dri-drivers-7.6-0.13 because they work better with rendering 3D graphs in a computer algebra system (Mathematica) that I use for school. Using mesa-dri-drivers-7.7-4 does not fix the 3D hardware acceleration problem. In fact, I've been through several versions of both mesa and libdrm since my update to F12. None of them have fixed this problem.

> Output of command: grep -e EE -e WW /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
(WW) Disabling Keyboard0
(II) Loading extension MIT-SCREEN-SAVER
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x61110 (PORT_HOTPLUG_EN) changed from 0x00000120 to 0x20000120
(WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x11001000 to 0xa2004000
(WW) intel(0): Option "AccelMethod" is not used

The "AccelMethod" Warning: I forgot that the "AccelMethod" option is no longer used in xorg.conf. I forgot to remove it.

Output of command: su -c 'lspci | grep VGA'
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

Hopefully this extra information is helpful.

[Hlingler]

The output of 'glxinfo' is odd, and does not seem to jive with output of Xorg.0.log: I would expect to see i965_dri.so referenced in the Xorg log errors/warnings, but it's not. Is a kmod loaded? Post:
su
lsmod | grep -e intel -e i9 -e i8

You have multiple conflicting version of mesa-dri-drivers installed; this cannot be good: such installation must have required force, and one or the other (whichever was installed last) must have over-written the files of the other. In addition: the 32-bit RPMs may be unnecessary - can they be removed without dragging out or disabling other stuff? Try: remove one set of mesa-dri-drivers, and re-install the other (to make sure no damage). Try: remove 32-bit (i686) versions, if possible. However, they should (theoretically) not make any difference one way or the other, but get them out of the way, if possible.

Package mesa-dri-drivers-experimental is totally extraneous to your hardware (it contains only an experimental ATI Radeon driver, which you do not need) - suggest that you remove it (trying to clear away cruft, and narrow down problem).

Overall, the error shown appears to be either a programming error (bug), or the result of a mis-match between the various DRM, Mesa, and/or Xorg packages.

If none of the above help, attach (or pastebin) the entire Xorg.0.log.

V

P.S. The referenced Debian bug may be related, but offers no solution.

What does the drm_intel_bo_busy message mean?

I have no idea.

P.P.S. Don't worry about the 'AccelMethod' thing - it's ignored, as you can see.

EDIT: Have you, at any time in the past, ever installed any 3rd-party video drivers, such as NVidia and/or ATI-FGLRX/Catalyst ?

[kjrdel]

Output of lsmod | grep -e intel -e i9 -e i8:

snd_hda_codec_intelhdmi    13029  1 
snd_hda_intel          23888  2 
snd_hda_codec          71956  3 snd_hda_codec_intelhdmi,snd_hda_codec_idt,snd_hda_intel
snd_pcm                78247  3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd                    62376  17 snd_hda_codec_intelhdmi,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
snd_page_alloc          7389  2 snd_hda_intel,snd_pcm
i2c_i801               10361  0 
i915                  282542  1 
drm_kms_helper         24568  1 i915
drm                   171094  3 i915,drm_kms_helper
i2c_algo_bit            5005  1 i915
i2c_core               26876  6 videodev,i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit
video                  20118  1 i915

In regards to 3rd-party video drivers, I've never used/installed them with my Linux partition. The only proprietary graphics drivers on my machine reside on the Windows partition of my hard drive.

The reason for the conflicting dri drivers is that the older one allows 3D rendering with my computer algebra system (Mathematica). The new version (7.7-4) crashes my X-server when trying to render 3D objects in Mathematica. Hence, I keep the old dri drivers, but update all of the other OpenGL-related libraries. This does not affect the problem. I already checked

One thing that did puzzle me was when I tried to remove the mesa-dri-drivers (I planned to remove and reinstall), PackageManger told me that one of the other packages I needed to remove was again mesa-dri-drivers.

Could the dri-drivers somehow be installed twice? This would sort of coincide with Debian bug.

Is there a way to check the git-tree to see if mesa-dri-drivers is installed twice?

Could I remove the dri-drivers packages without removing a bunch of other packages as well (PackageManager wanted to uninstall a whole bunch of other packages)?

[Hlingler]

Could I remove the dri-drivers packages without removing a bunch of other packages as well (PackageManager wanted to uninstall a whole bunch of other packages)?

Try (at your own risk):
su
rpm -ev --nodeps mesa-dri-drivers-7.7-4.fc12.i686 mesa-dri-drivers-7.7-4.fc12.x86_64 mesa-dri-drivers-experimental

But now I see another puzzling thing: why is glxinfo "trying /usr/lib64/dri/i965_dri.so" when clearly the driver in use is i915 (with matching kmod) ??? It should be looking for i915_dri.so. Post:
ldd `which glxinfo`

It is most curious that you report that "the older one allows 3D rendering with my computer algebra system (Mathematica)", but "new version (7.7-4) crashes my X-server when trying to render 3D objects in Mathematica.". Possible regression?

Could the dri-drivers somehow be installed twice? This would sort of coincide with Debian bug.

They *are* installed twice, as your RPM list clearly shows. See above.

Is there a way to check the git-tree to see if mesa-dri-drivers is installed twice?

Huh ???

V

P.S. Re-install the remaining mesa-dri-drivers packages after purging the duplicates (to ensure no damage).

[kjrdel]

Output of ldd `which glxinfo`:

linux-vdso.so.1 => (0x00007fff0579a000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000003316600000)
libm.so.6 => /lib64/libm.so.6 (0x000000330c200000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x000000330f200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000330ca00000)
libc.so.6 => /lib64/libc.so.6 (0x000000330be00000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x000000330fa00000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003318600000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x0000003312e00000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x0000003311a00000)
libdrm.so.2 => /lib/libdrm.so.2 (0x0000003318a00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000330c600000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x000000330ea00000)
/lib64/ld-linux-x86-64.so.2 (0x000000330ba00000)
librt.so.1 => /lib64/librt.so.1 (0x000000330d200000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000330ee00000)

I removed all of the mesa-dri-drivers (including 32-bit) and re-installed dri-drivers 7.7-4 (x86_64).

Now LIBGL_DEBUG=verbose glxinfo gives:

libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL error: dlopen /usr/lib64/dri/i965_dri.so failed (/usr/lib64/dri/i965_dri.so: undefined symbol: drm_intel_bo_references)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so

So now, the undefined symbol is drm_intel_bo_references instead of drm_intel_bo_busy. Interesting...

[Hlingler]

Probable regression - file a bug report, reference this thread and the Debian bug. If you feel adventurous:
su
yum --enablerepo=updates-testing update libdrm* mesa* xorg*

then re-start X.

Still damn odd that glxinfo would somehow invoke i965_dri.so when driver clearly seems to be i915_dri.so. Most puzzling ... .

V

EDIT: This doesn't look right either - notice that all others are .../lib64/... :

libdrm.so.2 => /lib/libdrm.so.2 (0x0000003318a00000)

Try: remove 32-bit (i686) libdrm.

[kjrdel]

Wow! That was the problem.

It was linking to the wrong libdrm.

Removed the 32-bit package and now libdrm points to /usr/lib64/libdrm.so.2

Output of LIBGL_DEBUG=verbose glxinfo now gives:

libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
...
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20090712 2009Q2 RC3


Thanks so much!

Ken