Date: Fri, 12 Nov 2010 12:54:19 +0200 From: Andriy Gapon <avg@freebsd.org> To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held Message-ID: <4CDD1CDB.6020409@freebsd.org> In-Reply-To: <4CD7E401.1010206@freebsd.org> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 08/11/2010 13:50 Andriy Gapon said the following: > on 05/11/2010 09:27 Andriy Gapon said the following: >> >> I use FreeSBD head and KDE 4 with all the bells and whistles enabled. >> Apparently recent KDE update has enabled even more of them, because I started to >> have panics with a kernel that has INVARIANTS and WITNESS enabled. > > I tried to solve the problem by changing drmdev from mutex to sx: > http://people.freebsd.org/~avg/drm-sx.diff Quite surprisingly for me, it seems that this patch has solved the following problem for me: http://thread.gmane.org/gmane.os.freebsd.devel.x11/9849 Or maybe this is just a coincidence. Could there be a logical explanation for this? > The things have improved, I am not getting the panic anymore. > Instead I have this LOR now: > lock order reversal: > 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 > 2nd 0xffffff0072a87200 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff803a7a6a = kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd40c = _witness_debugger+0x2c > witness_checkorder() at 0xffffffff803be879 = witness_checkorder+0x959 > _sx_slock() at 0xffffffff80378af8 = _sx_slock+0x88 > _vm_map_lock_read() at 0xffffffff805109e6 = _vm_map_lock_read+0x36 > vm_map_lookup() at 0xffffffff805127b4 = vm_map_lookup+0x54 > vm_fault() at 0xffffffff805097f9 = vm_fault+0xf9 > trap_pfault() at 0xffffffff80545d0f = trap_pfault+0x11f > trap() at 0xffffffff80546597 = trap+0x657 > calltrap() at 0xffffffff805305c8 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8054405d, rsp = 0xffffff81241b47f0, rbp = > 0xffffff81241b4870 --- > copyin() at 0xffffffff8054405d = copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fbd7 = radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa38 = drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd649 = devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1107 = kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c12c8 = ioctl+0x168 > syscallenter() at 0xffffffff803b57be = syscallenter+0x26e > syscall() at 0xffffffff80545e52 = syscall+0x42 > Xfast_syscall() at 0xffffffff805308a2 = Xfast_syscall+0xe2 > > Is this a serious LOR? > How can I resolve it? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CDD1CDB.6020409>