From nobody@FreeBSD.ORG Wed Oct 13 13:22:15 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 377A715337; Wed, 13 Oct 1999 13:22:15 -0700 (PDT)
Message-Id: <19991013202215.377A715337@hub.freebsd.org>
Date: Wed, 13 Oct 1999 13:22:15 -0700 (PDT)
From: gritton@iserver.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: Panic in vinum with MFS root and single processor
X-Send-Pr-Version: www-1.0

>Number:         14310
>Category:       kern
>Synopsis:       Panic in vinum with MFS root and single processor
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 13 13:30:01 PDT 1999
>Closed-Date:    Wed Oct 13 17:00:28 PDT 1999
>Last-Modified:  Thu Sep 13 12:44:15 GMT 2007
>Originator:     James Gritton
>Release:        3.3
>Organization:
Verio Web Hosting
>Environment:
FreeBSD  3.3-RELEASE FreeBSD 3.3-RELEASE #2: Wed Oct 13 14:05:30 MDT 1999     root@fc:/usr/src/sys/compile/VKERN  i386

>Description:
The system panics while running "vinum start" out of /etc/rc, apparently
when updating the vinum configuration (the last console output before
the panic is "vinum: updating configuration from /dev/da0b").  This only
happens when running from an MFS root filesystem, and only for single
processor systems (either one processor in hardware or a dual processor
system without SMP defined in the kernel will panic.  A dual processor
system with SMP defined will work).  The panic message is:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x10
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc02ae313
stack pointer           = 0x10:0xc9457c44
frame pointer           = 0x10:0xc9457c98
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 18 (vinum)
interrupt mask          = 
trap number             = 12
panic: page fault


where 0xc02ae313 is past the end of the kernel address space, presumably
in the vinum module.
>How-To-Repeat:
Create an MFS root filesystem and a generic kernel, both with unused
bits stripped out to save space.  On a system with vinum partitions
(for e.g. /usr), load the kernel, vinum.ko, and the MFS root out of the
loader and boot single user.  A "vinum start" will cause the panic.
>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->		closed 
State-Changed-By: grog 
State-Changed-When: Wed Oct 13 17:00:28 PDT 1999 
State-Changed-Why:  
es 
Problem has already been fixed. 


Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: grog 
Responsible-Changed-When: Wed Oct 13 17:00:28 PDT 1999 
Responsible-Changed-Why:  
grog maintains Vinum. 
>Unformatted:

Greg Lehey, 14 October 1999

	When submitting PRs about Vinum, please read vinum(4), which
	describes the information you need to supply.  The trap
	information is not enough.  You can find the same information
	at http://www.lemis.com/vinum/how-to-debug.html.

	You should also first check the known bugs list at
	http://www.lemis.com/vinum/bugs.html.
	There you could read:

	28 September 1999: If you don't have all device nodes, 'vinum
	start' may panic the machine.  In particular, if the
	/dev/da0s1a devices are missing, we have seen panics.

	Technical explanation: The function vinum_scandisk was trying
	to read from a drive which had been invalidated. This caused a
	null pointer dereference.

	Status: Fixed in 4.0-CURRENT (file vinumio.c, revision 1.45)
	and 3.3-STABLE (file vinumio.c, revision 1.7.2.11).
