Subject: Re: kern/31501: reproducible panics with 3.99.9/i386
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 10/07/2005 21:15:56
> 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. :-)