Date: Mon, 26 May 2008 12:17:56 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Ariff Abdullah <ariff@freebsd.org> Cc: freebsd-current@freebsd.org, d@delphij.net Subject: Re: /dev/soiund/pcm/dsp.c: uma_zalloc with non-sleepable lock held Message-ID: <20080526091756.GF21317@deviant.kiev.zoral.com.ua> In-Reply-To: <20080526155514.221a210e.ariff@FreeBSD.org> References: <483A58D9.4090400@delphij.net> <20080526155514.221a210e.ariff@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--jkO+KyKz7TfD21mV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 26, 2008 at 03:55:14PM +0800, Ariff Abdullah wrote: > On Sun, 25 May 2008 23:29:45 -0700 > Xin LI <delphij@delphij.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > Hi, > >=20 > > Hit this with WITNESS (today's -CURRENT). It seems that if I play > > music and have some other sound playing then the system would stop > > to respond. ~ Is this an known issue? > >=20 > > May 25 23:26:50 charlie kernel: uma_zalloc_arg: zone "16" with the > > following non-sleepable locks held: > > May 25 23:26:50 charlie kernel: exclusive sleep mutex pcm0 (sound > > cdev) r =3D 0 (0xffffff00019a9c20) locked @ > > /data/src/sys/modules/sound/sound/../../../dev/sound/pcm/dsp.c:650 > > May 25 23:26:50 charlie kernel: KDB: stack backtrace: > > May 25 23:26:50 charlie kernel: db_trace_self_wrapper() at > > db_trace_self_wrapper+0x2a > > May 25 23:26:50 charlie kernel: witness_warn() at witness_warn+0x248 > > May 25 23:26:50 charlie kernel: uma_zalloc_arg() at > > uma_zalloc_arg+0x334 May 25 23:26:50 charlie kernel: malloc() at > > malloc+0x8a May 25 23:26:50 charlie kernel: notify() at notify+0x67 > > May 25 23:26:50 charlie kernel: destroy_devl() at destroy_devl+0x23b > > May 25 23:26:50 charlie kernel: destroy_dev() at destroy_dev+0x19 > > May 25 23:26:50 charlie kernel: snd_clone_gc() at snd_clone_gc+0xc4 > > May 25 23:26:50 charlie kernel: snd_clone_unref() at > > snd_clone_unref+0x58 May 25 23:26:50 charlie kernel: dsp_close() at > > dsp_close+0x6d5 May 25 23:26:50 charlie kernel: devfs_close() at > > devfs_close+0x15c May 25 23:26:50 charlie kernel: vn_close() at > > vn_close+0xb6 May 25 23:26:50 charlie kernel: vn_closefile() at > > vn_closefile+0x80 May 25 23:26:50 charlie kernel: devfs_close_f() at > > devfs_close_f+0x1a May 25 23:26:50 charlie kernel: _fdrop() at > > _fdrop+0x23 May 25 23:26:50 charlie kernel: closef() at closef+0x4c > > May 25 23:26:50 charlie kernel: kern_close() at kern_close+0x10d > > May 25 23:26:50 charlie kernel: syscall() at syscall+0x1bf > > May 25 23:26:50 charlie kernel: Xfast_syscall() at > > Xfast_syscall+0xab May 25 23:26:50 charlie kernel: --- syscall (6, > > FreeBSD ELF64, close), rip =3D 0x804651f5c, rsp =3D 0x7fffffffd5e8, rbp > > =3D 0x803aa53f0 --- > >=20 >=20 > It is something new. Let me examine it first. Not quite. You cannot hold a mutex over the destroy_dev(), because the destroy_dev() may sleep. It was not very common situation, because it requires another thread still in the driver methods to trigger the problem. Now, because the malloc() is called unconditionally in the destroy_dev() since rev. 1.212, the problem gets hit regularly. --jkO+KyKz7TfD21mV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkg6gEMACgkQC3+MBN1Mb4iB/ACg1+noddHV3CG3Do0z4+T5Fpj5 pZ4AniYy7841ZxzvvhpwikFBYs20h9q+ =qxIV -----END PGP SIGNATURE----- --jkO+KyKz7TfD21mV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080526091756.GF21317>