PERFORCE change 113164 for review

[Attilio Rao]

2007/1/19, Hans Petter Selasky <hselasky at c2i.net>:
> On Friday 19 January 2007 17:58, Attilio Rao wrote:
> > 2007/1/19, Hans Petter Selasky <hselasky at freebsd.org>:
> > > http://perforce.freebsd.org/chv.cgi?CH=113164
> > >
> > > Change 113164 by hselasky at 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