svn commit: r212964 - head/sys/kern

Andriy Gapon avg at
Wed Sep 22 14:43:18 UTC 2010

on 22/09/2010 16:46 Gavin Atkinson said the following:
> 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?

textdumps need DDB.
textdumps also need dumpdev which is not enabled by default in
/etc/defaults/rc.conf, but that's easier to fix for any individual user or a
FreeBSD "distribution".

I originally suggested to include DDB in the stable GENERICs.
But that has a number of consequences:
1. With DDB a panic results in a system going to ddb prompt instead of rebooting,
unless KDB_UNATTENDED is also specified.  System not rebooting on panic may be a
POLA violation and an inconvenience.  However, a user can change this using
debug.debugger_on_panic=0 sysctl.  Although, sysctl time might be too late in some
cases, not sure.

2. Adding KDB_UNATTENDED to GENERIC may have unexpected effect for users that
include GENERIC in their kernel config and then extend/trim it with local
directives.  So another possible POLA violation.  Again, fixable by
debug.debugger_on_panic=1 with all the howevers and althoughs.

For me personally, the significant benefits outweigh possible minor/temporary
inconveniences and surprises, but this opinion is not shared by all developers.

Really besides the point, but such FreeBSD "distributions" like FreeNAS and PC-BSD
can really use their own kernel config, they don't have to use the same GENERICs.

P.S. I think that it would have been better if you followed up to my proposal on
arch at .

Andriy Gapon

More information about the svn-src-head mailing list