From pawmal@unia.3lo.lublin.pl  Tue Jun  3 15:35:59 2003
Return-Path: <pawmal@unia.3lo.lublin.pl>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id AE19E37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  3 Jun 2003 15:35:59 -0700 (PDT)
Received: from unia.3lo.lublin.pl (unia.3lo.lublin.pl [212.182.70.2])
	by mx1.FreeBSD.org (Postfix) with SMTP id 7BF7543F75
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  3 Jun 2003 15:35:58 -0700 (PDT)
	(envelope-from pawmal@unia.3lo.lublin.pl)
Received: (qmail 85578 invoked by uid 1007); 3 Jun 2003 22:39:16 -0000
Message-Id: <20030603223916.85577.qmail@unia.3lo.lublin.pl>
Date: 3 Jun 2003 22:39:16 -0000
From: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Reply-To: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: vinum causes panic after start/stop/... cycle, easy to reproduce
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         52916
>Category:       kern
>Synopsis:       [vinum] vinum causes panic after start/stop/... cycle, easy to reproduce
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    le
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 03 15:40:06 PDT 2003
>Closed-Date:    Sat Nov 26 15:21:43 GMT 2005
>Last-Modified:  Sat Nov 26 15:21:43 GMT 2005
>Originator:     Pawe Maachowski
>Release:        FreeBSD 4.8-STABLE i386
>Organization:
ZiN
>Environment:
FreeBSD  4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Apr  3 10:53:38 GMT 2003
root@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC  i386

	
>Description:
Both 4.8-RELEASE and fresh 4.8-STABLE (on two different machines) catch
kernel panic when I try something like:
vinum start;vinum stop;vinum start;vinum stop;vinum start;vinum stop

It is very easy to reproduce.

4.8-STABLE was compiled with debug symbols, unfortunately there is no
crashdump. Panic message from 4.8-STABLE (vinum as kld):

vinum: loaded
vinum: no drives found
vinum: unloaded
vinum: loaded
vinum: no drives found
vinum: unloaded
vinum: loaded


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xb7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01bedc8
stack pointer           = 0x10:0xd5749dc4
frame pointer           = 0x10:0xd5749dd8
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         = 107 (syslogd)
interrupt mask          = none
trap number             = 12
panic: page fault

syncing disks...

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xb7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01bedc8
stack pointer           = 0x10:0xd5749b04
frame pointer           = 0x10:0xd5749b18
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         = 107 (syslogd)
interrupt mask          = bio
trap number             = 12
panic: page fault
Uptime: 1m6s


So I compiled vinum statically into kernel,

# vinum start;vinum stop;vinum start;vinum stop;
** no drives found: No such file or directory
Can't unload vinum: No such file or directory
** no drives found: No such file or directory
Can't unload vinum: No such file or directory

and it crashed again with message like this:

vinum: no drives found
vinum: no drives found


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xb7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01cc204
stack pointer           = 0x10:0xd51e0e6c
frame pointer           = 0x10:0xd51e0e80
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         = 6 (syncer)
interrupt mask          = bio
trap number             = 12
panic: page fault

	
>How-To-Repeat:
Install minimal 4.8-RELEASE from ISO, type:
vinum start;vinum stop;vinum start;vinum stop;vinum start;vinum stop;
few times.

Note, creating vinum objects is not necessary!

Also note:
kldload vinum;kldunload vinum;kldload vinum;kldunload vinum;
doesn't produce panic on my machine.

I caught first panic when I tried `vinum stop' while reviving subdisk
(however, vinum was loaded/unloaded few times earlier cause configuration
was obliterated).

	
>Fix:
Unknown.
	


>Release-Note:
>Audit-Trail:

From: =?iso-8859-2?Q?Micha=B3?= Pasternak <michal@pasternak.w.lub.pl>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Wed, 4 Jun 2003 01:05:08 +0200

 FreeBSD 4-STABLE, same things happens here (I don't have vinum, just
 starting/stopping it a few times causes my machine to reboot
 without leaving a single line in logs)
 
 -- 
 Micha Pasternak :: http://pasternak.w.lub.pl
 $ mv /Almo /var  :: miejsce na  Twoja reklame

From: Greg 'groggy' Lehey <grog@FreeBSD.org>
To: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Wed, 4 Jun 2003 16:57:26 +0930

 --L4xCDQ7GT+ph8Lmk
 Content-Type: text/plain; charset=iso-8859-1
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tuesday,  3 June 2003 at 22:39:16 -0000, Pawel Malachowski wrote:
 >
 >> Number:         52916
 >> Category:       kern
 >> Synopsis:       vinum causes panic after start/stop/... cycle, easy to r=
 eproduce
 >> Confidential:   no
 >> Severity:       critical
 >> Priority:       high
 >> Responsible:    freebsd-bugs
 >> State:          open
 >> Quarter:
 >> Keywords:
 >> Date-Required:
 >> Class:          sw-bug
 >> Submitter-Id:   current-users
 >> Arrival-Date:   Tue Jun 03 15:40:06 PDT 2003
 >> Closed-Date:
 >> Last-Modified:
 >> Originator:     Pawe=B3 Ma=B3achowski
 >> Release:        FreeBSD 4.8-STABLE i386
 >> Organization:
 > ZiN
 >> Environment:
 > FreeBSD  4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Apr  3 10:53:38 GMT 2003
 > root@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC  i386
 >
 >
 >> Description:
 > Both 4.8-RELEASE and fresh 4.8-STABLE (on two different machines) catch
 > kernel panic when I try something like:
 > vinum start;vinum stop;vinum start;vinum stop;vinum start;vinum stop
 >
 > It is very easy to reproduce.
 
 I was not able to reproduce it.
 
 > 4.8-STABLE was compiled with debug symbols, unfortunately there is
 > no crashdump.
 
 What's the problem?  Do you have crash dumps enabled?
 
 > Panic message from 4.8-STABLE (vinum as kld):
 >
 > vinum: loaded
 > vinum: no drives found
 > vinum: unloaded
 > vinum: loaded
 > vinum: no drives found
 > vinum: unloaded
 > vinum: loaded
 >
 >
 > Fatal trap 12: page fault while in kernel mode
 
 Sorry, this doesn't help at all.  At the very least I'd need to know
 what the EIP address was.
 
 
 > fault virtual address   =3D 0xb7
 > fault code              =3D supervisor read, page not present
 > instruction pointer     =3D 0x8:0xc01bedc8
 
 This one.
 
 > So I compiled vinum statically into kernel,
 >
 > # vinum start;vinum stop;vinum start;vinum stop;
 > ** no drives found: No such file or directory
 > Can't unload vinum: No such file or directory
 > ** no drives found: No such file or directory
 > Can't unload vinum: No such file or directory
 >
 > and it crashed again with message like this:
 >
 > vinum: no drives found
 > vinum: no drives found
 
 You shouldn't be able to stop Vinum with a statically compiled module.
 
 > Also note:
 > kldload vinum;kldunload vinum;kldload vinum;kldunload vinum;
 > doesn't produce panic on my machine.
 
 That's something, I suppose.
 
 > I caught first panic when I tried `vinum stop' while reviving
 > subdisk
 
 I assume this is something else.
 
 I'd really like to find out what's happening here; we have two
 separate reports of a bug I haven't seen before, but I can't reproduce
 it here, neither with 4.7-RELEASE nor with the current 4.8-STABLE.
 Any further information would be welcome.
 
 Greg
 --
 See complete headers for address and phone numbers
 
 --L4xCDQ7GT+ph8Lmk
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.0 (FreeBSD)
 
 iD8DBQE+3Z9eIubykFB6QiMRAtO0AJwOhVFbjS8nNxFEf3n16qf87B7ZhwCeK/b+
 YWYdOtlHzheJYPswiForaqs=
 =V5qj
 -----END PGP SIGNATURE-----
 
 --L4xCDQ7GT+ph8Lmk--

From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
To: Greg 'groggy' Lehey <grog@FreeBSD.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Wed, 04 Jun 2003 21:00:24 +0200

 On 4 Jun 2003 at 16:57, Greg 'groggy' Lehey wrote:
 
 > >> Description:
 > > Both 4.8-RELEASE and fresh 4.8-STABLE (on two different machines) catch
 > > kernel panic when I try something like:
 > > vinum start;vinum stop;vinum start;vinum stop;vinum start;vinum stop
 > >
 > > It is very easy to reproduce.
 > 
 > I was not able to reproduce it.
 
 I've published this script on Polish FreeBSD users group, people confirm
 their machines are crashing too (about 20-60 start/stop cycles):
 
 #!/bin/sh
 i=1
 while [ 1 ]
 do
   echo Trying $i
   vinum start
   vinum stop
   i=$(($i + 1))
 done
 
 
 > > 4.8-STABLE was compiled with debug symbols, unfortunately there is
 > > no crashdump.
 > 
 > What's the problem?  Do you have crash dumps enabled?
 
 Yes.
 
 % grep dump /etc/rc.conf
 dumpdev="/dev/ad0s2b"
 % swapinfo
 Device          1K-blocks     Used    Avail Capacity  Type
 /dev/ad0s2b       1048448        0  1048448     0%    Interleaved
 % sysctl kern.dumpdev
 kern.dumpdev: { major = 116, minor = 0x30001 }
 
 Swap is big enough.
 
 > > Fatal trap 12: page fault while in kernel mode
 > 
 > Sorry, this doesn't help at all.  At the very least I'd need to know
 > what the EIP address was.
 > 
 > 
 > > fault virtual address   = 0xb7
 > > fault code              = supervisor read, page not present
 > > instruction pointer     = 0x8:0xc01bedc8
 > 
 > This one.
 
 This was sent earlier for private, I'm adding to audit trail.
 (Obtained from machine with DDB, copied `by hand'):
 
 fatal trap 12: page fault while in kernel mode
 fault virtual address	= 0x3edde192
 fault code		= supervisor read, page not present
 instruction pointer	= 0x8: 0xc02248b4
 stack pointer		= 0x10:0xe194adc4
 frame pointer		= 0x10:0xe194add8
 code segment		= base 0x0, limit 0xfffff, type 0x1b,
 			  DPL 0, press 1, def 321, gran 1
 proccessor eflags	= interrupt enabled, resume, IOPL=0
 current process	= 61 (syslogd)
 interrupt mask		= none
 kernel type 12 trap, code=0
 stopped ad dscheck+0x104 movl 0xb8(%esi),%edx
 
 `x $eip' shows dscheck+0x104 b8968b
 
 > > So I compiled vinum statically into kernel,
 > >
 > > # vinum start;vinum stop;vinum start;vinum stop;
 > > ** no drives found: No such file or directory
 > > Can't unload vinum: No such file or directory
 > > ** no drives found: No such file or directory
 > > Can't unload vinum: No such file or directory
 > >
 > > and it crashed again with message like this:
 > >
 > > vinum: no drives found
 > > vinum: no drives found
 > 
 > You shouldn't be able to stop Vinum with a statically compiled module.
 
 Of course, but I'm able to produce a panic this way, that's why it
 is so interesting. :)
 
 
 -- 
 Pawe Maachowski
 

From: Greg 'groggy' Lehey <grog@FreeBSD.org>
To: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Fri, 6 Jun 2003 14:52:05 +0930

 --lrZ03NoBR/3+SXJZ
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wednesday,  4 June 2003 at 21:00:24 +0200, Pawel Malachowski wrote:
 > On 4 Jun 2003 at 16:57, Greg 'groggy' Lehey wrote:
 >
 >>>> Description:
 >>> Both 4.8-RELEASE and fresh 4.8-STABLE (on two different machines) catch
 >>> kernel panic when I try something like:
 >>> vinum start;vinum stop;vinum start;vinum stop;vinum start;vinum stop
 >>>
 >>> It is very easy to reproduce.
 >>
 >> I was not able to reproduce it.
 >
 > I've published this script on Polish FreeBSD users group, people confirm
 > their machines are crashing too (about 20-60 start/stop cycles):
 >
 >
 >>> 4.8-STABLE was compiled with debug symbols, unfortunately there is
 >>> no crashdump.
 >>
 >> What's the problem?  Do you have crash dumps enabled?
 >
 > Yes.
 >
 >> grep dump /etc/rc.conf
 > dumpdev=3D"/dev/ad0s2b"
 >> swapinfo
 > Device          1K-blocks     Used    Avail Capacity  Type
 > /dev/ad0s2b       1048448        0  1048448     0%    Interleaved
 >> sysctl kern.dumpdev
 > kern.dumpdev: { major =3D 116, minor =3D 0x30001 }
 >
 > Swap is big enough.
 
 Hmm. =20
 
 >>> fault virtual address   =3D 0xb7
 >>> fault code              =3D supervisor read, page not present
 >>> instruction pointer     =3D 0x8:0xc01bedc8
 >>
 >> This one.
 >
 > `x $eip' shows dscheck+0x104 b8968b
 
 OK, this might give us a clue.
 
 >>> So I compiled vinum statically into kernel,
 >>>
 >>> # vinum start;vinum stop;vinum start;vinum stop;
 >>> ** no drives found: No such file or directory
 >>> Can't unload vinum: No such file or directory
 >>> ** no drives found: No such file or directory
 >>> Can't unload vinum: No such file or directory
 >>>
 >>> and it crashed again with message like this:
 >>>
 >>> vinum: no drives found
 >>> vinum: no drives found
 
 No, that's not a crash message.  That's normal.
 
 I'm guessing this has something to do with md devices.  Do you use
 any?  I don't, and every 'vinum start' created one.  I've committed a
 fix to vinum(8) (revision 1.31.2.6 of src/sbin/vinum/commands.c).
 Please try it and tell me if it fixes the problem.  Here it is again
 to save you cvsupping:
 
 diff -w -u -r1.31.2.5 commands.c
 --- commands.c  4 May 2002 05:04:14 -0000       1.31.2.5
 +++ commands.c  6 Jun 2003 05:08:43 -0000
 @@ -275,6 +275,10 @@
      char reply[32];
      int error;
 =20
 +    if (! isatty (STDIN_FILENO)) {
 +       fprintf (stderr, "Please enter this command from a tty device\n");
 +       return;
 +    }
      printf(" WARNING!  This command will completely wipe out your vinum co=
 nfiguration.\n"
         " All data will be lost.  If you really want to do this, enter the =
 text\n\n"
         " NO FUTURE\n"
 @@ -544,6 +548,7 @@
 =20
             if ((((stat->device_type & DEVSTAT_TYPE_MASK) =3D=3D DEVSTAT_TY=
 PE_DIRECT) /* disk device */
                  || ((stat->device_type & DEVSTAT_TYPE_MASK) =3D=3D DEVSTAT=
 _TYPE_STORARRAY)) /* storage array */
 +           &&((stat->device_type & DEVSTAT_TYPE_IF_MASK) !=3D DEVSTAT_TYPE=
 _IF_OTHER) /* and not md */
             &&((stat->device_type & DEVSTAT_TYPE_PASS) =3D=3D 0) /* and not=
  passthrough */
             &&((stat->device_name[0] !=3D '\0'))) {           /* and it has=
  a name */
                 sprintf(enamelist, "%s%s%d", _PATH_DEV, stat->device_name, =
 stat->unit_number);
 
 
 Greg
 --
 See complete headers for address and phone numbers
 
 --lrZ03NoBR/3+SXJZ
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.0 (FreeBSD)
 
 iD8DBQE+4CT9IubykFB6QiMRAtPeAKCYfaIlE20BClGuEIU3Jg5b/wszKgCeMlB1
 HMmTlyd/mnfnY4Jlqnt82rc=
 =pmOV
 -----END PGP SIGNATURE-----
 
 --lrZ03NoBR/3+SXJZ--

From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
To: Greg 'groggy' Lehey <grog@FreeBSD.org>
Cc: Freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Mon, 23 Jun 2003 23:40:36 +0200

 On 6 Jun 2003 at 14:52, Greg 'groggy' Lehey wrote:
 
 > I'm guessing this has something to do with md devices.  Do you use
 > any?  I don't, and every 'vinum start' created one.  I've committed a
 > fix to vinum(8) (revision 1.31.2.6 of src/sbin/vinum/commands.c).
 > Please try it and tell me if it fixes the problem.
 
 Problem appears when we call (f)sync() while `vinum start' command is working.
 After killing syslogd (which was using fsync(), I have both /var/log and /dev
 on / fs with SoftUpdates enabled), stability increased.
 
 I was running /bin/sync frequently during vinum start/stop loop and sometimes I
 can see `rm' (and other commands called from make_devices(), src/sbin/vinum/v.c)
 complaining it was not possible to remove/recreate device files in /dev/vinum.
 Panic happened within few seconds.
 
 
 -- 
 Pawe Maachowski
 
 

From: Greg 'groggy' Lehey <grog@FreeBSD.org>
To: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Cc: Freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Tue, 24 Jun 2003 07:52:35 +0930

 --fRqxu2t+6O910vVH
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Monday, 23 June 2003 at 23:40:36 +0200, Pawel Malachowski wrote:
 > On 6 Jun 2003 at 14:52, Greg 'groggy' Lehey wrote:
 >
 >> I'm guessing this has something to do with md devices.  Do you use
 >> any?  I don't, and every 'vinum start' created one.  I've committed a
 >> fix to vinum(8) (revision 1.31.2.6 of src/sbin/vinum/commands.c).
 >> Please try it and tell me if it fixes the problem.
 >
 > Problem appears when we call (f)sync() while `vinum start' command is working.
 > After killing syslogd (which was using fsync(), I have both /var/log and /dev
 > on / fs with SoftUpdates enabled), stability increased.
 >
 > I was running /bin/sync frequently during vinum start/stop loop and sometimes I
 > can see `rm' (and other commands called from make_devices(), src/sbin/vinum/v.c)
 > complaining it was not possible to remove/recreate device files in /dev/vinum.
 > Panic happened within few seconds.
 
 I'd appreciate answers to my questions.  Also a backtrace would help.
 
 Greg
 --
 See complete headers for address and phone numbers
 
 --fRqxu2t+6O910vVH
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.0 (FreeBSD)
 
 iD8DBQE+932rIubykFB6QiMRAvJGAJ4jWOMeTnptkF2MSO0Zx3mtOdZWEgCfXJPI
 oVQLrEW0qedWFi22JXRhd4g=
 =RXj2
 -----END PGP SIGNATURE-----
 
 --fRqxu2t+6O910vVH--

From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
To: Greg 'groggy' Lehey <grog@FreeBSD.org>
Cc: Freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Tue, 24 Jun 2003 00:43:54 +0200

 On 24 Jun 2003 at 7:52, Greg 'groggy' Lehey wrote:
 
 > I'd appreciate answers to my questions.  Also a backtrace would help.
 
 This was from 9 Jun 2003:
 
 dscheck(cf703f08,c31a5f00) at dscheck+0x104
 diskstrategy(cf703f08,c2f79d80,1,e194ae3c) at diskstrategy+0x7d
 spec_strategy(e194ae20,cf703f08,1,0,c041a6e0) at spec_strategy+0x8c
 ufs_strategy(e194ae64,e194ae70,c0240606,e194ae64,cf703f08) at ufs_strategy+0xc5
 ufs_vnoperate(e194ae64) at ufs_vnoperate+0x15
 bwrite(cf703f08,e194ae88,c024e4d,e194aea0,e194ae94) at bwrite+0x20a
 vop_stdwrite(e194aea0,e194ae94,c032ff61,e194aea0,e194aeac) at vop_stdwrite+0xe
 vop_defaultop(e194aea0,e194aeac,c0240956,e194aea0,c041a920) at vop_defaultop+0x15
 ufs_vnoperate(e194aea0,c041a920,e1953300,cf703f08,e194aee8) at ufs_vnoperate+0x15
 bawrite(cf703f08,0,cf703f08,e1953300,0) at bawrite+0x32
 ffs_fsync(e194af08,da0baf60,1,e194af80,c04887c0) at ffs_fsync+0x1e2
 fsync(da0baf60,e194af80,8053800,bfbfede8,8054cd5) at fsync+0xa8
 syscall2(2f2f2f,8054cd5,bfbfede8) at syscall2+0x1f5
 Xint0x80_syscall() at Xint0x80_syscall+0x25
 
 Will provide fresh one tommorow. What would You like to know? I'll try to answer.
 
 
 -- 
 Pawe Maachowski
 
 

From: Greg 'groggy' Lehey <grog@FreeBSD.org>
To: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Cc: Freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Tue, 24 Jun 2003 08:33:44 +0930

 --E1gTK3gVkNSK8zyC
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Tuesday, 24 June 2003 at  0:43:54 +0200, Pawel Malachowski wrote:
 > On 24 Jun 2003 at 7:52, Greg 'groggy' Lehey wrote:
 >
 >> I'd appreciate answers to my questions.  Also a backtrace would help.
 >
 > This was from 9 Jun 2003:
 
 Thanks.
 
 > Will provide fresh one tommorow. What would You like to know? I'll
 > try to answer.
 
 It's described in http://www.vinumvm.org/vinum/how-to-debug.html and
 the man page.  In particular, I need a gdb backtrace, not a ddb
 backtrace.  But if it looks the same, keep the dump and I'll look at
 it (or get you to look at it) when I know what I'm looking for.
 
 I'm still waiting for the answers to my questions.
 
 Greg
 --
 See complete headers for address and phone numbers
 
 --E1gTK3gVkNSK8zyC
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.0 (FreeBSD)
 
 iD8DBQE+94dQIubykFB6QiMRAqHqAJ415k3venaBBgf8sX1K1iLVw5ZqnwCfZY+x
 hUUv2fEcD6T9+hqnMbmMXLM=
 =amjq
 -----END PGP SIGNATURE-----
 
 --E1gTK3gVkNSK8zyC--

From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
To: Greg 'groggy' Lehey <grog@FreeBSD.org>
Cc: Freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Tue, 24 Jun 2003 20:25:23 +0200

 On 24 Jun 2003 at 8:33, Greg 'groggy' Lehey wrote:
 
 >         [...] In particular, I need a gdb backtrace, not a ddb
 > backtrace.  But if it looks the same, keep the dump and I'll look at
 > it (or get you to look at it) when I know what I'm looking for.
 
 As I said before, there was no crashdump.
 System tries do dump after first panic but fails with second panic.
 
 However, I discovered that when I change dumpdev from /dev/da0s1b
 to /dev/da1s1b (second, unused disk), dumping can be done with
 success.
 
 I've installed fresh 4.8-RELEASE from CD, updated kernel and userland
 do todays 4.8-STABLE. Also vinum resetconfig was done to remove previous
 configuration from second hard drive.
 # vinum list
 0 drives:
 0 volumes:
 0 plexes:
 0 subdisks:
 
 GENERIC kernel was used with the following additions:
 makeoptions     DEBUG=-g 
 pseudo-device   vinum
 options         VINUMDEBUG
 
 
 The following vinum-test.sh was used:
 
 #!/bin/sh
 i=1
 while [ 1 ]
 do
   echo Start $i
   (sync;sync;sync;sync;sync;sync;sync;sync;sync;sync;sync;sync) &
   vinum start
   echo Stop $i
   vinum stop
   i=$(($i + 1))
 done
 
 This script was running without problems about 300 times, then I started
 `make buildworld' and system crashed immediately.
 
 Here is backtrace:
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x3ef85e4c
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc023c864
 stack pointer           = 0x10:0xe18d0d70
 frame pointer           = 0x10:0xe18d0d84
 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         = 6129 (rm)
 interrupt mask          = none
 trap number             = 12
 panic: page fault
 
 syncing disks...
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x3ef85e4c
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc023c864
 stack pointer           = 0x10:0xe18d0b20
 frame pointer           = 0x10:0xe18d0b34
 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         = 6129 (rm)
 interrupt mask          = none
 trap number             = 12
 panic: page fault
 Uptime: 9m2s
 
 dumping to dev #da/0x20009, offset 2621464
 dump 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750 749 748 747 746 745
 [cut]
 (kgdb) bt
 #0  dumpsys () at ../../kern/kern_shutdown.c:487
 #1  0xc0232867 in boot (howto=260) at ../../kern/kern_shutdown.c:316
 #2  0xc0232c8c in poweroff_wait (junk=0xc042a18c, howto=-1069376369)
     at ../../kern/kern_shutdown.c:595
 #3  0xc03a620e in trap_fatal (frame=0xe18d0ae0, eva=1056464460) at ../../i386/i386/trap.c:974
 #4  0xc03a5ee1 in trap_pfault (frame=0xe18d0ae0, usermode=0, eva=1056464460)
     at ../../i386/i386/trap.c:867
 #5  0xc03a5a9f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -814809072, tf_edi = 16,
       tf_esi = 1056464276, tf_ebp = -510850252, tf_isp = -510850292, tf_ebx = 4, tf_edx = 2,
       tf_ecx = -814803112, tf_eax = -814803112, tf_trapno = 12, tf_err = 0,
       tf_eip = -1071396764, tf_cs = 8, tf_eflags = 66050, tf_esp = -1023903520,
       tf_ss = -814803112}) at ../../i386/i386/trap.c:466
 #6  0xc023c864 in dscheck (bp=0xcf6f1758, ssp=0xc31b6800) at ../../kern/subr_diskslice.c:184
 #7  0xc023c4d5 in diskstrategy (bp=0xcf6f1758) at ../../kern/subr_disk.c:246
 #8  0xc026bcb4 in spec_strategy (ap=0xe18d0b80) at ../../miscfs/specfs/spec_vnops.c:479
 #9  0xc0258682 in bwrite (bp=0xcf6f1758) at vnode_if.h:944
 #10 0xc025df46 in vop_stdbwrite (ap=0xe18d0bb0) at ../../kern/vfs_default.c:344
 #11 0xc025dd91 in vop_defaultop (ap=0xe18d0bb0) at ../../kern/vfs_default.c:152
 #12 0xc02589d2 in bawrite (bp=0xcf6f1758) at vnode_if.h:1193
 #13 0xc026bb58 in spec_fsync (ap=0xe18d0c10) at ../../miscfs/specfs/spec_vnops.c:396
 #14 0xc033fe33 in ffs_sync (mp=0xc2f82c00, waitfor=2, cred=0xc1adc900, p=0xc055a520)
     at vnode_if.h:558
 #15 0xc0262e7b in sync (p=0xc055a520, uap=0x0) at ../../kern/vfs_syscalls.c:577
 #16 0xc0232602 in boot (howto=256) at ../../kern/kern_shutdown.c:235
 #17 0xc0232c8c in poweroff_wait (junk=0xc042a18c, howto=-1069376369)
     at ../../kern/kern_shutdown.c:595
 #18 0xc03a620e in trap_fatal (frame=0xe18d0d30, eva=1056464460) at ../../i386/i386/trap.c:974
 #19 0xc03a5ee1 in trap_pfault (frame=0xe18d0d30, usermode=0, eva=1056464460)
     at ../../i386/i386/trap.c:867
 #20 0xc03a5a9f in trap (frame={tf_fs = -510853104, tf_es = -1070333936, tf_ds = -1023934448,
       tf_edi = 2909664, tf_esi = 1056464276, tf_ebp = -510849660, tf_isp = -510849700,
       tf_ebx = 12, tf_edx = 2, tf_ecx = -814693552, tf_eax = -814693552, tf_trapno = 12,
       tf_err = 0, tf_eip = -1071396764, tf_cs = 8, tf_eflags = 66050, tf_esp = -1023903520,
       tf_ss = -814693552}) at ../../i386/i386/trap.c:466
 #21 0xc023c864 in dscheck (bp=0xcf70c350, ssp=0xc31b6800) at ../../kern/subr_diskslice.c:184
 #22 0xc023c4d5 in diskstrategy (bp=0xcf70c350) at ../../kern/subr_disk.c:246
 #23 0xc026bcb4 in spec_strategy (ap=0xe18d0dcc) at ../../miscfs/specfs/spec_vnops.c:479
 #24 0xc034784d in ufs_strategy (ap=0xe18d0e10) at vnode_if.h:944
 #25 0xc0347f1d in ufs_vnoperate (ap=0xe18d0e10) at ../../ufs/ufs/ufs_vnops.c:2376
 #26 0xc0258682 in bwrite (bp=0xcf70c350) at vnode_if.h:944
 #27 0xc025df46 in vop_stdbwrite (ap=0xe18d0e4c) at ../../kern/vfs_default.c:344
 #28 0xc025dd91 in vop_defaultop (ap=0xe18d0e4c) at ../../kern/vfs_default.c:152
 #29 0xc0347f1d in ufs_vnoperate (ap=0xe18d0e4c) at ../../ufs/ufs/ufs_vnops.c:2376
 #30 0xc0258a09 in bowrite (bp=0xcf70c350) at vnode_if.h:1193
 #31 0xc0344054 in ufs_dirremove (dvp=0xe18d4780, ip=0xc31b6600, flags=32776, isrmdir=0)
     at ../../ufs/ufs/ufs_lookup.c:1051
 #32 0xc0345eb7 in ufs_remove (ap=0xe18d0ecc) at ../../ufs/ufs/ufs_vnops.c:721
 #33 0xc0347f1d in ufs_vnoperate (ap=0xe18d0ecc) at ../../ufs/ufs/ufs_vnops.c:2376
 #34 0xc026427f in unlink (p=0xd9f89520, uap=0xe18d0f80) at vnode_if.h:583
 #35 0xc03a64bd in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1,
       tf_esi = 134717440, tf_ebp = -1077938368, tf_isp = -510849068, tf_ebx = 134778368,
       tf_edx = 134778448, tf_ecx = 0, tf_eax = 10, tf_trapno = 7, tf_err = 2,
       tf_eip = 134523416, tf_cs = 31, tf_eflags = 643, tf_esp = -1077938412, tf_ss = 47})
     at ../../i386/i386/trap.c:1175
 #36 0xc0397375 in Xint0x80_syscall ()
 #37 0x8048367 in ?? ()
 #38 0x804813e in ?? ()
 (kgdb) up 6
 #6  0xc023c864 in dscheck (bp=0xcf6f1758, ssp=0xc31b6800) at ../../kern/subr_diskslice.c:184
 184             } else {
 (kgdb) list
 179             }
 180             if (lp == NULL) {
 181                     labelsect = -LABELSECTOR - 1;
 182                     endsecno = sp->ds_size;
 183                     slicerel_secno = secno;
 184             } else {
 185                     labelsect = lp->d_partitions[LABEL_PART].p_offset;
 186     if (labelsect != 0) Debugger("labelsect != 0 in dscheck()");
 187                     pp = &lp->d_partitions[dkpart(bp->b_dev)];
 188                     endsecno = pp->p_size;
 (kgdb) up 15
 #21 0xc023c864 in dscheck (bp=0xcf70c350, ssp=0xc31b6800) at ../../kern/subr_diskslice.c:184
 184             } else {
 
 
 
 -- 
 Pawe Maachowski
 
 
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: kris 
Responsible-Changed-When: Mon Jul 14 03:10:23 PDT 2003 
Responsible-Changed-Why:  
Assign to vinum author 

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

From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
To: Freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/52916: vinum causes panic after start/stop/... cycle, easy to reproduce
Date: Wed, 13 Aug 2003 22:25:09 +0200

 Kernel panic always happens at dscheck() when looking for
 lp->d_partitions[2].p_offset -- lp (sp->ds_label) is faulty.
 There are different ways we can go to dscheck() to panic there, most
 `popular' is with fsyncing (typically by syslogd or MTA process):
 
 
 panic messages:
 ---
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x3d6373f2
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0232130
 stack pointer           = 0x10:0xc93c7dc4
 frame pointer           = 0x10:0xc93c7dd8
 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         = 60 (syslogd)
 interrupt mask          = none
 trap number             = 12
 panic: page fault
 
 syncing disks...
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x3d6373f2
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0232130
 stack pointer           = 0x10:0xc93c7afc
 frame pointer           = 0x10:0xc93c7b10
 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         = 60 (syslogd)
 interrupt mask          = bio
 trap number             = 12
 panic: page fault
 Uptime: 6m36s
 
 dumping to dev #da/0x20001, offset 524312
 dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 
 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 
 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 
 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 
 6 5 4 3 2 1 0
 ---
 #0  dumpsys () at ../../kern/kern_shutdown.c:487
 487             if (dumping++) {
 (kgdb) bt
 #0  dumpsys () at ../../kern/kern_shutdown.c:487
 #1  0xc0228097 in boot (howto=260) at ../../kern/kern_shutdown.c:316
 #2  0xc02284bc in poweroff_wait (junk=0xc041df2c, howto=-1069426129)
     at ../../kern/kern_shutdown.c:595
 #3  0xc039ba6a in trap_fatal (frame=0xc93c7abc, eva=1029927922)
     at ../../i386/i386/trap.c:974
 #4  0xc039b73d in trap_pfault (frame=0xc93c7abc, usermode=0, eva=1029927922)
     at ../../i386/i386/trap.c:867
 #5  0xc039b2fb in trap (frame={tf_fs = -1070071792, tf_es = 16, tf_ds = 6488080,
       tf_edi = 8025764, tf_esi = 1029927738, tf_ebp = -918783216,
       tf_isp = -918783256, tf_ebx = 4, tf_edx = 2, tf_ecx = -1014875688,
       tf_eax = -1014875688, tf_trapno = 12, tf_err = 0, tf_eip = -1071439568,
       tf_cs = 8, tf_eflags = 66054, tf_esp = -1057169064, tf_ss = -1014875688})
     at ../../i386/i386/trap.c:466
 #6  0xc0232130 in dscheck (bp=0xc38239d8, ssp=0xc110c900)
     at ../../kern/subr_diskslice.c:185
 #7  0xc0231da1 in diskstrategy (bp=0xc38239d8) at ../../kern/subr_disk.c:248
 #8  0xc02617e0 in spec_strategy (ap=0xc93c7b58)
     at ../../miscfs/specfs/spec_vnops.c:479
 #9  0xc033d3a5 in ufs_strategy (ap=0xc93c7b9c) at vnode_if.h:944
 #10 0xc033da75 in ufs_vnoperate (ap=0xc93c7b9c) at ../../ufs/ufs/ufs_vnops.c:2376
 #11 0xc024e18e in bwrite (bp=0xc38239d8) at vnode_if.h:944
 #12 0xc0253a52 in vop_stdbwrite (ap=0xc93c7c00) at ../../kern/vfs_default.c:344
 #13 0xc025389d in vop_defaultop (ap=0xc93c7c00) at ../../kern/vfs_default.c:152
 #14 0xc033da75 in ufs_vnoperate (ap=0xc93c7c00) at ../../ufs/ufs/ufs_vnops.c:2376
 #15 0xc024f0d3 in vfs_bio_awrite (bp=0xc38239d8) at vnode_if.h:1193
 #16 0xc0336f1d in ffs_fsync (ap=0xc93c7c64) at ../../ufs/ffs/ffs_vnops.c:220
 #17 0xc03358b3 in ffs_sync (mp=0xc1020600, waitfor=2, cred=0xc0b32880,
     p=0xc04a1040) at vnode_if.h:558
 #18 0xc02589a7 in sync (p=0xc04a1040, uap=0x0) at ../../kern/vfs_syscalls.c:577
 #19 0xc0227e32 in boot (howto=256) at ../../kern/kern_shutdown.c:235
 #20 0xc02284bc in poweroff_wait (junk=0xc041df2c, howto=-1069426129)
     at ../../kern/kern_shutdown.c:595
 #21 0xc039ba6a in trap_fatal (frame=0xc93c7d84, eva=1029927922)
     at ../../i386/i386/trap.c:974
 #22 0xc039b73d in trap_pfault (frame=0xc93c7d84, usermode=0, eva=1029927922)
     at ../../i386/i386/trap.c:867
 #23 0xc039b2fb in trap (frame={tf_fs = 16, tf_es = -1014956016, tf_ds = 16,
       tf_edi = 8038016, tf_esi = 1029927738, tf_ebp = -918782504,
       tf_isp = -918782544, tf_ebx = 16, tf_edx = 2, tf_ecx = -1014929472,
       tf_eax = -1014929472, tf_trapno = 12, tf_err = 0, tf_eip = -1071439568,
       tf_cs = 8, tf_eflags = 66054, tf_esp = -1057169064, tf_ss = -1014929472})
     at ../../i386/i386/trap.c:466
 #24 0xc0232130 in dscheck (bp=0xc38167c0, ssp=0xc110c900)
     at ../../kern/subr_diskslice.c:185
 #25 0xc0231da1 in diskstrategy (bp=0xc38167c0) at ../../kern/subr_disk.c:248
 #26 0xc02617e0 in spec_strategy (ap=0xc93c7e20)
     at ../../miscfs/specfs/spec_vnops.c:479
 #27 0xc033d3a5 in ufs_strategy (ap=0xc93c7e64) at vnode_if.h:944
 #28 0xc033da75 in ufs_vnoperate (ap=0xc93c7e64) at ../../ufs/ufs/ufs_vnops.c:2376
 #29 0xc024e18e in bwrite (bp=0xc38167c0) at vnode_if.h:944
 #30 0xc0253a52 in vop_stdbwrite (ap=0xc93c7ea0) at ../../kern/vfs_default.c:344
 #31 0xc025389d in vop_defaultop (ap=0xc93c7ea0) at ../../kern/vfs_default.c:152
 #32 0xc033da75 in ufs_vnoperate (ap=0xc93c7ea0) at ../../ufs/ufs/ufs_vnops.c:2376
 #33 0xc024e4de in bawrite (bp=0xc38167c0) at vnode_if.h:1193
 #34 0xc0336e8e in ffs_fsync (ap=0xc93c7f08) at ../../ufs/ffs/ffs_vnops.c:198
 #35 0xc025b3e8 in fsync (p=0xc7ecef60, uap=0xc93c7f80) at vnode_if.h:558
 #36 0xc039bd19 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
       tf_edi = 134565077, tf_esi = -1077940760, tf_ebp = -1077940752,
       tf_isp = -918781996, tf_ebx = 134563840, tf_edx = 134563840, tf_ecx = -2,
       tf_eax = 95, tf_trapno = 7, tf_err = 2, tf_eip = 671994496, tf_cs = 31,
       tf_eflags = 647, tf_esp = -1077942188, tf_ss = 47})
     at ../../i386/i386/trap.c:1175
 #37 0xc038ced5 in Xint0x80_syscall ()
 #38 0x804ac27 in ?? ()
 #39 0x804a6df in ?? ()
 #40 0x804a58c in ?? ()
 #41 0x804a168 in ?? ()
 #42 0x80496e6 in ?? ()
 (kgdb) up 24
 #24 0xc0232130 in dscheck (bp=0xc38167c0, ssp=0xc110c900)
     at ../../kern/subr_diskslice.c:185
 185             } else {
 (kgdb) p lp
 $1 = (struct disklabel *) 0x3d63733a
 (kgdb) x lp->d_partitions[2].p_offset
 Cannot access memory at address 0x3d6373f2.
 (kgdb) up 10
 #34 0xc0336e8e in ffs_fsync (ap=0xc93c7f08) at ../../ufs/ffs/ffs_vnops.c:198
 198                                             (void) bawrite(bp);
 (kgdb) p bp->b_dev->__si_u->__si_disk->__sid_disk->d_slice->dss_slices[2]->ds_label
 $2 = (struct disklabel *) 0x3d63733a
 (kgdb) x bp->b_dev->__si_u->__si_disk->__sid_disk->d_slice->dss_slices[2]->ds_label
 0x3d63733a:     Cannot access memory at address 0x3d63733a.
 (kgdb) print bp->b_dev->__si_u->__si_disk->__sid_disk->d_slice->dss_slices[2]
 $3 = {ds_offset = 1163672931, ds_size = 1936865848, ds_type = 1665489981,
   ds_label = 0x3d63733a, ds_dev = 0x3a37455c, ds_devs = {0x5c3d7473, 0x753a4845,
     0x455c3d70, 0xa5c3a4d, 0x656c3a09, 0x3a485e3d, 0x5e3d6c62, 0x72633a47},
   ds_openmask = 61 '=', ds_wlabel = 94 '^'}
 (kgdb) print bp->b_dev->__si_u->__si_disk->__sid_disk->d_slice->dss_slices[1]
 $4 = {ds_offset = 0, ds_size = 12594960, ds_type = 0, ds_label = 0x0,
   ds_dev = 0x0, ds_devs = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
   ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}
 
 
 Fault virtual address is 0x3d6373f2, which means lp->d_partitions[2].p_offset.
 lp ($1) points to 0x3d63733a and cannot be accessed.
 As one can see at $2, this pointer looks to be invalid very early, data at $3
 compared with $4 looks `random'.
 If dumpdev is set to swap partition on the same hard drive we run dscheck(),
 it is not possible to obtain crashdump -- dumping will fail.
 
 Included crashdump was obtained running script on 4.8-STABLE (with / fs
 and swap on /dev/ad0 hard drive and dumpdev set to /dev/da0s1b -- this
 second /dev/da0 hard drive was used only for dumps):
 
 #!/bin/sh
 i=1
 while [ 1 ]
 do
  echo Try $i
  vinum read /dev/ad0
  vinum stop
  i=$(($i+1))
 done
 
 While this scrit is running, I can observe things like that, for example
 from Sendmail:
 # collect: Cannot write ./dfh7DEdhLC000450 (fsync, uid=25, gid=25): Invalid argument
 Error writing control file ./tfh7DEdhLC000450: Invalid argument
 
 or:
 
 # cd /usr/ports/
 # make clean
 /usr/bin/make: Input/output error.
 # make clean
 /usr/bin/make: Input/output error.
 # make clean
 ===> archivers
 ===> archivers/9e non-existent
 ===> archivers/arc non-existent
 ===> archivers/arj non-existent
 ===> archivers/bzip non-existent
 
 Machine is still working, sometimes even for few minutes.
 
 Finally panic happens while `vinum read' (vinum start) is running.
 
 1.  /sbin/vinum vinum_read() calls ioctls: VINUM_STARTCONFIG, VINUM_CREATE,
 2.  Kernel part of vinum (vinumioctl.c) in case VINUM_CREATE calls
     parse_user_config(),
 3.  parse_user_config() (vinumconfig.c) calls parse_config(),
 4.  parse_config() (vinumconfig.c) in case kw_read calls vinum_scandisk(),
 5.  vinum_scandisk() (vinumio.c) will return ENOENT, cause there are no
     vinum slices on my test box,
 6.  Before vinum_scandisk() will return ENOENT, it calls check_drive(),
 7.  check_drive() (vinumio.c) calls read_drive_label(),
 8.  read_drive_label() (vinumio.c) calls init_drive(),
 9.  init_drive() (vinumio.c) calls open_drive(),
 10. open_drive() (vinumio.c) calls (dsw->d_open)(), which is actually
     diskopen(),
 11. diskopen() (kern/subr_disk.c) calls dsopen(),
 12. dsopen() (kern/subr_diskslice.c) calls dsinit(),
 13. dsinit() (kern/subr_diskmbr.c) sets B_READ flag on bp->b_flags
     and calls biowait(),
 14. biowait() (kern/vfs_bio.c) checks that B_READ flag is set and then calls
     tsleep(bp, PRIBIO, "biord", 0) -- this is protected with splbio()/splx(),
 15. Kernel panic happens right now, before splx(s), however sometimes splx()
     is called and biowait() returns with 0 before panic happens.
 
 It was easy to check at 13. that lp in dsinit() is still valid and equal to
 correct lp obtained from vinum.
 
 
 
 -- 
 Pawe Maachowski

From: =?iso-8859-2?Q?Pawe=B3_Ma=B3achowski?= <pawmal@unia.3lo.lublin.pl>
To: FreeBSD-gnats-submit@FreeBSD.org
Cc: grog@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: kern/52916 (vinum start/stop panic)
Date: Tue, 19 Aug 2003 15:05:15 +0200

 > 15. Kernel panic happens right now, before splx(s), however sometimes splx()
 >     is called and biowait() returns with 0 before panic happens.
 
 Actually, this finishing biowait() is not the one called by vinum (bp is
 different).
 
 
 Let's summarize:
 
 It looks that when open_drive() is called, some data in memory are getting
 corrupted. After tsleep() [kern/vfs_bio.c, biowait() called from dsinit()],
 some other processes have ability to work with disk, however, they usually
 fail as described earlier in audit-trail (,,Input/output error'' etc., also
 ,,handle_workitem_freeblocks: block count'').
 In most cases system panics in dscheck() while syncing because of invalid lp
 pointer.
 Probably this is not an issue when starting vinum from rc.conf, cause / fs
 is mounted read-only so write requests are not handled.
 
 This might give a real clue,
 I'm testing this on the following HDD configuration:
 ad0 - / fs mounted rw (/dev/ad0s1a) and swap (/dev/ad0s1b),
       there are no more partitions or slices
 da0 - /dev/da0s1b, used only as a dumpdev
 da1 - not used
 Running FreeBSD 4.8-STABLE. No vinum slices defined.
 
 
 When I run: vinum read /dev/da0; vinum stop; ...
 it will NOT panic. :)
 
 When I run: vinum read /dev/ad0; vinum stop; ...
 it WILL panic.
 
 If I force vinum at vinum_scandisk() to call dscheck()
 only for ('b'<=x<'i') partitions and run: vinum read /dev/ad0; vinum stop; ...
 seems it will NOT panic.
 
 If I force vinum at vinum_scandisk() to call dscheck()
 for ('a'<=x<'i', excluding 'c' and 'b') partition and run:
 vinum read /dev/ad0; vinum stop; ...
 seems it will NOT panic.
 
 If I force vinum at vinum_scandisk() to call dscheck()
 only for ('a'<=x<'c') partitions and run: vinum read /dev/ad0; vinum stop; ...
 it WILL panic, but not too fast.
 
 If I force vinum at vinum_scandisk() to call dscheck()
 only for ('a'<=x<'b') partition and run: vinum read /dev/ad0; vinum stop; ...
 seems it will NOT panic.
 
 where:
 ,,seems it will NOT panic'' == >500 iterations of read/stop loop without
 problem during ad0s1a (cd /usr/ports && make clean) activity.
 
 
 
 -- 
 Pawe Maachowski
Responsible-Changed-From-To: grog->le 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Sep 9 18:56:50 GMT 2004 
Responsible-Changed-Why:  
With permission of both, reassign from grog to le. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=52916 
State-Changed-From-To: open->feedback 
State-Changed-By: ceri 
State-Changed-When: Fri Nov 4 20:03:29 GMT 2005 
State-Changed-Why:  
If this bug only exists in vinum as it exists in 4.x and early 5.x then  
it basically isn't going to get fixed.  Can it be reproduced under the  
gvinum currently in use? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=52916 
State-Changed-From-To: feedback->closed 
State-Changed-By: le 
State-Changed-When: Sat Nov 26 15:20:41 GMT 2005 
State-Changed-Why:  
This behaviour can't be reproduced with gvinum, since in gvinum 
"stop" is a no-op. 

I'm closing this PR since 'classic' vinum isn't supported anymore. 

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