Date: Fri, 19 Jan 2007 19:42:14 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Hans Petter Selasky" <hselasky@c2i.net> Cc: perforce@freebsd.org Subject: Re: PERFORCE change 113164 for review Message-ID: <3bbf2fe10701191042i2833731an96c286c40877353@mail.gmail.com> In-Reply-To: <200701191814.04201.hselasky@c2i.net> References: <200701191656.l0JGuPu7025321@repoman.freebsd.org> <3bbf2fe10701190858v4fbdf5ct5fd39c6e16f2a10d@mail.gmail.com> <200701191814.04201.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/1/19, Hans Petter Selasky <hselasky@c2i.net>: > On Friday 19 January 2007 17:58, Attilio Rao wrote: > > 2007/1/19, Hans Petter Selasky <hselasky@freebsd.org>: > > > http://perforce.freebsd.org/chv.cgi?CH=113164 > > > > > > Change 113164 by hselasky@hselasky_mini_itx on 2007/01/19 16:56:15 > > > > > > The sound mutex needs to allow recursion, else the > > > new "uaudio" will not work. > > > > > > Affected files ... > > > > > > .. //depot/projects/usb/src/sys/dev/sound/pcm/sound.c#3 edit > > > > > > Differences ... > > > > > > ==== //depot/projects/usb/src/sys/dev/sound/pcm/sound.c#3 (text+ko) ==== > > > > > > @@ -78,7 +78,7 @@ > > > m = malloc(sizeof(*m), M_DEVBUF, M_WAITOK | M_ZERO); > > > if (m == NULL) > > > return NULL; > > > - mtx_init(m, desc, type, MTX_DEF); > > > + mtx_init(m, desc, type, MTX_DEF|MTX_RECURSE); > > > return m; > > > #else > > > return (void *)0xcafebabe; > > > > Recursed mutexes very often are symptomatic of some some bug... > > it is the case? why the mutex is recursed? > > > > Because my system shares the lock with the "pcm channel" of the sound system. > That means it uses "c->lock" (see below) to protect the isochronous USB > transfers. The problem is that my USB callback calls "chn_intr()" which also > locks the same lock. > > Maybe this should be addressed by Ariff A. ? > > void > chn_intr(struct pcm_channel *c) > { > CHN_LOCK(c); > c->interrupts++; > if (c->direction == PCMDIR_PLAY) > chn_wrintr(c); > else > chn_rdintr(c); > CHN_UNLOCK(c); > } One solution can be taking off the calls CHN_LOCK/CHN_UNLOCK from the "internal" functions and checking with mtx_assert inside them. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10701191042i2833731an96c286c40877353>