From owner-freebsd-hackers Sat Jun 15 11: 6:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A517837B404 for ; Sat, 15 Jun 2002 11:06:27 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1920) id 4D324AE165; Sat, 15 Jun 2002 11:06:27 -0700 (PDT) Date: Sat, 15 Jun 2002 11:06:27 -0700 From: Maxime Henrion To: hackers@FreeBSD.org Cc: Evan Sarmiento Subject: Re: CHN_LOCK() Message-ID: <20020615180627.GO85244@elvis.mu.org> References: <200206151734.g5FHYBs26505@csa.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206151734.g5FHYBs26505@csa.bu.edu> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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