Re: ddb_enable="YES" by default?
On 2014-09-05 16:35, John Baldwin wrote: On Friday, September 05, 2014 5:08:07 pm Peter Wemm wrote: On Friday 05 September 2014 13:51:24 Craig Rodrigues wrote: > On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin wrote: > > Probably at least 50% of the time when I work with a user on a bug report, > > I ask them to go into kgdb and run specific commands to extract more > > detailed info (print some struct, etc.). > > Sure, I understand, but you are not working with every user who > encounters a kernel panic in FreeBSD. For the average or casual > FreeBSD user, such as desktop > users of FreeBSD or PC-BSD, wouldn't it be better > to have ddb_enable="YES" be the default in FreeBSD? The ddb script > there does a fairly reasonable > job of gathering some useful info which can be analyzed later, and > then rebooting the box. > > For more expert users, or people developing products, they can set > ddb_enable="NO" > and do more advanced debugging. Or hook into /etc/rc.d/ddb and define > a different > ddb script which doesn't do textdumps on kernel panic. I think what John was saying was at that point it's too late. The loss of the crash dump means the one shot at getting more information is gone. For reproducable crashes, yes, an end user could just flip the bit. But for a one-off, it's too late. Also, crashinfo is already enabled by default. If a user enables crash dumps in the installer, they will have a nice /var/crash/core.txt.N that they can post to the mailing lists just as easily as the text dump you envision. And in fact, I've seen our users already doing this. (Have you looked at a /var/crash/core.txt.N file yet?) I've in fact done just that (posted the top part of a core.txt.N file, and gotten VERY good results from the list(s). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ddb_enable="YES" by default?
On Friday, September 05, 2014 5:08:07 pm Peter Wemm wrote: > On Friday 05 September 2014 13:51:24 Craig Rodrigues wrote: > > On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin wrote: > > > Probably at least 50% of the time when I work with a user on a bug report, > > > I ask them to go into kgdb and run specific commands to extract more > > > detailed info (print some struct, etc.). > > > > Sure, I understand, but you are not working with every user who > > encounters a kernel panic in FreeBSD. For the average or casual > > FreeBSD user, such as desktop > > users of FreeBSD or PC-BSD, wouldn't it be better > > to have ddb_enable="YES" be the default in FreeBSD? The ddb script > > there does a fairly reasonable > > job of gathering some useful info which can be analyzed later, and > > then rebooting the box. > > > > For more expert users, or people developing products, they can set > > ddb_enable="NO" > > and do more advanced debugging. Or hook into /etc/rc.d/ddb and define > > a different > > ddb script which doesn't do textdumps on kernel panic. > > I think what John was saying was at that point it's too late. The loss of > the > crash dump means the one shot at getting more information is gone. > > For reproducable crashes, yes, an end user could just flip the bit. But for > a > one-off, it's too late. Also, crashinfo is already enabled by default. If a user enables crash dumps in the installer, they will have a nice /var/crash/core.txt.N that they can post to the mailing lists just as easily as the text dump you envision. And in fact, I've seen our users already doing this. (Have you looked at a /var/crash/core.txt.N file yet?) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ddb_enable="YES" by default?
On Friday 05 September 2014 13:51:24 Craig Rodrigues wrote: > On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin wrote: > > Probably at least 50% of the time when I work with a user on a bug report, > > I ask them to go into kgdb and run specific commands to extract more > > detailed info (print some struct, etc.). > > Sure, I understand, but you are not working with every user who > encounters a kernel panic in FreeBSD. For the average or casual > FreeBSD user, such as desktop > users of FreeBSD or PC-BSD, wouldn't it be better > to have ddb_enable="YES" be the default in FreeBSD? The ddb script > there does a fairly reasonable > job of gathering some useful info which can be analyzed later, and > then rebooting the box. > > For more expert users, or people developing products, they can set > ddb_enable="NO" > and do more advanced debugging. Or hook into /etc/rc.d/ddb and define > a different > ddb script which doesn't do textdumps on kernel panic. I think what John was saying was at that point it's too late. The loss of the crash dump means the one shot at getting more information is gone. For reproducable crashes, yes, an end user could just flip the bit. But for a one-off, it's too late. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: ddb_enable="YES" by default?
On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin wrote: > > Probably at least 50% of the time when I work with a user on a bug report, > I ask them to go into kgdb and run specific commands to extract more detailed > info (print some struct, etc.). Sure, I understand, but you are not working with every user who encounters a kernel panic in FreeBSD. For the average or casual FreeBSD user, such as desktop users of FreeBSD or PC-BSD, wouldn't it be better to have ddb_enable="YES" be the default in FreeBSD? The ddb script there does a fairly reasonable job of gathering some useful info which can be analyzed later, and then rebooting the box. For more expert users, or people developing products, they can set ddb_enable="NO" and do more advanced debugging. Or hook into /etc/rc.d/ddb and define a different ddb script which doesn't do textdumps on kernel panic. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ddb_enable="YES" by default?
On Thursday, September 04, 2014 8:02:55 pm Craig Rodrigues wrote: > Brooks, > > In r178450, you set the default of ddb_enable to NO: > > > r178450 | brooks | 2008-04-23 15:40:59 -0700 (Wed, 23 Apr 2008) | 4 lines > Changed paths: >M /head/etc/defaults/rc.conf > > Revert rev 1.332 and keep ddb scripts off by default for now. Minidumps > are more flexable and much text-dump like output can be produced from > them so there's a good argument they are a better default. > > Index: head/etc/defaults/rc.conf > === > --- head/etc/defaults/rc.conf(revision 178449) > +++ head/etc/defaults/rc.conf(revision 178450) > @@ -33,7 +33,7 @@ > apm_enable="NO"# Set to YES to enable APM BIOS functions (or NO). > apmd_enable="NO"# Run apmd to handle APM event from userland. > apmd_flags=""# Flags to apmd (if enabled). > -ddb_enable="YES"# Load ddb scripts at boot. > +ddb_enable="NO"# Set to YES to load ddb scripts at boot. > ddb_config="/etc/ddb.conf"# ddb(8) config file. > devd_enable="YES" # Run devd, to trigger programs on device tree changes. > devd_flags=""# Additional flags for devd(8). > > > > Do you think this is OK to enable by default now? > Developers who know what they are doing can turn it off in /etc/rc.conf. > > For the average end-user, this is super useful, because > it loads the ddb rules in /etc/ddb.conf, which do > useful things like enable textdumps, show all the locks, show all the > locked vnodes, > and reboots the box. > > This will allow end-users who have a problem in the field with FreeBSD, > and are not kernel debugging experts, to get a lot of useful diagnostic > info that can be reported back to developers on the mailing lists. > > Right now, a lot of times, people take camera pictures of their screen at the > ddb prompt. That's pretty painful. :) Probably at least 50% of the time when I work with a user on a bug report, I ask them to go into kgdb and run specific commands to extract more detailed info (print some struct, etc.). You can'd do that with text dumps. All that info is thrown away when the machine reboots. OTOH, /var/crash/core.txt.N provides much of the same information automatically from a minidump (and I've seen users posting URLs to the file). You can also implement many of the more advanced ddb commands like 'show lockedvnodes' using gdb scripts against a minidump (see 'lockedvnodes' command in www.freebsd.org/~jhb/gdb/gdb6). In short, minidumps still provide far more information and can almost completely replicate the functionality of textdumps. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ddb_enable="YES" by default?
On Thu, Sep 04, 2014 at 05:02:55PM -0700, Craig Rodrigues wrote: > Brooks, > > In r178450, you set the default of ddb_enable to NO: > > > r178450 | brooks | 2008-04-23 15:40:59 -0700 (Wed, 23 Apr 2008) | 4 lines > Changed paths: >M /head/etc/defaults/rc.conf > > Revert rev 1.332 and keep ddb scripts off by default for now. Minidumps > are more flexable and much text-dump like output can be produced from > them so there's a good argument they are a better default. > > Index: head/etc/defaults/rc.conf > === > --- head/etc/defaults/rc.conf(revision 178449) > +++ head/etc/defaults/rc.conf(revision 178450) > @@ -33,7 +33,7 @@ > apm_enable="NO"# Set to YES to enable APM BIOS functions (or NO). > apmd_enable="NO"# Run apmd to handle APM event from userland. > apmd_flags=""# Flags to apmd (if enabled). > -ddb_enable="YES"# Load ddb scripts at boot. > +ddb_enable="NO"# Set to YES to load ddb scripts at boot. > ddb_config="/etc/ddb.conf"# ddb(8) config file. > devd_enable="YES" # Run devd, to trigger programs on device tree changes. > devd_flags=""# Additional flags for devd(8). > > > > Do you think this is OK to enable by default now? > Developers who know what they are doing can turn it off in /etc/rc.conf. > > For the average end-user, this is super useful, because > it loads the ddb rules in /etc/ddb.conf, which do > useful things like enable textdumps, show all the locks, show all the > locked vnodes, > and reboots the box. > > This will allow end-users who have a problem in the field with FreeBSD, > and are not kernel debugging experts, to get a lot of useful diagnostic > info that can be reported back to developers on the mailing lists. > > Right now, a lot of times, people take camera pictures of their screen at the > ddb prompt. That's pretty painful. :) IIRC John was the one who convinced me it was better to post process text dumps than to run potentially risky ddb scripts. I've cc'd him for his opinion. One way or another I belive we should default to producing a useful crash report even at the risk of filling /var. -- Brooks pgpA7K6pa2EH4.pgp Description: PGP signature
ddb_enable="YES" by default?
Brooks, In r178450, you set the default of ddb_enable to NO: r178450 | brooks | 2008-04-23 15:40:59 -0700 (Wed, 23 Apr 2008) | 4 lines Changed paths: M /head/etc/defaults/rc.conf Revert rev 1.332 and keep ddb scripts off by default for now. Minidumps are more flexable and much text-dump like output can be produced from them so there's a good argument they are a better default. Index: head/etc/defaults/rc.conf === --- head/etc/defaults/rc.conf(revision 178449) +++ head/etc/defaults/rc.conf(revision 178450) @@ -33,7 +33,7 @@ apm_enable="NO"# Set to YES to enable APM BIOS functions (or NO). apmd_enable="NO"# Run apmd to handle APM event from userland. apmd_flags=""# Flags to apmd (if enabled). -ddb_enable="YES"# Load ddb scripts at boot. +ddb_enable="NO"# Set to YES to load ddb scripts at boot. ddb_config="/etc/ddb.conf"# ddb(8) config file. devd_enable="YES" # Run devd, to trigger programs on device tree changes. devd_flags=""# Additional flags for devd(8). Do you think this is OK to enable by default now? Developers who know what they are doing can turn it off in /etc/rc.conf. For the average end-user, this is super useful, because it loads the ddb rules in /etc/ddb.conf, which do useful things like enable textdumps, show all the locks, show all the locked vnodes, and reboots the box. This will allow end-users who have a problem in the field with FreeBSD, and are not kernel debugging experts, to get a lot of useful diagnostic info that can be reported back to developers on the mailing lists. Right now, a lot of times, people take camera pictures of their screen at the ddb prompt. That's pretty painful. :) -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
