Date: Mon, 8 Nov 2010 14:04:03 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held Message-ID: <20101108120403.GC2392@deviant.kiev.zoral.com.ua> 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
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101108120403.GC2392>