Date: Sat, 15 Jun 2002 11:06:27 -0700 From: Maxime Henrion <mux@freebsd.org> To: hackers@FreeBSD.org Cc: Evan Sarmiento <evms@cs.bu.edu> Subject: Re: CHN_LOCK() Message-ID: <20020615180627.GO85244@elvis.mu.org> In-Reply-To: <200206151734.g5FHYBs26505@csa.bu.edu> References: <200206151734.g5FHYBs26505@csa.bu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Evan Sarmiento wrote: > I keep on getting debug messages like this, both at startup > and right before any sound plays: > > Jun 14 23:44:38 teqnix kernel: /usr/src/sys/vm/uma_core.c:1327: could > sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:713 > heyeh, Jun 14 23:44:38 teqnix kernel: /usr/src/sys/vm/uma_core.c:1327: could > sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:713 [...] > To avoid this, I was wondering if I could change CHN_LOCK() to use > spin locks instead of sleeping mutex locks? Of course I would > make it so that mtx_init has RECURS.. would this work? This debugging messages appear because some code calls malloc() without the M_NOWAIT flags, so if memory is not available right now, the code may sleep while holding the lock which is bad. Changing the type of the mutex to a spin mutex would not fix anything, and would make things a lot worse. You need to change the code so that it calls malloc() earlier, while it's not holding any lock, or unlock before calling malloc(), relock and deal with the race condition if it's possible. Calling malloc() with M_NOWAIT isn't a good fix as well, because there is no reason to make this code fail if memory if not available at the moment, and not have it sleep for it instead. M_NOWAIT should only be used while in interrupt context, as far as I know. Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020615180627.GO85244>