From ue@nathan.ruhr.de  Tue Jul 11 02:52:27 2000
Return-Path: <ue@nathan.ruhr.de>
Received: from mail.ruhr.de (in-ruhr2.ruhr.de [141.39.224.60])
	by hub.freebsd.org (Postfix) with SMTP id 826F137B5EF
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 11 Jul 2000 02:52:25 -0700 (PDT)
	(envelope-from ue@nathan.ruhr.de)
Received: (qmail 32730 invoked by alias); 11 Jul 2000 09:52:45 -0000
Received: (from ue@localhost)
	by nathan.ruhr.de (8.9.3/8.9.3) id LAA16205;
	Tue, 11 Jul 2000 11:36:49 +0200 (CEST)
	(envelope-from ue)
Message-Id: <200007110936.LAA16205@nathan.ruhr.de>
Date: Tue, 11 Jul 2000 11:36:49 +0200 (CEST)
From: Udo Erdelhoff <ue@nathan.ruhr.de>
Reply-To: ue@nathan.ruhr.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: dumpon(8) needs to be updated [patch]
X-Send-Pr-Version: 3.2

>Number:         19848
>Category:       docs
>Synopsis:       dumpon(8) needs to be updated [patch included]
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    ben
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 11 03:00:02 PDT 2000
>Closed-Date:    Fri Jul 14 18:59:41 BST 2000
>Last-Modified:  Fri Jul 14 19:10:55 BST 2000
>Originator:     Udo Erdelhoff
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:

FreeBSD 5.0-current as of 08-JUL-2000
src/sbin/dumpon/dumpon.8 v1.13

>Description:

The bugs section of dumpon(8) states:

     Dumpon currently allows only devices with minor number 1 to be used as
     dump devices.

This is obviously no longer true. Various messages on the mailing lists
show that people have been dumping to /dev/da0s1b (minor 0x20001) with
good effect. 

The bugs section does not mention that setting DUMPDEV in rc.conf causes
dumpon to be called during the transition from single-user to multi-user.
This means that it's close to impossible to capture dumps caused by
problem during boot. There was a discussion on -current about this
problem in March 2000 (see revision 1.12 of this file). The problem
has not been resolved yet (AFAIK), so bugs should warn about it.

Additionally, a part of the notes section should be changed.

Old version:
One of the system swap devices is usually chosen as the dump device, as
swap devices are the most likely to have the required space at dump time.

New version:
One of the system swap devices should be used as the dump device.  Devices
used for regular filesystems will probably lack sufficent space to store the    
dump.

[And that's the polite version - I was tempted to write to something
to the effect of "using anything but a swap device is suicidal"]

>How-To-Repeat:

man 8 dumpon 
dumpon /dev/any-swap-device
put DUMPEV=above-device in rc.conf
panic the system, reboot 
=> core is saved in /var/crash

>Fix:

The patch implements the changes outlined above. The changes should be
MFCed to RELENG_4 before 4.1-RELEASE.

Index: dumpon.8
===================================================================
RCS file: /home/ncvs/src/sbin/dumpon/dumpon.8,v
retrieving revision 1.13
diff -u -r1.13 dumpon.8
--- dumpon.8	2000/03/28 15:54:32	1.13
+++ dumpon.8	2000/07/11 09:10:57
@@ -68,8 +68,9 @@
 .Nm
 to be verbose about its activity.
 .Sh NOTES
-One of the system swap devices is usually chosen as the dump device, as
-swap devices are the most likely to have the required space at dump time.
+One of the system swap devices should be used as the dump device.  Devices
+used for regular filesystems will probably lack sufficent space to store the
+dump.
 .Pp
 The 
 .Nm
@@ -106,9 +107,13 @@
 Because the filesystem layer is already dead by the time a crash dump
 is taken, it is not possible to send crash dumps directly to a file.
 .Pp
-.Nm Dumpon
-currently allows only devices with minor number 1 to be used as dump 
-devices.
+Since
+.Nm dumpon
+is called from 
+.Pa /etc/rc ,
+system panics during kernel initialisation or single-user mode will NOT
+cause a dump.  Currently, there is no safe or reliable way to enforce
+the creation of dumps in these cases.
 .Sh HISTORY
 The
 .Nm

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->ben 
Responsible-Changed-By: ben 
Responsible-Changed-When: Thu Jul 13 13:16:05 BST 2000 
Responsible-Changed-Why:  
I'll commit this tonight. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19848 
State-Changed-From-To: open->closed 
State-Changed-By: ben 
State-Changed-When: Fri Jul 14 18:59:41 BST 2000 
State-Changed-Why:  
Committed in -current and 4-stable, thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19848 
>Unformatted:
