From mkb@reiher.informatik.uni-wuerzburg.de  Mon Sep 29 07:17:11 2003
Return-Path: <mkb@reiher.informatik.uni-wuerzburg.de>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CB64316A4BF
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 29 Sep 2003 07:17:11 -0700 (PDT)
Received: from haegar.informatik.uni-wuerzburg.de (wi4x41.informatik.uni-wuerzburg.de [132.187.101.41])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C040B44001
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 29 Sep 2003 07:17:09 -0700 (PDT)
	(envelope-from mkb@reiher.informatik.uni-wuerzburg.de)
Received: from reiher.informatik.uni-wuerzburg.de (wi4d22.informatik.uni-wuerzburg.de [132.187.101.122])
	by haegar.informatik.uni-wuerzburg.de (Postfix) with ESMTP id B9ADD24FAA
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 29 Sep 2003 16:17:08 +0200 (CEST)
Received: by reiher.informatik.uni-wuerzburg.de (Postfix, from userid 1001)
	id 0DCAD5C34; Mon, 29 Sep 2003 16:17:14 +0200 (CEST)
Message-Id: <20030929141714.0DCAD5C34@reiher.informatik.uni-wuerzburg.de>
Date: Mon, 29 Sep 2003 16:17:14 +0200 (CEST)
From: Matthias Buelow <mkb@mukappabeta.de>
Reply-To: Matthias Buelow <mkb@mukappabeta.de>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: vinum resetconfig panic on 5.1
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         57363
>Category:       kern
>Synopsis:       vinum resetconfig panic on 5.1
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 29 07:20:03 PDT 2003
>Closed-Date:    Mon Sep 29 18:03:54 PDT 2003
>Last-Modified:  Tue Oct  7 19:30:09 PDT 2003
>Originator:     Matthias Buelow
>Release:        FreeBSD 5.1-RELEASE-p2 i386
>Organization:
>Environment:
System: xxx

5.1-RELEASE-p2/i386

>Description:

	vinum resetconfig seems to render the vinum configuration
	extremely unstable.  In about 1/3 of the resetconfig attempts
	on two different machines running 5.1, it produced a kernel
	panic.  On one machine, after resetconfig panicked the machine,
	it would also panic on every vinum create.
	This occurred with both IDE aswell as SCSI disks.
	I can't at the moment provide a crash dump.  Maybe also the
	problem is already known.  If not, I could take some effort
	to produce a trace.

>How-To-Repeat:

	Install 5.1, play around with vinum create+resetconfig.
>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: grog 
State-Changed-When: Mon Sep 29 18:01:10 PDT 2003 
State-Changed-Why:  
Informational PR, closed. 


Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: grog 
Responsible-Changed-When: Mon Sep 29 18:01:10 PDT 2003 
Responsible-Changed-Why:  
grog handles Vinum PRs 

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

From: Oliver Lehmann <oliver@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc: grog@freebsd.org
Subject: Re: kern/57363: vinum resetconfig panic on 5.1
Date: Sun, 5 Oct 2003 01:27:16 +0200

 Here are some informations about the described incident. I'm able to 
 reproduce it.
 (The lines with more than 74 chars are intentionally not wrapped)
 
 
 root@nudel NUDEL> gdb -k kernel.debug  /usr/tmp//vmcore.0
 GNU gdb 5.2.1 (FreeBSD)
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "i386-undermydesk-freebsd"...
 panic: from debugger
 panic messages:
 ---
 Fatal trap 12: page fault while in kernel mode
 cpuid = 1; lapic.id = 01000000
 fault virtual address   = 0xdeadc0e2
 fault code              = supervisor write, page not present
 instruction pointer     = 0x8:0xc021e975
 stack pointer           = 0x10:0xce0f9a64
 frame pointer           = 0x10:0xce0f9a7c
 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         = 578 (vinum)
 panic: from debugger
 cpuid = 1; lapic.id = 01000000
 
 
 Fatal trap 3: breakpoint instruction fault while in kernel mode
 cpuid = 1; lapic.id = 01000000
 instruction pointer     = 0x8:0xc0337755
 stack pointer           = 0x10:0xce0f97d4
 frame pointer           = 0x10:0xce0f97e0
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = IOPL = 0
 current process         = 578 (vinum)
 panic: from debugger
 cpuid = 1; lapic.id = 01000000
 boot() called on cpu#1
 Uptime: 5m25s
 acd0: timeout waiting for cmd=e7 s=11 e=04
 acd0: flushing device failed
 Dumping 256 MB
 ata0: resetting devices ..
 done
  16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
 ---
 #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
 238             dumping++;
 (kgdb) bt
 #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
 #1  0xc0204923 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:370
 #2  0xc0204cdf in panic () at /usr/src/sys/kern/kern_shutdown.c:543
 #3  0xc014c392 in db_panic () at /usr/src/sys/ddb/db_command.c:448
 #4  0xc014c312 in db_command (last_cmdp=0xc03a8440, cmd_table=0xc03a8260, aux_cmd_tablep=0xc03a1694, aux_cmd_tablep_end=0xc03a1698) at /usr/src/sys/ddb/db_command.c:346
 #5  0xc014c426 in db_command_loop () at /usr/src/sys/ddb/db_command.c:470
 #6  0xc014f1ba in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
 #7  0xc0337463 in kdb_trap (type=12, code=0, regs=0xce0f9a24) at /usr/src/sys/i386/i386/db_interface.c:170
 #8  0xc0350b22 in trap_fatal (frame=0xce0f9a24, eva=0) at /usr/src/sys/i386/i386/trap.c:829
 #9  0xc0350802 in trap_pfault (frame=0xce0f9a24, usermode=0, eva=3735929058) at /usr/src/sys/i386/i386/trap.c:748
 #10 0xc03503cd in trap (frame=
       {tf_fs = -1069875176, tf_es = -1071710192, tf_ds = -1068957680, tf_edi = 17993, tf_esi = -1058251008, tf_ebp = -837838212, tf_isp = -837838256, tf_ebx = -1034852416, tf_edx = -559038242, tf_ecx = 1, tf_eax = -559038242, tf_trapno = 12, tf_err = 2, tf_eip = -1071519371, tf_cs = 8, tf_eflags = 66182, tf_esp = -1058250996, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:433
 #11 0xc0338e08 in calltrap () at {standard input}:97
 #12 0xc01ab511 in free_vinum (cleardrive=1) at /usr/src/sys/dev/vinum/vinum.c:265
 #13 0xc01b2cc6 in vinum_super_ioctl (dev=0xc2680a00, cmd=0, data=0xce0f9c54 "\001") at /usr/src/sys/dev/vinum/vinumioctl.c:330
 #14 0xc01b25d6 in vinumioctl (dev=0x0, cmd=17993, data=0xce0f9c54 "\001", flag=3, td=0xc26ce5f0) at /usr/src/sys/dev/vinum/vinumioctl.c:80
 #15 0xc01cbe9e in spec_ioctl (ap=0xce0f9c54) at /usr/src/sys/fs/specfs/spec_vnops.c:347
 #16 0xc01cb5d8 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:123
 #17 0xc0266e51 in vn_ioctl (fp=0xc2728ce4, com=17993, data=0xce0f9c54, active_cred=0xc29fb300, td=0xc26ce5f0) at vnode_if.h:488
 #18 0xc022b2a8 in ioctl (td=0xc26ce5f0, uap=0xce0f9d10) at file.h:251
 #19 0xc0350e6e in syscall (frame=
       {tf_fs = -1078001617, tf_es = -1078001617, tf_ds = -1078001617, tf_edi = 135079267, tf_esi = -1077937637, tf_ebp = -1077937592, tf_isp = -837837452, tf_ebx = -1077937648, tf_edx = -1077937664, tf_ecx = 0, tf_eax = 54, tf_trapno = 22, tf_err = 2, tf_eip = 134701199, tf_cs = 31, tf_eflags = 582, tf_esp = -1077937668, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1021
 #20 0xc0338e5d in Xint0x80_syscall () at {standard input}:139
 ---Can't read userspace from dump, or kernel process---
 
 (kgdb) up 10
 #10 0xc03503cd in trap (frame=
       {tf_fs = -1069875176, tf_es = -1071710192, tf_ds = -1068957680, tf_edi = 17993, tf_esi = -1058251008, tf_ebp = -837838212, tf_isp = -837838256, tf_ebx = -1034852416, tf_edx = -559038242, tf_ecx = 1, tf_eax = -559038242, tf_trapno = 12, tf_err = 2, tf_eip = -1071519371, tf_cs = 8, tf_eflags = 66182, tf_esp = -1058250996, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:433
 433                             (void) trap_pfault(&frame, FALSE, eva);
 (kgdb) list
 428     
 429                     KASSERT(cold || td->td_ucred != NULL,
 430                         ("kernel trap doesn't have ucred"));
 431                     switch (type) {
 432                     case T_PAGEFLT:                 /* page fault */
 433                             (void) trap_pfault(&frame, FALSE, eva);
 434                             goto out;
 435     
 436                     case T_DNA:
 437     #ifdef DEV_NPX
 (kgdb) 
 (kgdb)

From: Greg 'groggy' Lehey <grog@FreeBSD.org>
To: Oliver Lehmann <oliver@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/57363: vinum resetconfig panic on 5.1
Date: Wed, 8 Oct 2003 10:47:05 +0930

 --82WbDBJhFeTAYH8j
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Sunday,  5 October 2003 at  1:27:16 +0200, Oliver Lehmann wrote:
 > Here are some informations about the described incident. I'm able to
 > reproduce it.
 
 You're responding to somebody else's problem report, and it's closed.
 
 > #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
 > 238             dumping++;
 > (kgdb) bt
 > #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
 > ...
 > #10 0xc03503cd in trap (frame=
 >       {tf_fs = -1069875176, tf_es = -1071710192, tf_ds = -1068957680, tf_edi = 17993, tf_esi = -1058251008, tf_ebp = -837838212, tf_isp = -837838256, tf_ebx = -1034852416, tf_edx = -559038242, tf_ecx = 1, tf_eax = -559038242, tf_trapno = 12, tf_err = 2, tf_eip = -1071519371, tf_cs = 8, tf_eflags = 66182, tf_esp = -1058250996, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:433
 > #11 0xc0338e08 in calltrap () at {standard input}:97
 > #12 0xc01ab511 in free_vinum (cleardrive=1) at /usr/src/sys/dev/vinum/vinum.c:265
 
 You're not usually interested in the code in trap().  It's the next
 function down (often conveniently hidden) which is of interest.
 
 Anyway, there's not much point in adding text to a closed PR,
 especially since the system details are probably incorrect.  If you
 can't get help on the list, enter a new PR with your own details.
 
 Greg
 --
 See complete headers for address and phone numbers.
 
 --82WbDBJhFeTAYH8j
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.0 (FreeBSD)
 
 iD8DBQE/g2WRIubykFB6QiMRAi/rAJsEN2xrB+wxjCGdOsmZ0Zab6unSjgCgjvvJ
 7PVp8nwTfLJkbZKr5RDxHJU=
 =tGpS
 -----END PGP SIGNATURE-----
 
 --82WbDBJhFeTAYH8j--
>Unformatted:

Greg Lehey, 30 September 2003

	I've tried the "how-to-repeat" repeatedly.  It worked as
	expected.  Obviously there's something special about the
	circumstances behind this report, but without any information
	(not even the information requested in the man page), there's
	not much I can do about it.  I'll treat this as an
	informational PR and close it.  If you get a dump, please
	contact me.
