From nobody@FreeBSD.org  Fri Sep 17 18:03:56 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 53B5816A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Sep 2004 18:03:56 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2CF3143D48
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Sep 2004 18:03:56 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i8HI3teJ004765
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Sep 2004 18:03:55 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.11/8.12.11/Submit) id i8HI3tLa004764;
	Fri, 17 Sep 2004 18:03:55 GMT
	(envelope-from nobody)
Message-Id: <200409171803.i8HI3tLa004764@www.freebsd.org>
Date: Fri, 17 Sep 2004 18:03:55 GMT
From: David Kelly <dkelly@hiwaay.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: start_vinum="YES" panics 5.3-BETA4 on boot
X-Send-Pr-Version: www-2.3

>Number:         71824
>Category:       kern
>Synopsis:       start_vinum="YES" panics 5.3-BETA4 on boot
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    le
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 17 18:10:37 GMT 2004
>Closed-Date:    Sat Nov 06 15:27:14 GMT 2004
>Last-Modified:  Sat Nov 06 15:27:14 GMT 2004
>Originator:     David Kelly
>Release:        5.3-BETA4
>Organization:
>Environment:
FreeBSD Opus.home 5.3-BETA4 FreeBSD 5.3-BETA4 #0: Thu Sep 16 19:53:35 CDT 2004     dkelly@Opus.home:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
Attempts to autostart vinum at boot cause kernel panic after 1 second of uptime. Last things displayed before freezing are:

vinum: loaded
panic: unmount: dangling vnode
cpuid = 0
uptime: 1s

Vinum volume was created with "vinum stripe -v /dev/ad4s1d /dev/ad6s1d" originally in 5.2.1.

Can't make it not reproduce this problem in 5.3-BETA. Previously worked in 5.2.1-p9 but not totally without issues. In p9 vinum often did not remember at boot that the vinum drives were to be striped but did remember. Had to boot single user and repeat the above command to restore that information and create /dev/vinum/vinum0.

Due to this problem I'm currently running a totally stock GENERIC.

# vinum printconfig
# Vinum configuration of Opus.home, saved at Fri Sep 17 12:59:44 2004
drive vinumdrive1 device /dev/ad6s1d
drive vinumdrive0 device /dev/ad4s1d
volume vinum0
plex name vinum0.p0 org striped 558s vol vinum0 
sd name vinum0.p0.s0 drive vinumdrive0 plex vinum0.p0 len 319571622s driveoffset 265s plexoffset 0s
sd name vinum0.p0.s1 drive vinumdrive1 plex vinum0.p0 len 319571622s driveoffset 265s plexoffset 558s

>How-To-Repeat:
Machine is a Dell Power Edge 400SC, P4-2.8G-512k, HT disabled. MB is Intel 875 based. The problem vinum drives are on SATA interfaces. System boot drive is PATA. The s1b partition on each drive is used as swap.

I always have this problem if vinum is started from /etc/rc.conf. Doesn't matter if vinum is loaded in /boot/loader.conf or not.
>Fix:
Boot single user. Manually mount filesystems. Manually run "vinum start" and then mount that one too.

Sometimes (less often than in 5.2.1) vinum forgets its configuration and the "vinum stripe" command above has to be reapplied.

A bit cleaner solution has been to comment out the vinum start in /etc/rc.conf and remove the fs entry from /etc/fstab. System boots cleanly to multiuser. Then "vinum start" works, and "mount /dev/vinum/vinum0 /usr5" finishes the task.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->le 
Responsible-Changed-By: le 
Responsible-Changed-When: Sat Sep 18 12:58:20 GMT 2004 
Responsible-Changed-Why:  
Grab another vinum PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71824 

From: David Kelly <dkelly@HiWAAY.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/71824: start_vinum="YES" panics 5.3-BETA4 on boot
Date: Sat, 18 Sep 2004 20:40:19 -0500

 Noticed some diffs come thru on /usr/src/sys/ so I built a kernel that 
 now calls itself 5.3-BETA5. Essentially the same results.
 
 Don't hold this to be absolutely exactly perfect as I'm having to type 
 it from one place to another. Hoping this will give some idea as to 
 where its happening:
 
 (bright text)
 ...
 ad0: 117899MB <IC35L120AVV207-V240A63A> [239340/16/63] at ata0-master 
 UDMA100
 ATAPI_RESET time = 40us
 acd0: CDROM <model number> at ata1-master UDMA33
 ad4: 157066MB <HDS722516VLSA80/V340A60A> [319120/16/63] at ata2-master 
 SATA150
 ad6: 157066MB <HDS722516VLSA80/V340A60A> [319120/16/63] at ata2-master 
 SATA150
 vinum: loaded
 Mounting root from ufs:/dev/ad0s1a
 (dim text starts)
 Pre-seeding PRNG: kickstart.
 Loading configuration files.
 Entropy harvesting: interrupts ethernet point-to-point kickstart.
 (bright text resumes)
 panic: unmount: dangling vnode
 cpuid = 0
 Uptime: 2s
 
 As mentioned previously the vinum volume is on /dev/ad[46]s1d and was 
 created with "vinum stripe -v /dev/ad4s1d /dev/ad6s1d"
 
 If the system panics on vinum as shown above, on restart when 
 start_vinum is removed from /etc/rc.conf I have to re-enter the vinum 
 stripe command as vinum has forgotten its configuration.
 
 The best way I've found to start the system is without start_vinum in 
 /etc/rc.conf, let it fail on /dev/vinum/vinum0 in /etc/fstab and drop 
 into single-user. Then type "vinum start" and "exit". For some reason 
 the start of vinum needs to be delayed.
 
 Doesn't seem to matter whether vinum_load="YES" is in /boot/loader.conf 
 or not. Vinum_load was in loader.conf for the above boot text output.
 
 What wasn't working just now was to boot directly into single user and 
 manually start vinum. That too was panicking just now. It used to work. 
 Haven't tried enough variations to say this panic was because vinum had 
 lost its configuration, or whether vinum lost its configuration because 
 of this (or previous) panics.
 

From: Feczak Szabolcs <feczo@siodigit.hu>
To: freebsd-gnats-submit@FreeBSD.org, dkelly@hiwaay.net
Cc:  
Subject: Re: kern/71824: start_vinum="YES" panics 5.3-BETA4 on boot
Date: Mon, 04 Oct 2004 18:53:02 +0200

 This is a known problem with "classic" vinum. You need / mounted when
 starting vinum or else you get the panic. If you switch to gvinum instead
 your problem should go away (but beware that the control program for gvinum
 still lacks a lot of functionality).
 
 What you need to do to switch:
 
 * Remove start_vinum="YES" from /etc/rc.conf.
 * Add geom_vinum_load="YES" to /boot/loader.conf
 * Change /dev/vinum/* to /dev/gvinum/* in /etc/fstab
 * Reboot
 
 info was published at :
 
 http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035547.html
 
 by Daniel Eriksson
 

From: Feczak Szabolcs <feczo@siodigit.hu>
To: freebsd-gnats-submit@FreeBSD.org
Cc: dkelly@hiwaay.net
Subject: Re: kern/71824: start_vinum="YES" panics 5.3-BETA4 on boot
Date: Mon, 04 Oct 2004 19:02:18 +0200

 This seems to work better:
 
 
 In /etc/rc.d/vinum, change
 start_cmd="vinum start"
 to
 start_cmd="gvinum start"
 
 Change /dev/vinum/* to /dev/gvinum/* in /etc/fstab
 
 
 info published at
 
 http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035574.html
 
 by Jens
 
 
 

From: "David Kelly" <dkelly@hiwaay.net>
To: <freebsd-gnats-submit@FreeBSD.org>, <dkelly@hiwaay.net>
Cc:  
Subject: Re: kern/71824: start_vinum="YES" panics 5.3-BETA4 on boot
Date: Wed, 3 Nov 2004 10:07:48 -0600 (CST)

 Lets close this PR as gvinum solved the two issues which prompted me to
 open the PR. No more panic on boot. Also gvinum has always remembered its
 prior configuration after boot.
 
 It would be nice if the vinum(8) manpage said something about gvinum.
 Mention known issues such as how changes elsewhere to support geom
 sometimes break vinum (such as panic when root isn't mounted). Suggest
 gvinum and mention what shortcomings and/or features it may have or lack.
 
 
State-Changed-From-To: open->closed 
State-Changed-By: le 
State-Changed-When: Sat Nov 6 15:27:01 GMT 2004 
State-Changed-Why:  
Closed on submitter's request. 

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