Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2011 21:33:44 +0100
From:      "C. P. Ghost" <cpghost@cordula.ws>
To:        David DEMELIER <demelier.david@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: why panic(9) ?
Message-ID:  <AANLkTinFMxA_81UXiJ=7feNmPC3xzZN-4TucifLEAwvh@mail.gmail.com>
In-Reply-To: <AANLkTi=OQbS-0jJx0YwZhM7xDWPLOkaYYZAYfESUEvvM@mail.gmail.com>
References:  <AANLkTi=OQbS-0jJx0YwZhM7xDWPLOkaYYZAYfESUEvvM@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 11, 2011 at 9:11 PM, David DEMELIER
<demelier.david@gmail.com> wrote:
> Hello,
>
> I'm just guessing why current BSD panic() when a problem occurs, all
> modern operating systems solve the problem instead of crashing
> suddently and corrupting all your data without saving your work.
>
> Yes, why this function exists? There is no way to solve a problem
> without panic'ing? Is panic really needed? Imagine someone working on
> something really important and his computer just panic, his work not
> saved everybody shout at him in the corporation. He lose his job, his
> wife, his dog, everything is wrong, just because of a panic() !

Sometimes, it's best to panic(9) rather than to try recovery. Imagine
a situation where the kernel detects that some of its important internal
data structures are corrupted. Should it resume execution with pointers
pointing into some Nirwana (and "undefined behavior" in the worst case
means that some serious bad things could happen), or is it preferable
to panic(9) right away?

Granted, some panics could handled more gracefully, e.g. flushing
buffers and such to disk... but here again: in most cases, the kernel
can't be sure that it is internally sane enough to write to disk (it could
overwrite other parts of the disk by syncing, right?), so better leave the
disks untouched in this circumstance (only exception: dumping core).

> Seriously, I really hate when I play some music that suddenly the
> music get stucked in a infinite loop, why ? I don't know because the
> panic does not core dump. But after some search I found that the panic
> was done because of conky. How the hell conky can panic FreeBSD? We
> are in 2011 ! I think even Window 2000 does not crash on a user-land
> software.
>
> I'm guessing now, if minix panic when a bloated crappy software is
> running. I think Andrew is in the right way.

The real problem we have here (IMHO), is that we don't have a microkernel
architecture. Any error in a driver would panic the whole system. This
is a real pain. But short of redesigning BSD from scratch, there's not
much we could do atm.

> --
> Demelier David

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinFMxA_81UXiJ=7feNmPC3xzZN-4TucifLEAwvh>