Date: Sun, 28 Sep 1997 22:20:06 -0700 (PDT) From: Peter Wemm <peter@netplex.com.au> To: freebsd-bugs Subject: Re: kern/4630: buffer_map might become corrupted Message-ID: <199709290520.WAA17384@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/4630; it has been noted by GNATS.
From: Peter Wemm <peter@netplex.com.au>
To: Tor Egge <Tor.Egge@idi.ntnu.no>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG,
dyson@FreeBSD.ORG
Subject: Re: kern/4630: buffer_map might become corrupted
Date: Mon, 29 Sep 1997 13:18:22 +0800
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709290520.WAA17384>