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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
