32 bit DRI on amd64 - possible bug?

xorquewasp at googlemail.com xorquewasp at googlemail.com
Sat Jun 26 06:51:01 UTC 2010


Hi.

I've had two people tell me that this is supposed to be working
these days (8.0-RELEASE-p2) but I'm not having much luck.

I have a 32 bit chroot, built with "make buildworld TARGET=i386"
and have built a pile of ports in that jail (i386 libGL, i386
dri, etc, etc).

I've tried running the chroot as both a jail and an ordinary
chroot and in both cases, any program that tries to use DRI
behaves erratically and usually (but not always) segfaults
immediately:

i386-jail$ LIBGL_DEBUG=verbose glxinfo
name of display: 10.1.3.1:0.0
libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
DRM_IOCTL_VERSION: Bad address
Segmentation fault: 11

i386-jail$ LIBGL_DEBUG=verbose glxinfo
name of display: 10.1.3.1:0.0
libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
Segmentation fault: 11

i386-jail$ LIBGL_DEBUG=verbose glxinfo
name of display: 10.1.3.1:0.0
libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: Searching for BusID pci:0000:06:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports (null)
drmOpenDevice: node name is /dev/dri/card1
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card2
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card3
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card4
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card5
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card6
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card7
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card8
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card9
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card10
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card11
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card12
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card13
drmOpenByBusid: drmOpenMinor returns -1003
drmOpenDevice: node name is /dev/dri/card14
drmOpenByBusid: drmOpenMinor returns -1003
libGL error: drmOpenOnce failed (Operation not permitted)
libGL error: reverting to software direct rendering
libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so
display: 10.1.3.1:0  screen: 0
direct rendering: Yes
<output snipped>

Note the lack of a segfault in the third invocation. The
glxinfo program runs to completion about one in every
six invocations. Programs such as glxdemo sometimes manage
to open a window and process a few events before crashing
(it's pretty much over before anything's visible onscreen -
less than half a second):

i386-chroot$ glxdemo
Segmentation fault: 11 (core dumped)
i386-chroot$ glxdemo
Segmentation fault: 11 (core dumped)
i386-chroot$ glxdemo
Resize event
Resize event
Redraw event
Segmentation fault: 11 (core dumped)

It doesn't work outside of the chroot either (just using
LD_32_LIBRARY_PATH to allow the binaries to find their
libraries):

$ LD_32_LIBRARY_PATH=/jail/i386/usr/local/lib \
  LIBGL_DEBUG=verbose \
  LIBGL_DRIVERS_PATH=/jail/i386/usr/local/lib/dri \
  /jail/i386/usr/local/bin/glxinfo 2>&1
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
libGL: OpenDriver: trying /jail/wine/usr/local/lib/dri/r300_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
Segmentation fault (core dumped)

A ktrace shows nothing particular interesting in any case.
Sometimes an ioctl() will fail with EFAULT but usually,
things just crash:

 75860 initial thread RET   stat 0
 75860 initial thread CALL  open(0xffffd0f4,O_RDWR,<unused>0)
 75860 initial thread NAMI  "/dev/dri/card0"
 75860 initial thread RET   open 6
 75860 initial thread CALL  write(0x2,0xffffcaf0,0x26)
 75860 initial thread GIO   fd 2 wrote 38 bytes
       "drmOpenDevice: open result is 6, (OK)
       "
 75860 initial thread RET   write 38/0x26
 75860 initial thread CALL  ioctl(0x6,0xc0246400 ,0x28414100)
 75860 initial thread RET   ioctl 0
 75860 initial thread CALL  ioctl(0x6,0xc0246400 ,0x28414100)
 75860 initial thread RET   ioctl 0
 75860 initial thread PSIG  SIGSEGV SIG_DFL
 75860 initial thread NAMI  "glxinfo.core"

The "operation not permitted" error is confusing too
as permissions on /dev/dri/card0 are fine:

i386$ id
uid=11001(m0) gid=11001(m0) groups=11001(m0),11003(devel),11012(usb),11013(video)
i386$ ls -alF /dev/dri/card0
crw-rw----  1 root  video    0,  37 May 26 10:29 /dev/dri/card0

Needless to say, DRI works flawlessly on the host. The package
versions on the host and in the chroot match.

Is this a bug? I'm mystified as I seem to be the only person
having this problem.

host: FreeBSD 8.0-RELEASE-p2 amd64
jail: FreeBSD 8.0-RELEASE-p2 i386

packages:
dri-7.4.4,2
xf86-video-ati-6.12.4_1
libGL-7.4.4

Device is an ATI Radeon x1950.

Any help would be seriously appreciated!

Regards,
xw


More information about the freebsd-hackers mailing list