Re: HEADS UP: panic behaviour changed

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 31 Jan 2009 19:48:14 +0000 (UTC)
    From:        Eduardo Horvath <eeh%NetBSD.org@localhost>
    Message-ID:  <Pine.NEB.4.64.0901311938090.17004%mail.netbsd.org@localhost>

As I have said before, I don't really care which way the default
for ddb.onpanic is set, but ...

  | 1) Not everyone runs X.  Most servers use a serial console.

Forget X when discussing this issue, X isn't an argument for anything,
one way or the other.   By the time X gets anywhere near the system,
sysctl.conf has run, and the local system owner can trivially decide
which behaviour works for them and insert the relevant line into
sysctl.conf.

If the best argument anyone can come up with for one default or the
other is that it avoids the need for an entry in sysctl.conf then
that effectively means there is no reason at all.
 
  | 3) There is a period of time between loading the kernel and when the rc 
  | scripts run where you can't tweak the ddb_onpanic value.

Yes, this is why the kernel needs a default value, and why we can
sensibly discuss what that default value should be.  By itself it
doesn't say anything about which particular value should be the
default however.

  | 4) If the machine panics early, say during device configuration due to 
  | broken hardware, you don't really want it to attempt to reboot, since that 
  | will result in an infinite reboot loop.

Yes, perhaps - it depends upon the cause of the panic, but this
can certainly happen.   But I'm not sure this is any worse (or
better) than the infinite loop the kernel is sitting in waiting
for a reply to the db> prompt.   Both require user interaction,
and nothing proceeds until a user has done something to alter the
state of the system.

As an alternative, if the system panics due to a corrupted filesystem
that was incorrectly marked clean, then ddb is of no practical use
and a reboot will detect the unclean filesys and fsck (and either
fix, or at least tell the user what the problem is).

  | Given all this, the default should be to have the kernel drop to DDB when 
  | it panics.

Sorry, I cannot see that follows.   Nor can I see that it is incorrect
either, you just haven't convinced me either way.

I actually suspect that the answer to this question really doesn't matter
(and ideally should never even be slightly relevant).

Aside from broken hardware, the kernel just shouldn't panic at all.
ddb is of no real help with broken hardware, so if the kernel panics
because of broken hardware, dropping into ddb isn't going to help
(nor will it hurt probably, the system needs to be fixed before doing
any more real work).

I really cannot remember the last time a NetBSD kernel panic'd on me,
it would be years ago I suspect.  Of course, I don't routinely run
unstable builds, so I am mostly not dealing with bleading edge development
code.   The last time a kernel panic'd so early that its panic behaviour
couldn't have been set in sysctl.conf I couldn't even begin to guess
(except that it would have been way back before sysctl.conf existed....)

Overall, my conclusion is that the default value for this option
simply doesn't matter - there's no value that is going to be right
for everyone, in the very rare cases where it matters at all.

So, why the arguments?

kre