From owner-freebsd-bugs Sun Sep 28 22:19:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17300 for bugs-outgoing; Sun, 28 Sep 1997 22:19:02 -0700 (PDT) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17282; Sun, 28 Sep 1997 22:18:45 -0700 (PDT) Received: from spinner.netplex.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.netplex.com.au with ESMTP id NAA08603; Mon, 29 Sep 1997 13:18:23 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199709290518.NAA08603@spinner.netplex.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Tor Egge cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 00:02:37 +0200." <199709282202.AAA27999@pat.idi.ntnu.no> Date: Mon, 29 Sep 1997 13:18:22 +0800 From: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tor Egge wrote: > A new crash. > > ----- > (kgdb) print intr_nesting_level > $1 = 2 > (kgdb) where > #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 > #1 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") > at ../../kern/kern_shutdown.c:393 > #2 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe3c4c2c0) > at ../../vm/vm_map.c:344 > #3 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3e16640) > at ../../vm/vm_map.c:883 > #4 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3e16640, > start=3881472000) at ../../vm/vm_map.c:943 > #5 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3881472000, > end=3881480192) at ../../vm/vm_map.c:1891 > #6 0xe012fe0d in bfreekva (bp=0xe7015f94) at ../../kern/vfs_bio.c:240 > #7 0xe01307ec in brelse (bp=0xe7015f94) at ../../kern/vfs_bio.c:696 > #8 0xe0132150 in biodone (bp=0xe7015f94) at ../../kern/vfs_bio.c:1888 > #9 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe7015f94) > at ../../dev/ccd/ccd.c:966 > #10 0xe01016ea in ccdiodone (cbp=0xe3caae00) at ../../dev/ccd/ccd.c:1026 > #11 0xe0131f04 in biodone (bp=0xe3caae00) at ../../kern/vfs_bio.c:1774 > #12 0xe019846c in scsi_done (xs=0xe3e1a480) at ../../scsi/scsi_base.c:450 > #13 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) > at ../../i386/scsi/aic7xxx.c:1969 > #14 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 > #15 0xe0119160 in tsleep (ident=0xe35e0fb8, priority=17, > wmesg=0xe01a4a2a "ffsfsn", timo=0) at ../../kern/kern_synch.c:330 > #16 0xe01a4b3d in ffs_fsync (ap=0xe9478ce8) at ../../ufs/ffs/ffs_vnops.c:313 > #17 0xe01b45b2 in vm_object_page_clean (object=0xe375f680, start=0, end=0, > syncio=1, lockflag=1) at vnode_if.h:479 > #18 0xe0136cd6 in vfs_msync (mp=0xe3083800, flags=2) > at ../../kern/vfs_subr.c:2127 > #19 0xe01376d4 in sync (p=0xe021c670, uap=0x0, retval=0x0) > at ../../kern/vfs_syscalls.c:479 > #20 0xe0117251 in boot (howto=256) at ../../kern/kern_shutdown.c:203 > #21 0xe0117676 in panic (fmt=0xe01b0013 "vm_map_entry_dispose in interrupt") ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > at ../../kern/kern_shutdown.c:393 > #22 0xe01b009b in vm_map_entry_dispose (map=0xe25a1f00, entry=0xe34af280) > at ../../vm/vm_map.c:344 > #23 0xe01b09af in vm_map_simplify_entry (map=0xe25a1f00, entry=0xe3ac1700) > at ../../vm/vm_map.c:883 > #24 0xe01b0a7d in _vm_map_clip_start (map=0xe25a1f00, entry=0xe3ac1700, > start=3882176512) at ../../vm/vm_map.c:943 > #25 0xe01b1f6e in vm_map_delete (map=0xe25a1f00, start=3882176512, > end=3882184704) at ../../vm/vm_map.c:1891 > #26 0xe012fe0d in bfreekva (bp=0xe700e064) at ../../kern/vfs_bio.c:240 > #27 0xe01307ec in brelse (bp=0xe700e064) at ../../kern/vfs_bio.c:696 > #28 0xe0132150 in biodone (bp=0xe700e064) at ../../kern/vfs_bio.c:1888 > #29 0xe0101610 in ccdintr (cs=0xe2faf198, bp=0xe700e064) > at ../../dev/ccd/ccd.c:966 > #30 0xe01016ea in ccdiodone (cbp=0xe37cb300) at ../../dev/ccd/ccd.c:1026 > #31 0xe0131f04 in biodone (bp=0xe37cb300) at ../../kern/vfs_bio.c:1774 > #32 0xe019846c in scsi_done (xs=0xe30eee00) at ../../scsi/scsi_base.c:450 > #33 0xe01f292c in ahc_done (ahc=0xe2fa5000, scb=0xe336e300) > at ../../i386/scsi/aic7xxx.c:1969 > #34 0xe01f0497 in ahc_intr (arg=0xe2fa5000) at ../../i386/scsi/aic7xxx.c:843 ^^^^^^^^^^^^^^^^^^^ > #35 0x3d51 in ?? () > ----- > > This means that both vm_map_entry_dispose and vm_map_entry_create might > be called in an interrupt context, manipulating buffer_map and the free > pool of vm map entries. > > A simple spl protection of vm_map_entry_dispose/vm_map_entry_create > is not sufficient. > > For 2.2-STABLE, MALLOC might be called with M_WAITOK during during the > interrupt (vm_map_entry_create -> MALLOC) > > For CURRENT, kmem_alloc might be called during an interrupt. > (vm_map_entry_create -> zalloc -> _zalloc -> _zget -> kmem_alloc) > > Thus, it might be better to not call bfreekva in brelse if it occurs > during an interrupt. An alternate solution is to not call brelse in > biodone, but instead push the buffer onto a list that is emptied by a > dedicated high priority kernel process. > > - Tor Egge I've spotted something possibly related from at least one 2.2-STABLE system.. From the console log during a relatively quiet time: 3:45PM up 6 days, 5:56, 15 users, load averages: 0.01, 0.00, 0.00 Sun Sep 28 16:00:00 CST 1997 4:00PM up 6 days, 6:11, 16 users, load averages: 0.00, 0.00, 0.00 4:15PM up 6 days, 6:26, 15 users, load averages: 0.00, 0.00, 0.00 4:30PM up 6 days, 6:41, 15 users, load averages: 0.03, 0.01, 0.00 panic: vm_object_deallocate: object deallocated too many times Debugger("panic") Choose: b)oot, d)ebugger, p)anic, q)uit? Timeout after 30 seconds; Rebooting.. syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xf012c806 [..] This particular panic has happend twice on this machine. It's configured identically to a dozen others (P5-133, 32MB, ASUS 430HX mboard, quantum ide drives). Cheers, -Peter