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