The following reply was made to PR kern/31501; it has been noted by GNATS.

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: cube@cubidou.net
Cc: gnats-bugs@netbsd.org, tech-kern@netbsd.org
Subject: Re: kern/31501: reproducible panics with 3.99.9/i386
Date: Fri, 07 Oct 2005 21:15:56 +0900

 > Typical issue of not including "conf/std".  Yamamoto-san, I think it
 > should be better to have config(1) automatically include it, otherwise
 > we'll have reports like this any time we add something there.
 
 it's what i proposed in the first place.  (as "default-options")
 so i'm not against it.
 
 > So, as you have guessed now, your problem is that you don't have any
 > bufq strategy compiled into your kernel.  Now, the kernel should panic
 > instead of segfaulting (what happens is that it ends up with
 > bufq_strat_dummy and tries to call its init function, which is NULL).
 
 as bufq_strat_dummy is skipped in the loop, i think bsp is NULL.
 
 > To sum up, we have 3 bugs:
 > 
 >  1.  Segfault instead of panic.  Easy enough to solve, we should test
 >      after the loop if we got bufq_strat_dummy, and panic.  Or even
 >      make the #ifdef DEBUG block permanent and replace the printf with
 >      a panic().
 > 
 >  2.  fdc/fd doesn't depend on BUFQ_DISKSORT in the config files.  Should
 >      be easy enough to fix.
 
 it isn't a bug.  "fallback to an existing strategy" is
 an intended behaviour when i wrote the code.
 
 >  3.  Users don't know about conf/std and what to do with it.  Proper way
 >      to fix that is left as an exercise to the reader.  Even though I
 >      tend to agree with Yamamoto-san's point on having conf/std
 >      automatically included, users who know how config(1) works will
 >      still have a choice, while those who aren't always looking at
 >      source-changes (can't really blame them) won't be bitten in such
 >      ways that easily.
 
 users should read UPDATING. :-)
 
 YAMAMOTO Takashi