From owner-freebsd-x11@FreeBSD.ORG Mon Nov 8 11:50:28 2010 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEBF5106566B; Mon, 8 Nov 2010 11:50:28 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A85EB8FC1F; Mon, 8 Nov 2010 11:50:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA29427; Mon, 08 Nov 2010 13:50:26 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PFQEz-0003un-QK; Mon, 08 Nov 2010 13:50:25 +0200 Message-ID: <4CD7E401.1010206@freebsd.org> Date: Mon, 08 Nov 2010 13:50:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <4CD3B1D2.30003@icyb.net.ua> In-Reply-To: <4CD3B1D2.30003@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 11:50:28 -0000 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 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? > The panic: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex drmdev (drmdev) r = 0 (0xffffff0001b968a0) locked @ > /usr/src/sys/dev/drm/drm_drv.c:791 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8afa = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff803a7afa = kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd49c = _witness_debugger+0x2c > witness_warn() at 0xffffffff803bed32 = witness_warn+0x322 > trap() at 0xffffffff8054639f = trap+0x39f > calltrap() at 0xffffffff80530688 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8054411d, rsp = 0xffffff81241917f0, rbp = > 0xffffff8124191870 --- > copyin() at 0xffffffff8054411d = copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fcc7 = radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa78 = drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd739 = devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1197 = kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c1358 = ioctl+0x168 > syscallenter() at 0xffffffff803b584e = syscallenter+0x26e > syscall() at 0xffffffff80545f12 = syscall+0x42 > Xfast_syscall() at 0xffffffff80530962 = Xfast_syscall+0xe2 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801f96a1c, rsp = 0x7fffffffe7a8, > rbp = 0xc020644e --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x832372000 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8054411d > stack pointer = 0x28:0xffffff81241917f0 > frame pointer = 0x28:0xffffff8124191870 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 3 > current process = 3439 (initial thread) > trap number = 12 > panic: page fault > cpuid = 0 > > > The panic is quite obvious: drmdev mutex is taken and held in drm_ioctl() and > radeon_cp_texture() can perform copyin and/or copyout, so it's a matter of a > chance (or proper workload) to hit a page fault there. > > What's not obvious is how to properly fix this. > Any ideas? > > Probably less important is what started to trigger the problem. Because the > code hasn't been changed in ages and I have never seen this issue before. > But, d'oh, it seems that this issue has been already reported: > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg67757.html > > I will appreciate any help. > Thanks! -- Andriy Gapon