latest drm patches

Robert Noland rnoland at FreeBSD.org
Thu Oct 2 21:30:13 UTC 2008


On Thu, 2008-10-02 at 23:16 +0200, Paul B. Mahol wrote:
> On 10/2/08, Robert Noland <rnoland at freebsd.org> wrote:
> > On Thu, 2008-10-02 at 22:38 +0200, Paul B. Mahol wrote:
> >> On 10/2/08, Robert Noland <rnoland at freebsd.org> wrote:
> >> > I have made new patch sets for both -CURRENT and -STABLE.  They are
> >> > located at:
> >> >
> >> > http://people.freebsd.org/~rnoland/drm-update-7-100108.patch.bz2
> >> > http://people.freebsd.org/~rnoland/drm-update-8-100108.patch.bz2
> >> >
> >> > Note that if your are using RELENG_7, you will need to be very current.
> >> > i.e. on or after 2008-09-29 16:20:13 -0400.  CURRENT should be at least
> >> > 2008-09-20 15:56:02 -0400.
> >> >
> >> > This is a re-sync to git master, which seems to address many of the
> >> > issues with the intel chipsets < 965.  I'm still not certain exactly
> >> > which change fixes them unfortunately.  This update contains a lot of
> >> > code cleanup and is post gem merge (no, we don't have gem support).  It
> >> > should prove much easier to read the code now.  A lot of thanks goes to
> >> > vehemens for that work.  I have adapted the code to use cdevpriv for
> >> > tracking per open file data, which is the reason that you need really
> >> > current bits to use this patch.  That alleviates the old ugly hack that
> >> > we used to try and accomplish the task and helped to clean up the open /
> >> > close behavior a good bit.  This also replaces the hack that was put in
> >> > place a year or so ago to prevent radeons from locking up with AIGLX
> >> > enabled.  I have had a couple of radeon testers report that it still
> >> > works as expected, though I no longer have radeon hardware to test with
> >> > myself.  Other various fixes from the linux crew and Intel, many of
> >> > which are muddled in with the gem merge.
> >> >
> >> > I am planning to push this into CURRENT pretty soon, possibly even
> >> > sometime tomorrow once I have a chance to discuss with a few others.
> >>
> >> Wow, something is broken again (glxgears doenst work again). I checked
> >> twice (with two versions of agp)
> >
> > Are you sure that your -CURRENT meets the requirements that I stated?
> 
> FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #6: Sun Sep 28
> 11:46:55 CEST 2008

Hrm, ok... You say that git from yesterday is working.  I pushed one of
the 2 differences last night, so let's try this.

cd into your git directory
git pull
cd bsd-core && make clean && make all install

Hopefully that will tell us which one has the issue.

robert.

> > There are only two commits difference between what is in git and that
> > patch.  One of them requires having the new bits, though it may not
> > produce coherent errors if it isn't present.
> >
> >> Only new is that this error is being displayed:
> >>
> >> error: [drm:pid1716:i915_mem_init_heap] *ERROR* called with no
> >> initialization
> >>
> >>
> >>
> >> I checked modules from git(again), and they still works, new (actually
> >> old) lor is still there:
> >>
> >> info: [drm] Initialized i915 1.6.0 20080730
> >> drm0: [ITHREAD]
> >> lock order reversal: (sleepable after non-sleepable)
> >>  1st 0xc3ddc060 drmdev (drmdev) @
> >> /usr/home/pbanicev/src/freebsd/gitdrm/drm/bsd-core/drm/../drm_drv.c:713
> >>  2nd 0xc41409e4 user map (user map) @ /usr/src/sys/vm/vm_glue.c:179
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper(c06d0902,e658ba48,c050a705,4,c06cc438,...) at
> >> db_trace_self_wrapper+0x26
> >> kdb_backtrace(4,c06cc438,c06e98c2,c3c52728,e658baa4,...) at
> >> kdb_backtrace+0x29
> >> _witness_debugger(c06d31e8,c41409e4,c06e9dba,c3c52728,c06e98c2,...) at
> >> _witness_debugger+0x25
> >> witness_checkorder(c41409e4,9,c06e98c2,b3,0,...) at
> >> witness_checkorder+0x810
> >> _sx_xlock(c41409e4,0,c06e98c2,b3,e658bb08,...) at _sx_xlock+0x85
> >> _vm_map_lock_read(c41409a0,c06e98c2,b3,c050a964,c3fd9280,...) at
> >> _vm_map_lock_read+0x4d
> >> useracc(8114090,8,1,c440a895,c3c56ea8,...) at useracc+0x65
> >> i915_cmdbuffer(c3ddc000,c3fd9280,c415cb00,2c9,0,...) at
> >> i915_cmdbuffer+0x384
> >> drm_ioctl(c4165000,8018644b,c3fd9280,3,c4158d20,...) at drm_ioctl+0x32b
> >> giant_ioctl(c4165000,8018644b,c3fd9280,3,c4158d20,...) at giant_ioctl+0x6e
> >> devfs_ioctl_f(c4012658,8018644b,c3fd9280,c4164800,c4158d20,...) at
> >> devfs_ioctl_f+0xf8
> >> kern_ioctl(c4158d20,4,8018644b,c3fd9280,204140,...) at kern_ioctl+0x1dd
> >> ioctl(c4158d20,e658bcf8,c,16,c0702c70,...) at ioctl+0x134
> >> syscall(e658bd38) at syscall+0x283
> >> Xint0x80_syscall() at Xint0x80_syscall+0x20
> >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x283c9a43, esp =
> >> 0xbfbfdb2c, ebp = 0xbfbfdb48 ---
> >
> > Hrm, I'm not seeing this either... I'll try and reproduce...
> 
> There is one more (I belive this one is also old one)
> 
> lock order reversal: (Giant after non-sleepable)
>  1st 0xc3ddc060 drmdev (drmdev) @
> /usr/home/pbanicev/src/freebsd/gitdrm/drm/bsd-core/drm/../drm_drv.c:713
>  2nd 0xc0743c70 Giant (Giant) @ /usr/src/sys/kern/kern_sx.c:580
> KDB: stack backtrace:
> db_trace_self_wrapper(c06d0902,e64cd9e4,c050a705,4,c06cc438,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(4,c06cc438,c06ce089,c3c511a0,e64cda40,...) at kdb_backtrace+0x29
> _witness_debugger(c06d31e8,c0743c70,c06c8802,c3c511a0,c06ce089,...) at
> _witness_debugger+0x25
> witness_checkorder(c0743c70,9,c06ce089,244,0,...) at witness_checkorder+0x810
> _mtx_lock_flags(c0743c70,0,c06ce089,244,0,...) at _mtx_lock_flags+0xc4
> _sx_xlock_hard(c4028744,c4024d20,0,c06e98c2,b3,...) at _sx_xlock_hard+0x225
> _sx_xlock(c4028744,0,c06e98c2,b3,e64cdb08,...) at _sx_xlock+0xc0
> _vm_map_lock_read(c4028700,c06e98c2,b3,c050a964,c4930440,...) at
> _vm_map_lock_read+0x4d
> useracc(8a32130,8,1,c440a895,c3c56ea8,...) at useracc+0x65
> i915_cmdbuffer(c3ddc000,c4930440,c4775880,2c9,0,...) at i915_cmdbuffer+0x384
> drm_ioctl(c4165000,8018644b,c4930440,3,c4024d20,...) at drm_ioctl+0x32b
> giant_ioctl(c4165000,8018644b,c4930440,3,c4024d20,...) at giant_ioctl+0x6e
> devfs_ioctl_f(c401d230,8018644b,c4930440,c477e200,c4024d20,...) at
> devfs_ioctl_f+0xf8
> kern_ioctl(c4024d20,5,8018644b,c4930440,504140,...) at kern_ioctl+0x1dd
> ioctl(c4024d20,e64cdcf8,c,c06d40c2,c0702c70,...) at ioctl+0x134
> syscall(e64cdd38) at syscall+0x283
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28676a43, esp =
> 0xbfbfe3d4, ebp = 0xbfbfe3f0 ---
> 
> >
> > robert.
> >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20081002/71380f7e/attachment.pgp


More information about the freebsd-x11 mailing list