(unknown charset) Re: radeon_cp_texture: page fault with non-sleepable locks held

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) _at_ /usr/src/sys/dev/drm/drm_drv.c:791
> 2nd 0xffffff0072a87200 user map (user map) _at_ /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