Re: need some debugging help

On Sun, Aug 31, 2003 at 12:52:47 +0200, Poul-Henning Kamp wrote:
> In message <20030831070854.GA54748_at_panzer.kdm.org>, "Kenneth D. Merry" writes:
> 
> >Anyway, I got some debugging output, and I've attached dmesg output.  Let
> >me know whether anything in there looks suspicious or points to a possible
> >problem.
> 
> There's nothing which jumps out at me, and I guess the best strategy is
> hunting down the devbuf thing by changing all users of M_DEVBUF until
> something trips...

Thanks.  That did the trick.

As it turns out, it was a one-line problem in the da(4) patches that was
causing the problem.

Anyway, that's fixed, and things seem to work fine.  I've attached a new
version of the patches.  I'll try to come up with a -stable version that'll
fix things there as well.

If anyone wants to take a look at the way I'm using mutexes here,
especially in the new taskqueue thread, I'd appreciate it.

In particular, I went through some interesting permutations in
taskqueue_kthread() to make things work right:

 - I tried holding Giant when calling tsleep, but it complained that I
   didn't own Giant.

 - I tried not holding a mutex at all when calling tsleep, but ran into
   this assert in msleep():

        KASSERT(timo != 0 || mtx_owned(&Giant) || mtx != NULL,
            ("sleeping without a mutex"));

 - I tried just holding a mutex all the time, but obviously you can't
   malloc while holding a mutex (except Giant), and the sysctl code does a
   number of mallocs.  (The original cause of this problem -- M_WAITOK
   mallocs.)

So in the end, I just acquire a mutex, drop it for taskqueue_run(),
re-acquire it and and pass it into the msleep call so that it can drop it
and re-acquire it for me.  There's no other reason for it.  The taskqueue
stuff already has its own mutex that isn't exposed to taskqueue_run(), and
it shouldn't be held anyway when the task's function is called.

I also put code in the sysctl functions in the cd(4) and da(4) drivers to
acquire Giant, since I'm assuming that the sysctl code needs it.

Comments are welcome.

Thanks,

Ken
-- 
Kenneth Merry
ken_at_kdm.org