svn commit: r212964 - head/sys/kern

[John Baldwin]

On Thursday, September 23, 2010 11:11:24 pm Ken Smith wrote:
> On Thu, 2010-09-23 at 20:31 -0600, M. Warner Losh wrote:
> > In message: <alpine.LNX.2.00.1009231841500.23791 at ury.york.ac.uk>
> >             Gavin Atkinson <gavin at FreeBSD.org> writes:
> > : On Thu, 23 Sep 2010, Ken Smith wrote:
> > : > The issues talked about so far all contribute to the reason for that.
> > : > But one of the more basic gut reactions to it all is that the users
> > : > want to be interested in helping with the debugging (even if just
> > : > providing the requested info) for any sort of crash information
> > : > to be useful.  And at the point we shift something from -current
> > : > to -stable the percentage of people actively interested in participating
> > : > in that sort of stuff flip.  The bulk of people using -current
> > : > know it's risky and they do it out of some interest in debugging
> > : > stuff.  The *bulk* of people using -stable are less interested or
> > : > flat out not interested.  And have no clue what crash dumps are,
> > : > may be challenged to notice partition-getting-full issues, etc.
> > : 
> > : I'm not sure I buy this argument, I'm afraid.  Part of the advantage of 
> > : having all this done automatically on the as-shipped release media is that 
> > : end users don't have to be interested in debugging - crashinfo(8) does 
> > : most of the work for them.  There's no easy way to actually determine 
> > : figures, but even if say only 10-15% of crashes can be diagnosed and 
> > : corrected just from the output of crashinfo(8) then that's a huge win for 
> > : the project as a whole. I'm guessing 10-15% is not unrealistic.
> > : 
> > : I appreciate the issue about filling partitions is a valid one.  Would a 
> > : possible compromise be that on release media, crashinfo(8) or similar will 
> > : default to only keeping the most recent coredump or similar?  Given /var 
> > : now defaults to 4GB, Defaulting to keeping a single core is probably 
> > : acceptable.
> > 
> > Furthermore, if we aren't interested in crash dumps by default, why do
> > we install the huge .symbols files?
> > 
> > Warner
> > 
> 
> 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".

> This is definitely one I don't have a strong enough opinion
> on to fight over, I sympathize with both sides.  If the
> general consensus is mostly towards changing so be it.
> I've got no way to tell what percentage of users would
> have any clue what to do with the crash info versus users
> who would be negatively impacted simply by the fact their
> systems are generating stuff they're completely ignorant
> of and will never touch.

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.

-- 
John Baldwin