I suppose I should say that "Less than 100% satisfaction..." was intended
as a humorous intro to a problem; considering the changes in the past couple
of days, problems in _one_ driver is a lot better than one would imagine.
If the NetBSD team hadn't lulled me into a false sense of security with their
usual excellence, I wouldn't have noticed anything unusual about -current
being unstable...  :-)

I know the reports weren't very specific; the first was dramatic enough that
I imagined that anyone with a PAS board would see it too, and the second was
one of those irreproducible problems that my experience on the receiving end
of such bug reports indicated that it wouldn't be easy making it more concrete.

The first was also easily fixable; pas.c doesn't initialize the sbdsp_softc
it hands to sbsdp_probe().  For some reason, adding a tracing printf() turned
the mysterious reset into a visible kernel page fault, making it easy to find
and then fix.  I've sent Chris D. my proposed fix; if anyone else wants it
(like, whoever maintains the audio driver code, for example) I can send-pr it
or mail it direct.

The second is, I think, not a problem.  I just recompiled audio.c, and sure
enough, it just simply takes 1 minute 10 seconds to compile, all of it user
run time.  (I.e. in multi-user mode, I was able to do ps and watch disk
activity while cc1 sat there sucking down cycles.)  audio.c certainly doesn't
LOOK complicated enough to deserve that kind of attention, but clearly this
isn't a disk driver problem.