Re: HEADS UP: panic behaviour changed

[Johnny Billquist <bqt%softjar.se@localhost>]

Robert Elz wrote:
>     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.

True. Forget X. What we're talking about here is the default, and more 
precisely at the time when the default hasn't been changed (yet).

>   | 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.

Yes.

>   | 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.

Well. If something panics at an early stage, then you probably do want 
to do something extraodrinary anyway, so a simple reboot is never the 
right answer. ddb might be the right answer, or it might not.
Either way, manual intervention is needed, and a straight reboot is 
always the wrong answer. ddb or not depends, but getting into ddb 
certainly will not hinder taking some other action after that.

> 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).

This situation looks more like the system have booted far enough for 
sysctl.conf being processed, so I don't think it's relevant for talking 
about the default value.

Remember, the default value is only applicable until we've started going 
though the rc script.

>   | 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).

Exactly. It don't hurt do drop into ddb on a panic. And since we're 
talking about the default, it's really only the question of what to do 
if we panic before rc have been run. At that point, what should we do on 
a panic? Reboot or ddb? I think that ddb is the right answer.
Once rc have been run, it's the users choice, and he can decide 
appropriately what is the right thing for his situation.

> 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?

Well, for me it's not a big issue. I initially wondered if the change 
Andrew posted really just was a question of changing the default, and it 
appears it is.

I personally think that the old default was appropriate, but since I 
build my own kernels anyway, I really don't care much.

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol