From owner-freebsd-current@FreeBSD.ORG Sun Jan 23 23:00:29 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 70B3010656CE for ; Sun, 23 Jan 2011 23:00:29 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C270B8FC23 for ; Sun, 23 Jan 2011 23:00:23 +0000 (UTC) Received: by wyf19 with SMTP id 19so3561596wyf.13 for ; Sun, 23 Jan 2011 15:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9v7vTA1wgh+CJiQRpZc7Gf6SrLPCK7E2eYxElmBy03I=; b=lWsW8roqGF/cgfbN33r7tb5QYJgy2TB1cm1/hRfl01YkbVEShk/NRqCqChsNJcOCMW PSv3ufnWHCbKiLNtTy1FZH0Xb0TwrRirXHK3kH7UsIzw8ThbF4R2fXCVv4xFDAbWTjRf KO25X5xS1kQB+Wm5R3+eS0Q0gxuNE4ps4cyr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pt07PDWSEDdNjZikAeA4oCIRVY2n7lGSwp3gBOF+tVmbSK7dcFsxVgVkt0c5VNLNz7 bTVzJDxXYdeVw8so3AFv6OhmXeYbSwNm5R5bAXrfmPpKXBjlVOwuQJ8miBbueZAMsArE D87cHfPmFObrhe+xl/ThDm3yDOLBPLzfro3Eo= Received: by 10.227.143.75 with SMTP id t11mr3606371wbu.87.1295823622479; Sun, 23 Jan 2011 15:00:22 -0800 (PST) Received: from Melon.malikania.fr (65.21.102-84.rev.gaoland.net [84.102.21.65]) by mx.google.com with ESMTPS id 11sm8820863wbi.0.2011.01.23.15.00.15 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Jan 2011 15:00:16 -0800 (PST) Message-ID: <4D3CB2FE.2080603@gmail.com> Date: Mon, 24 Jan 2011 00:00:14 +0100 From: David Demelier User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110111 Thunderbird/3.1.7 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:00:29 -0000 On 12/01/2011 00:03, Garrett Cooper wrote: > On Tue, Jan 11, 2011 at 12:11 PM, David DEMELIER > 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() ! >> >> 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. > > 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? > 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. > Thanks, > -Garrett 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 and a panic occurs not everybody understand what happens. Or the problem for me, when a panic occurs it *NEVER* core dump. Absolutely 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 :-) -- David Demelier