From owner-freebsd-current@FreeBSD.ORG Sun Jan 23 23:04:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5CC71065672 for ; Sun, 23 Jan 2011 23:04:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5638B8FC0A for ; Sun, 23 Jan 2011 23:04:24 +0000 (UTC) Received: by wwf26 with SMTP id 26so3399440wwf.31 for ; Sun, 23 Jan 2011 15:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FxjjJh7JI4RH1y+IMqwCGSDbjUqNgQX+CMTeb4d157U=; b=MpVCpqJCC2Ryj+rVBBEpMbttnYXgI7JRASPjbEg/qPZWL8OoB5J2CWRe+C0iu3Ygxw QBdn71hMn8JgHneiGgH61l+oe6HCUqGQY1qTkbNAI0ilD8+PQE2LBNRaYzlFbB4ZW858 pfS8KWxBudDcJaE+V2jGc6xYarRZUUgHHguNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QwW4Me5MzRjVoFyXUd3yDLmS9P73vLZ9495l3McR8unHlwOmU0w6evJBa9uptZyDJb Pt/o0TkVuF0/1KIy6oLhR4r4Nt8tedijQp4hGEReZkS3NSjm4mrVxXBzRl2riQN6clh3 21VBzh/8LVpHu065LmwPaOZ4UVTy6Guxn8GoM= MIME-Version: 1.0 Received: by 10.216.49.15 with SMTP id w15mr1685852web.1.1295823863269; Sun, 23 Jan 2011 15:04:23 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Sun, 23 Jan 2011 15:04:22 -0800 (PST) In-Reply-To: <4D3CB2FE.2080603@gmail.com> References: <4D3CB2FE.2080603@gmail.com> Date: Sun, 23 Jan 2011 15:04:22 -0800 X-Google-Sender-Auth: _RJFchWLkvMaHY6_GZMZYLytC0I Message-ID: From: Garrett Cooper To: David Demelier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: why panic(9) ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 23:04:24 -0000 On Sun, Jan 23, 2011 at 3:00 PM, David Demelier wrote: > On 12/01/2011 00:03, Garrett Cooper wrote: >> >> On Tue, Jan 11, 2011 at 12:11 PM, David DEMELIER >> =A0wrote: >>> >>> 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() ! >>> >>> 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. >> >> =A0 =A0 So I guess with that reasoning we don't need asserts, bugs never >> occur, and the if the computer catches on fire we should just let it >> burn up instead of getting an extinguisher and put it out :D? >> =A0 =A0 As an example: I would rather have my PC panic and not write out >> corrupt data to disk instead of write out that corrupt data to disk. >> The latter has happened with userland apps on occasion before they >> crash, and that really fries my bacon... Similarly, if we're beyond >> recovery, panicing is the best and only option, but yes... recovery >> could be handled better in some cases. Filesystems are a bit trickier >> though because they're more mission critical than say a non-critical >> device driver (my sound driver?) tanking. > > In any case, when panic occurs, switching display to the tty can be great= . > Why not a sysctl like kern.tty_on_panic? Because when you're running X an= d a > panic occurs not everybody understand what happens. > > Or the problem for me, when a panic occurs it *NEVER* core dump. Absolute= ly > never, it stops at a moment but does not finish so I need to be in tty to > debug directly so that's why a tty switch may helps in my case :-) That request makes sense... Thanks, -Garrett