From tf@wurbl.wn.bawue.de Fri May 19 16:56:06 2000 Return-Path: Received: from nadia.s.bawue.de (nadia.s.bawue.de [193.197.11.52]) by hub.freebsd.org (Postfix) with ESMTP id BA4A437BC45 for ; Fri, 19 May 2000 16:56:02 -0700 (PDT) (envelope-from tf@wurbl.wn.bawue.de) Received: from wurbl.wn.bawue.de (uucp@localhost) by nadia.s.bawue.de (8.9.3/8.9.3) with UUCP id BAA18938 for freebsd.org!FreeBSD-gnats-submit; Sat, 20 May 2000 01:56:00 +0200 (CEST) Received: from uucp (helo=prian.bk.int) by wurbl.bk.int with local-esmtp (Exim 3.03 #1) id 12svMk-0000xB-00 for FreeBSD-gnats-submit@freebsd.org; Sat, 20 May 2000 00:35:35 +0200 Message-Id: Date: Sat, 20 May 2000 00:29:42 +0200 (CEST) From: Thomas Faehnle To: FreeBSD-gnats-submit@freebsd.org Subject: "vinum start" under load causes "Fatal trap 12" >Number: 18685 >Category: kern >Synopsis: "vinum start" under load causes "Fatal trap 12" >Confidential: no >Severity: critical >Priority: medium >Responsible: grog >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri May 19 17:00:01 PDT 2000 >Closed-Date: Tue Jul 11 00:07:07 MDT 2000 >Last-Modified: Tue Jul 11 00:09:05 MDT 2000 >Originator: Thomas Faehnle >Release: FreeBSD 4.0-STABLE i386 >Organization: Multisys GbR >Environment: 4.0-STABLE, tracked up to CTM patch src-4.0077 >Description: Starting the vinum subsystem ("vinum start") on a loaded machine causes a "Fatal trap 12: page fault while in kernel mode". DDB output follows: ,-------------------- | Fatal trap 12: page fault while in kernel mode | fault virtual address = 0x69666f27 | fault code = supervisor read, page not present | instruction pointer = 0x8:0xc0158c14 | stack pointer = 0x10:0xc3dd7bf8 | frame pointer = 0x10:0xc3dd7c0c | 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 = 974 (make) | interrupt mask = none | kernel: type 12 trap, code=0 | Stopped at dscheck+0x104: movl 0xb8(%esi),%edx | | db> trace | dscheck(c1413728,c08c6900) at dscheck+0x104 | diskstrategy(c1413728,c0845e80,c1413728,0,c3dd7c4c) at diskstrategy+0xad | spec_strategy(c3dd7c70,c3dd7c58,c0208f7d,c3dd7c70,c3dd7c8c) at spec_strategy+0x8c | spec_vnoperate(c3dd7c70,c3dd7c8c,c02089e5,c3dd7c70,c3dd7ce4) at spec_vnoperate+0x15 | ufs_vnoperatespec(c3dd7c70,c3dd7ce4,c1413728,0,c028ae80) at ufs_vnoperatespec+0x15 | ufs_strategy(c3dd7cb0,c3dd7cbc,c017114a,c3dd7cb0,c08d2400) at ufs_strategy+0xc5 | ufs_vnoperate(c3dd7cb0) at ufs_vnoperate+0x15 | bread(c3df7540,0,400,0,c3dd7ce4) at bread+0x8e | ffs_blkatoff(c3df7540,0,0,0,c3dd7d64) at ffs_blkatoff+0x83 | ufs_lookup(c3dd7db4,c3dd7dc8,c0174c51,c3dd7db4,c3dbe806) at ufs_lookup+0x1ed | ufs_vnoperate(c3dd7db4,c3dbe806,c3df7540,c3dd7eac,c3dd7dbc) at ufs_vnoperate+0x15 | vfs_cache_lookup(c3dd7e08,c3dd7e18,c0177848,c3dd7e08,c3df7540) at vfs_cache_lookup+0x251 | ufs_vnoperate(c3dd7e08,c3df7540,c0993900,c3dd7eac,c3b0ca00) at ufs_vnoperate+0x15 | lookup(c3dd7e84,c3b0ca00,c3b0ca00,c3dd7f80,c3b0ca00) at lookup+0x284 | namei(c3dd7e84,c3b0ca00,2,c3dd7f80,8072d90) at namei+0x178 | stat(c3b0ca00,c3dd7f80,8072d90,0,8074600) at stat+0x41 | syscall2(2f,2f,2f,8074600,0) at syscall2+0x1f1 | Xint0x80_syscall() at Xint0x80_syscall+0x26 | | db> ps | pid proc addr uid ppid pgrp flag stat wmesg wchan cmd | 1090 c3def740 c3e5b000 0 1 1090 000204 3 vinum c09bcb90 vinum | 1084 c3df0e00 c3df1000 0 208 1084 004006 2 vinum | 974 c3b0ca00 c3dd6000 0 662 628 004006 2 make | 662 c3df0ac0 c3df4000 0 659 628 004086 3 wait c3df0ac0 sh | 659 c3b0c6c0 c3ddc000 0 639 628 004486 2 make | 639 c3b0d220 c3dc2000 0 636 628 004086 3 wait c3b0d220 sh | 636 c3b0cd40 c3dca000 0 635 628 004486 2 make | 635 c3b0cee0 c3dc8000 0 628 628 004086 3 wait c3b0cee0 sh | 628 c3b0d080 c3dc4000 0 207 628 004486 2 make | 214 c3b0d3c0 c3dba000 0 1 214 004086 3 ttyin c085f410 getty | 213 c3b0d560 c3db6000 0 1 213 004086 3 ttyin c085f610 getty | 212 c3b0d700 c3db3000 0 1 212 004086 3 ttyin c085f710 getty | 211 c3b0dbe0 c3da4000 0 1 211 004086 3 ttyin c085f810 getty | 210 c3b0d8a0 c3dab000 0 1 210 004086 3 ttyin c085f910 getty | 209 c3b0dd80 c3da1000 0 1 209 004086 3 ttyin c085fa10 getty | 208 c3b0e740 c3d8c000 0 1 208 004086 3 wait c3b0e740 bash | 207 c3b0f5e0 c3d65000 0 1 207 004086 3 wait c3b0f5e0 bash | 192 c3b0da40 c3da7000 0 1 192 000084 3 select c02c1dec moused | 161 c3b0df20 c3d9d000 0 1 161 000584 2 sendmail | 158 c3b0e0c0 c3d9a000 0 1 158 000484 2 cron | 156 c3b0e260 c3d96000 0 1 156 000084 3 select c02c1dec inetd | 140 c3b0e400 c3d92000 0 1 140 000084 3 select c02c1dec rpc.statd | 138 c3b0e5a0 c3d8f000 0 1 138 000084 3 select c02c1dec rpc.lockd | 136 c3b0e8e0 c3d89000 0 132 132 000084 3 nfsd c0827200 nfsd | 135 c3b0ea80 c3d86000 0 132 132 000084 3 nfsd c07f3200 nfsd | 134 c3b0ec20 c3d83000 0 132 132 000084 3 nfsd c0827000 nfsd | 133 c3b0f440 c3d68000 0 132 132 000084 3 nfsd c07f3000 nfsd | 132 c3b0edc0 c3d80000 0 1 132 000084 3 accept c39e39f6 nfsd | 130 c3b0ef60 c3d7d000 0 1 130 000084 3 select c02c1dec mountd | 125 c3b0f100 c3d72000 1 1 125 000184 3 select c02c1dec portmap | 119 c3b0f2a0 c3d6f000 0 1 119 000084 2 syslogd | 5 c3b0f780 c3b1c000 0 0 0 000204 2 syncer | 4 c3b0f920 c3b1a000 0 0 0 100604 2 bufdaemon | 3 c3b0fac0 c3b18000 0 0 0 000204 3 psleep c02b9380 vmdaemon | 2 c3b0fc60 c3b16000 0 0 0 100604 2 pagedaemon | 1 c3b0fe00 c3b14000 0 0 1 004284 3 wait c3b0fe00 init | 0 c02c1180 c0327000 0 0 0 000204 3 sched c02c1180 swapper | 1089 c3ded1e0 c3ed9000 0 1084 1084 002006 5 vinum | db> `-------------------- Vinum configuration follows: ,-------------------- | 3 drives: | D d0 State: up Device /dev/da0s2e Avail: 14539/15539 MB (93%) | D d1 State: up Device /dev/da1s2e Avail: 14539/15539 MB (93%) | D d2 State: up Device /dev/da2s2e Avail: 14539/15539 MB (93%) | | 1 volumes: | V raid State: up Plexes: 1 Size: 2000 MB | | 1 plexes: | P raid.p0 R5 State: up Subdisks: 3 Size: 2000 MB | | 3 subdisks: | S raid.p0.s0 State: up PO: 0 B Size: 1000 MB | S raid.p0.s1 State: up PO: 256 kB Size: 1000 MB | S raid.p0.s2 State: up PO: 512 kB Size: 1000 MB `-------------------- >How-To-Repeat: Generate some load (I did a "make -j 30 buildworld" on a i586/133MHz/32MB machine). Type "vinum start" to activate vinum with an existing configuration. >Fix: >Release-Note: >Audit-Trail: State-Changed-From-To: open->feedback State-Changed-By: grog State-Changed-When: Fri May 19 18:14:29 PDT 2000 State-Changed-Why: Awaiting further information from subbmitter. Responsible-Changed-From-To: freebsd-bugs->grog Responsible-Changed-By: grog Responsible-Changed-When: Fri May 19 18:14:29 PDT 2000 Responsible-Changed-Why: grog handles Vinum PRs. State-Changed-From-To: feedback->closed State-Changed-By: imp State-Changed-When: Tue Jul 11 00:07:07 MDT 2000 State-Changed-Why: This looks EXACTLY like a bug that I've fixed in subr_disk.c. Likely they are related. it would be even more likely if the vinum start was not the first time you did this, but the second or theird because disk_destroy was leaving bogons around. http://www.freebsd.org/cgi/query-pr.cgi?pr=18685 >Unformatted: Greg Lehey, 20 May 2000 Removed complete copy of PR from Audit Trail. This stack trace doesn't look like it has anything to do with Vinum. It's from a make process, and it's in generic disk processing. In any case, in order to do anything, I'll need a dump. If you think it's Vinum, please take a look at the list of information required in vinum(4) or at http://www.lemis.com/vinum/how-to-debug.html and send this information.