svn commit: r212964 - head/sys/kern

[John Baldwin]

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