Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Apr 2004 08:22:00 +1000
From:      Peter Jeremy <peterjeremy@optushome.com.au>
To:        ticso@cicely.de
Cc:        current@freebsd.org
Subject:   Re: panic on one cpu leaves others running...
Message-ID:  <20040408222200.GD6458@server.vk2pj.dyndns.org>
In-Reply-To: <20040408142742.GD5279@cicely12.cicely.de>
References:  <Pine.NEB.3.96L.1040408001234.39416A-100000@fledge.watson.org> <20040408091030.GA6458@server.vk2pj.dyndns.org> <40751A74.50504@freebsd.org> <20040408114441.GB6458@server.vk2pj.dyndns.org> <20040408142742.GD5279@cicely12.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 08, 2004 at 04:27:43PM +0200, Bernd Walter wrote:
>On Thu, Apr 08, 2004 at 09:44:41PM +1000, Peter Jeremy wrote:
>> >  A panic usually means that
>> >something unrecoverable happened, and that continuing on is not safe.
>> 
>> I realise that.  Hence actually being able to continue after a panic
>> would be extremely difficult to do safely.  (Probably not possible in
>> general, though it might be in some special cases).
>
>If it's save to continue then there's no need to panic at all.
>Just stoping the faulting parts would be enough in that case.

Except FreeBSD (and most Unices) don't do this in general.

I was thinking of hardware failures - if a CPU fails and it wasn't
holding any locks then it would seem feasible to just abort the
thread/process that was using the CPU and limp along on the remaining
CPU(s).

Likewise an unrecoverable memory error in a clean page should (in most
cases) be able to be recovered by marking that page unusable and
loading another copy of the data into another page.  (Obviously this
is problematic if the page in question is part of the kernel VM
subsystem or the device driver for the relevant backing store).  Even
a dirty page may be recoverable by aborting the affected process or
treating it similarly to an I/O error on a filesystem.

The marketing spin from at least one vendor suggests that their
high-end systems can manage this sort of fault recovery.  I'm not sure
whether this is an area that FreeBSD should aspire to - I suspect that
the effort needed to implement and test this would not be justified by
the small size of the additional potential market.

Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040408222200.GD6458>