From owner-freebsd-current@FreeBSD.ORG Sun Apr 27 22:06:22 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4726637B401 for ; Sun, 27 Apr 2003 22:06:22 -0700 (PDT) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [61.88.9.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C338543F3F for ; Sun, 27 Apr 2003 22:06:18 -0700 (PDT) (envelope-from Johny.Mattsson@ericsson.com.au) Received: from brsf10.epa.ericsson.se ([61.88.9.226]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3S53r417079 for ; Mon, 28 Apr 2003 15:03:53 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) h3S56E022700 for ; Mon, 28 Apr 2003 15:06:15 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Apr 2003 15:06:14 +1000 Message-ID: From: "Johny Mattsson (EPA)" To: "'current@freebsd.org'" Date: Mon, 28 Apr 2003 15:06:12 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: RE: kernel paniced: now what? - IDEA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 28 Apr 2003 05:06:22 -0000 Hi all, Seeing as this is a question that pops up rather frequently ("it panicked - now what?"), I thought I'd put up an idea for discussion: I suspect a lot of you people have or have had exposure to products such as Cisco and/or NetScreen. One of the really nifty things with those (and probably others) is the command "show tech" (or "get tech" in NetScreen's case), which provides a rather complete debug dump including state information, statistics, configuration data, and the like, which can be used quite efficiently to pinpoint problems. How about introducing such a command to the kernel debugger? That way even a non-kernel-hacker such as myself would have a quite straight forward way of generating a good quality bug report. Say for example it was to include the stack trace, parameter printouts/dereferences for each of the frames, mutex states, memory stats, and some other useful goodies. Of course, if you don't have a serial terminal attached, it'll probably be too much info to copy by hand, but that's a separate issue. I'd love to back this idea up with patches, but I'm not a kernel hacker, and have no exposure to debugger internals either. If what I'm suggesting is infeasible, I'll take your word for it, but I thought I'd put the question out there at least. Comments? Would the resulting advantages compensate for the time invested in adding such a feature? Regards, /Johny