drm/dri update

Johannes Hofmann Johannes.Hofmann at gmx.de
Mon Jan 7 14:31:56 PST 2008


Hey,

I got it working with

diff --git a/bsd-core/drm_dma.c b/bsd-core/drm_dma.c
index 71ef845..cdfe124 100644
--- a/bsd-core/drm_dma.c
+++ b/bsd-core/drm_dma.c
@@ -80,9 +80,10 @@ void drm_dma_takedown(drm_device_t *dev)
                        free(dma->bufs[i].buflist, M_DRM);
                }
        }
-
+#if 0
        free(dma->buflist, M_DRM);
        free(dma->pagelist, M_DRM);
+#endif
        free(dev->dma, M_DRM);
        dev->dma = NULL;
        DRM_SPINUNINIT(&dev->dma_lock);


glxinfo reports:

hofmann at blob:~ >glxinfo 
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2

and 

hofmann at blob:~ >glxgears 
8102 frames in 5.0 seconds = 1620.076 FPS
8171 frames in 5.0 seconds = 1633.914 FPS


This is great! Thanks a lot Simon!

 Johannes


Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
> Steve O'Hara-Smith <steve at sohara.org> wrote:
>> On Mon, 07 Jan 2008 02:53:44 +0100
>> "Simon 'corecode' Schubert" <corecode at fs.ei.tum.de> wrote:
>> 
>>> You'll need to install a MesaLib that supports dri.  I don't know how 
>>> you could do this with the MesaLib from pkgsrc.  I installed MesaLib-dri 
>>> from pkgsrc-wip.  Be sure to read the README.
>> 
>>        It was going great right up to this point where I get this trying
>> to compile MesaLib-dri ...
>> 
>> mklib: ERROR: Don't know how to make a static/shared library
>> for DragonFly mklib: Please add necessary commands to mklib
>> script.
>> 
>>        ... I hacked the mklib script in place and changed 'FreeBSD' to
>> 'FreeBSD' | 'DragonFly' in the obvious place.
> 
> Same here on a T42p thinkpad.
> 
>> 
>>        Unfortunately once all was done starting the X server with dri
>> enabled simply crashes the system (stop dead and reboot with no messages).
>> The last thing in the Xorg.0.log is:
>> 
>> drmOpenDevice: node name is /dev/dri/card0
>> drmOpenDevice: open result is 8, (OK)
> 
> here it's
> 
> (II) RADEON(0): initializing int10
> (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear
> (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear
> (II) RADEON(0): Primary V_BIOS segment is: 0xc000
> (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear
> (--) RADEON(0): Chipset: "ATI FireGL Mobility T2 (M10) NT (AGP)" (ChipID = 0x4e54)
> (--) RADEON(0): Linear framebuffer at 0xe0000000
> (II) RADEON(0): AGP card detected
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 7, (OK)
> 
>> 
>>        The only good news in all this is that I half expected this to
>> happen. This combination of a Radeon 9200SE and an ASUS A8V has always
>> crashed under dri in much this way, although I had been hoping that an up
>> to date drm and agp set might fix it :)
>> 
>>        Any suggestions as to how I might go about tracking this little gem
>> down ?
> 
> 
> It then panics with 
> 
> #0  dumpsys () at thread.h:83
> #1  0xc02a2815 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:375
> #2  0xc02a2f9e in panic (fmt=0xc051d67a "trying to free NULL pointer")
>    at /usr/src/sys/kern/kern_shutdown.c:800
> #3  0xc02a0bbf in kfree (ptr=0x0, type=0xda8a1d40)
>    at /usr/src/sys/kern/kern_slaballoc.c:813
> #4  0xda89b42a in drm_dma_takedown ()
> #5  0xda89bf00 in drm_lastclose ()
> #6  0xda89ca5d in drm_close ()
> #7  0xc028b976 in dev_dclose (dev=0x0, fflag=0, devtype=0)
>    at /usr/src/sys/kern/kern_device.c:124
> #8  0xc030140a in spec_close (ap=0xdbcabba8) at /usr/src/sys/vfs/specfs/spec_vnops.c:740
> #9  0xc0413291 in ufsspec_close (ap=0xdbcabba8) at /usr/src/sys/vfs/ufs/ufs_vnops.c:1947
> #10 0xc04139b7 in ufs_vnoperatespec (ap=0x0) at /usr/src/sys/vfs/ufs/ufs_vnops.c:2462
> #11 0xc02fbaa2 in vop_close (ops=0x0, vp=0x0, fflag=0)
>    at /usr/src/sys/kern/vfs_vopops.c:257
> #12 0xc02faafb in vn_close (vp=0xdb13e728, flags=0) at /usr/src/sys/kern/vfs_vnops.c:417
> #13 0xc02fb94f in vn_closefile (fp=0x0) at /usr/src/sys/kern/vfs_vnops.c:1103
> #14 0xc028f5da in fdrop (fp=0xda8fa8e0) at file2.h:120
> #15 0xc028f4e0 in closef (fp=0xda8fa8e0, td=0x0) at /usr/src/sys/kern/kern_descrip.c:2079
> #16 0xc028d8b5 in kern_close (fd=7) at /usr/src/sys/kern/kern_descrip.c:833
> #17 0xc028d7f5 in sys_close (uap=0x0) at /usr/src/sys/kern/kern_descrip.c:788
> #18 0xc04ce8c7 in syscall2 (frame=0xdbcabd40)
>    at /usr/src/sys/platform/pc32/i386/trap.c:1339
> #19 0xc04bc735 in Xint0x80_syscall () at /usr/src/sys/platform/pc32/i386/exception.s:872
> #20 0x28330c48 in ?? ()
> #21 0xbfbff57c in ?? ()
> #22 0x0000002f in ?? ()
> #23 0x00000000 in ?? ()
> #24 0x00000000 in ?? ()
> #25 0x00000000 in ?? ()
> #26 0x00000000 in ?? ()
> #27 0x44929000 in ?? ()
> #28 0xdaa1ba00 in ?? ()
> #29 0xc06048d4 in softclock_pcpu_ary ()
> #30 0xdbcab980 in ?? ()
> 
>  Johannes





More information about the Users mailing list