From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:04:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61E6910656A6; Mon, 8 Nov 2010 12:04:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A09038FC17; Mon, 8 Nov 2010 12:04:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA8C43LJ086489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 14:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA8C43BL096621; Mon, 8 Nov 2010 14:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA8C43j3096620; Mon, 8 Nov 2010 14:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Nov 2010 14:04:03 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101108120403.GC2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i1pIEVnkQA3wUJat" Content-Disposition: inline In-Reply-To: <4CD7E401.1010206@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 12:04:11 -0000 --i1pIEVnkQA3wUJat Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: > on 05/11/2010 09:27 Andriy Gapon said the following: > >=20 > > 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 s= tarted to > > have panics with a kernel that has INVARIANTS and WITNESS enabled. >=20 > I tried to solve the problem by changing drmdev from mutex to sx: > http://people.freebsd.org/~avg/drm-sx.diff I remember that drm lock can be acquired from the interrupt thread, if the card supports interrupts. Changing it to sx cannot work then, because interrupt threads cannot sleep. Most likely, you are getting around it since r600 not yet used interrupts on FreeBSD. I think the solution is to drop drm lock around copyin. >=20 > 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:7= 91 > 2nd 0xffffff0072a87200 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a =3D db_trace_self_wrapper+0= x2a > kdb_backtrace() at 0xffffffff803a7a6a =3D kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd40c =3D _witness_debugger+0x2c > witness_checkorder() at 0xffffffff803be879 =3D witness_checkorder+0x959 > _sx_slock() at 0xffffffff80378af8 =3D _sx_slock+0x88 > _vm_map_lock_read() at 0xffffffff805109e6 =3D _vm_map_lock_read+0x36 > vm_map_lookup() at 0xffffffff805127b4 =3D vm_map_lookup+0x54 > vm_fault() at 0xffffffff805097f9 =3D vm_fault+0xf9 > trap_pfault() at 0xffffffff80545d0f =3D trap_pfault+0x11f > trap() at 0xffffffff80546597 =3D trap+0x657 > calltrap() at 0xffffffff805305c8 =3D calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff8054405d, rsp =3D 0xffffff81241b47f0, rbp= =3D > 0xffffff81241b4870 --- > copyin() at 0xffffffff8054405d =3D copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fbd7 =3D radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa38 =3D drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd649 =3D devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1107 =3D kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c12c8 =3D ioctl+0x168 > syscallenter() at 0xffffffff803b57be =3D syscallenter+0x26e > syscall() at 0xffffffff80545e52 =3D syscall+0x42 > Xfast_syscall() at 0xffffffff805308a2 =3D Xfast_syscall+0xe2 >=20 > Is this a serious LOR? I think it is. The d_mmap() cdevsw method acquires drm lock. > How can I resolve it? See above. >=20 > > The panic: > > Kernel page fault with the following non-sleepable locks held: > > exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xffffff0001b968a0) lock= ed @ > > /usr/src/sys/dev/drm/drm_drv.c:791 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff801b8afa =3D db_trace_self_wrapper= +0x2a > > kdb_backtrace() at 0xffffffff803a7afa =3D kdb_backtrace+0x3a > > _witness_debugger() at 0xffffffff803bd49c =3D _witness_debugger+0x2c > > witness_warn() at 0xffffffff803bed32 =3D witness_warn+0x322 > > trap() at 0xffffffff8054639f =3D trap+0x39f > > calltrap() at 0xffffffff80530688 =3D calltrap+0x8 > > --- trap 0xc, rip =3D 0xffffffff8054411d, rsp =3D 0xffffff81241917f0, r= bp =3D > > 0xffffff8124191870 --- > > copyin() at 0xffffffff8054411d =3D copyin+0x3d > > radeon_cp_texture() at 0xffffffff8022fcc7 =3D radeon_cp_texture+0x167 > > drm_ioctl() at 0xffffffff8020fa78 =3D drm_ioctl+0x318 > > devfs_ioctl_f() at 0xffffffff802dd739 =3D devfs_ioctl_f+0x109 > > kern_ioctl() at 0xffffffff803c1197 =3D kern_ioctl+0x1f7 > > ioctl() at 0xffffffff803c1358 =3D ioctl+0x168 > > syscallenter() at 0xffffffff803b584e =3D syscallenter+0x26e > > syscall() at 0xffffffff80545f12 =3D syscall+0x42 > > Xfast_syscall() at 0xffffffff80530962 =3D Xfast_syscall+0xe2 > > --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x801f96a1c, rsp =3D 0x= 7fffffffe7a8, > > rbp =3D 0xc020644e --- > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x832372000 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff8054411d > > stack pointer =3D 0x28:0xffffff81241917f0 > > frame pointer =3D 0x28:0xffffff8124191870 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 3 > > current process =3D 3439 (initial thread) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > >=20 > >=20 > > 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. > >=20 > > What's not obvious is how to properly fix this. > > Any ideas? > >=20 > > Probably less important is what started to trigger the problem. Becaus= e the > > code hasn't been changed in ages and I have never seen this issue befor= e. > > But, d'oh, it seems that this issue has been already reported: > > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg67757.html > >=20 > > I will appreciate any help. > > Thanks! >=20 >=20 > --=20 > Andriy Gapon --i1pIEVnkQA3wUJat Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzX5zIACgkQC3+MBN1Mb4iYCQCg69m64iuVew7hcbIqf7PdA6G6 KXEAnjxNj7QvJMFQthFHcZ4mNeFNVLwI =gS5A -----END PGP SIGNATURE----- --i1pIEVnkQA3wUJat--