NetBSD Problem Report #45313
From jakllsch@yavin.kollasch.net Tue Aug 30 15:05:16 2011
Return-Path: <jakllsch@yavin.kollasch.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id DBC2863C0E2
for <gnats-bugs@gnats.NetBSD.org>; Tue, 30 Aug 2011 15:05:16 +0000 (UTC)
Message-Id: <20110830150513.6261E164BD@yavin.kollasch.net>
Date: Tue, 30 Aug 2011 15:05:13 +0000 (UTC)
From: jakllsch@kollasch.net
Reply-To: jakllsch@kollasch.net
To: gnats-bugs@gnats.NetBSD.org
Subject: panic(9)
X-Send-Pr-Version: 3.95
>Number: 45313
>Category: kern
>Synopsis: panic(9) is too fatal
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Aug 30 15:10:00 +0000 2011
>Last-Modified: Tue Jun 06 03:10:00 +0000 2017
>Originator: Jonathan A. Kollasch
>Release: NetBSD 5.99.55
>Organization:
>Environment:
System: NetBSD yavin.kollasch.net 5.99.55 NetBSD 5.99.55 (YAVIN) #37: Sat Aug 20 12:34:40 CDT 2011 jakllsch@trantor.kollasch.net:/local/jakllsch/nbsd-head/build-amd64/objdir/sys/arch/amd64/compile/YAVIN amd64
Architecture: x86_64
Machine: amd64
>Description:
panic(9) should not be and can not be fatal.
>How-To-Repeat:
db> call kmem_alloc(128, 0)
>Fix:
Make it possible to continue from panic(9) if you know what to poke in ddb.
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/45313: panic(9)
Date: Tue, 30 Aug 2011 18:52:41 +0000
On Tue, Aug 30, 2011 at 03:10:01PM +0000, jakllsch@kollasch.net wrote:
> panic(9) should not be and can not be fatal.
if you want linux, you know where to get it.
--
David A. Holland
dholland@netbsd.org
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/45313: panic(9)
Date: Tue, 30 Aug 2011 19:28:09 +0000
On Tue, Aug 30, 2011 at 06:55:02PM +0000, David Holland wrote:
> On Tue, Aug 30, 2011 at 03:10:01PM +0000, jakllsch@kollasch.net wrote:
> > panic(9) should not be and can not be fatal.
>
> if you want linux, you know where to get it.
Sorry, that was way too snarky.
The actual proposition is:
If you panic or assert and drop into ddb, and you know what you're
doing, and at least in less severe circumstances, it would be nice to
be able to e.g. force the current lwp to return with an error and
continue, or just suspend it, in order to be able to do
sync;sync;reboot.
obviously such a procedure won't always work, but sometimes it will.
jakllsch also says that we currently no longer even attempt to sync
during panic, which seems wrong.
--
David A. Holland
dholland@netbsd.org
From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/45313: panic(9) is too fatal
Date: Tue, 6 Jun 2017 03:05:07 +0000
It's a reasonable request.
I've had a case where mounting / rw triggered an assert, and couldn't
replace the kernel without a second machine to make a USB image with a
non DIAGNOSTIC kernel.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.