Date: Wed, 22 Sep 2010 14:46:40 +0100 From: Gavin Atkinson <gavin@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r212964 - head/sys/kern Message-ID: <1285163200.64197.10.camel@buffy.york.ac.uk> In-Reply-To: <201009211507.o8LF7iVv097676@svn.freebsd.org> References: <201009211507.o8LF7iVv097676@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2010-09-21 at 15:07 +0000, Andriy Gapon wrote: > Author: avg > Date: Tue Sep 21 15:07:44 2010 > New Revision: 212964 > URL: http://svn.freebsd.org/changeset/base/212964 >=20 > Log: > kdb_backtrace: stack(9)-based code to print backtrace without any backe= nd > =20 > The idea is to add KDB and KDB_TRACE options to GENERIC kernels on > stable branches, so that at least the minimal information is produced > for non-specific panics like traps on page faults. > The GENERICs in stable branches seem to already include STACK option. Ignoring the rest of the discussion about locking, I think this is a step in the right direction. However, what I feel we should be strongly considering is for textdumps to be enabled by default on release media. As more groups choose to use the kernels from the release media (PC-BSD, FreeNAS, etc) and put them into places where end users are never expected to recompile kernels, having textdumps enabled by default in RELEASE kernels becomes a bigger and bigger priority. Groups like PC-BSD don't necessarily have the time or skills to do the needed kernel debugging (and nor should they have to, it's not their purpose), so anything we can do in releases to make sure we have enough info to resolve panics seen by their users is a big bonus. Is there any real reason why we shouldn't go down this route? Thanks, Gavin --=20 Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1285163200.64197.10.camel>