From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 14:09:03 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB26A106564A for ; Tue, 23 Aug 2011 14:09:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 024F28FC08 for ; Tue, 23 Aug 2011 14:09:02 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA28183 for ; Tue, 23 Aug 2011 17:09:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E53B47C.2000901@FreeBSD.org> Date: Tue, 23 Aug 2011 17:09:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: common entry point for "software" and "hardware" "panics" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 14:09:03 -0000 Too many quote signs in the subject line... let me try to explain. Currently we have two sources of detecting some trouble/inconsistency that requires a system panic/reset or debugging. One source is various checks in the program code (e.g. KASSERTs) that call panic() when a fatal inconsistency is detected. The other source is the hardware that generates a trap when something is wrong from its point of view. In this case the trap need not be a fatal one, so the software (the kernel) checks a type of trap and decides whether the condition is fatal. But let's distinguish the purely software source from the hardware+software source. Depending on the kernel options/configuration the kernel can also react in different ways to the fatal conditions. One way is to call panic(9) , the other way is to call kdb_trap. But it's even a little bit more complicated than that. So, let's consider some possibilities. !KDB, software problem: panic -> kern_reboot !KDB, fatal trap: trap -> trap_fatal -> panic -> kern_reboot KDB, !KDB_UNATTENDED, software problem: panic -> kdb_enter -> breakpoint ~> trap -> kdb_trap KDB, !KDB_UNATTENDED, fatal trap: trap -> trap_fatal -> kdb_trap Also, kdb key from console: kdb_enter -> breakpoint ~> trap -> kdb_trap panic key from console: kdb_panic -> panic -> ... and also some code calls kdb_enter instead of panic in situations that require debugging: kdb_enter -> breakpoint ~> kdb_trap So, we can see that in these examples that currently we do not have a function that would be called in all the cases. I think that it would be nice if we had some sort of a (semi-)universal front-end to panic and kdb_trap. E.g. it could be useful for some common tasks like stopping other CPUs in SMP environment. Then, it could be useful for printing some information useful in both cases like e.g. a stack trace. Or perhaps deciding whether KDB should be actually entered in a common place. Unfortunately, this is not a proposal, just sort of musings on the topic. Does anybody have some more concrete ideas here? Thank you! -- Andriy Gapon