From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 06:51:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537AA106564A for ; Sat, 26 Jun 2010 06:51:01 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0A298FC0A for ; Sat, 26 Jun 2010 06:50:58 +0000 (UTC) Received: by fxm13 with SMTP id 13so306850fxm.13 for ; Fri, 25 Jun 2010 23:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=wTjFrgqQkWkfPuLhe4gt/11ghJiY+HJ2dqY/BQ6+hZY=; b=lvwn9lPrIx7DUY7C6oo40hn35O4K9Y3OWa57m1/2WGD5v6zzL3TiPN/pRUYPZ55Ubr 8StfNBw9ZTmp0czYkqkG8P4WTGumeHTdi2LrZuAwYhLmAq07dsbJFB3z65Ygt1zJDyRX LrCCviQauU9eSDXAdCgZ+5mCrGmDvCL1Off4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=EbjOwCCTfDQKmGC/13z6P7cUDPITHjwVZAZLPQNvA/zEq9vD+XoFOm7EvRFcdLsac/ S6mSmW8FFqX5bVmD445iU5D8dyJZDw//KlAtryOd1lFZ8R7NF5Ja8FE7tCoJyPgt6ZEj tl8QS2t/Ifj8fnO7XVsTG2atWYUg+MrTuScuU= Received: by 10.223.50.68 with SMTP id y4mr1384157faf.51.1277535057772; Fri, 25 Jun 2010 23:50:57 -0700 (PDT) Received: from viper.internal.network (dsl78-143-224-50.in-addr.fast.co.uk [78.143.224.50]) by mx.google.com with ESMTPS id a3sm39732883fak.40.2010.06.25.23.50.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Jun 2010 23:50:57 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 4C1A64AC0A; Sat, 26 Jun 2010 06:50:56 +0000 (UTC) Date: Sat, 26 Jun 2010 06:50:56 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20100626065056.GA897@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 32 bit DRI on amd64 - possible bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 06:51:01 -0000 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 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,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