Date: Tue, 28 Sep 2010 15:04:11 -0400 From: John Baldwin <jhb@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: bruce@cran.org.uk, src-committers@freebsd.org, Ken Smith <kensmith@buffalo.edu>, svn-src-all@freebsd.org, avg@freebsd.org, gavin@freebsd.org, svn-src-head@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: svn commit: r212964 - head/sys/kern Message-ID: <201009281504.12236.jhb@freebsd.org> In-Reply-To: <20100928183350.GB2224@garage.freebsd.pl> References: <20100922222441.00002f27@unknown> <201009240923.04406.jhb@freebsd.org> <20100928183350.GB2224@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 28, 2010 2:33:50 pm Pawel Jakub Dawidek wrote: > On Fri, Sep 24, 2010 at 09:23:04AM -0400, John Baldwin wrote: > > > Because disks are big and (again, just trying to explain my > > > understanding of what I inherited) we want all the support > > > to be in place, just not turned on. There is a difference > > > between "You can give us much better information by doing > > > <these extra installation steps, including installing the > > > .symbols goo> and then making a one-line change to rc.conf" > > > versus "You can give us much better information by making > > > a one-line change to rc.conf". > > > > The biggest argument against this (and the reason I always enable crashdumps > > on all machines I am involved with) is that many panics are not easily > > reproducible, esp. ones that trigger under load. If dumpdev is not on by > > default, then the info from a rare or hard-to-trigger bug may simply be lost. > > Also, "just send-pr or mail the 'foo' file" is even simpler than "enable this > > knob in rc.conf and reproduce your issue, then come back". > > I am bigger fan of textdumps than minidumps, because in my opinion > textdumps provide quite a lot of useful info. I'm working with FreeBSD > kernel for years now and almost entirely avoided gdb for kernel > debugging. DDB and printf(9) are in 99% enough for me (maybe I'm too > traditional, but that's the fact). I'm not saying that textdumps are > enough in 99%, though. Have you looked at a /var/crash/core.txt.X file yet? If not, you should, as it is very similar to a text dump. In fact, it will contain the contents of any ddb trace buffer in addition to a stack trace from kgdb, process listing from ps, etc. > > Well, if we turn it on we should document it clearly. Folks are already > > interested in asking for help once a machine panics, and if the reply to a > > query on questions@ can say "please go look for a file named 'foo' and e-mail > > it somewhere or send-pr it", that is far simpler than having to enable dumps > > and reproduce the panic. > > Another important thing in my opinion is privacy of user's data. Once > the data hit the disk it can stay there forever. This is why I use > encrypted swap everywhere. I'd never send kernel minidump from my > laptop or from any of my servers to anyone, but I'd be happy to send > textdump. > > I find textdumps a great solution that's in the middle between > protecting user's privacy and providing a lot of useful info and I'd > much prefer to turn on textdumps by default and eventually extend what > we dump, than to make minidumps the default. I'm suggesting they provide us the core.txt.X file, not the full minidump. A developer could then ask them to run specific commands from a subsequent kgdb session to obtain more details. > You can always ask user to add this one-line to rc.conf to turn > minidump on and provide you the info that was missing in textdump. This only works for easily reproducible bugs, and in that case they can turn on dumps later without a need for it to be automatic at all. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009281504.12236.jhb>