oops: panic: bremfree: bp 0xc4206410 not locked
I got this while the system was swapping quite a bit (silly Gtk+ newsreader + supernews's huge retention == lots of memory used). FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 GNU gdb 5.2.0 (FreeBSD) 20020627 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: bremfree: bp 0xc4206410 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4206410 not locked cpuid = 0; lapic.id = Uptime: 1h20m25s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112[CTRL-C to abort] --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, len=14) at ../../../kern/vfs_cluster.c:801 #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) at ../../../kern/vfs_bio.c:1620 #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, td=0xc03ed9c0) at vnode_if.h:545 #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) at ../../../kern/vfs_syscalls.c:129 #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) at ../../../vm/uma_dbg.c:186 #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 zone_drain) at ../../../vm/uma_core.c:1167 #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #18 0xc0212330 in fork_exit (callout=0xc02fe784 vm_pageout, arg=0x0, frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 (kgdb) quit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: oops: panic: bremfree: bp 0xc4206410 not locked
I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Jim Bloom [EMAIL PROTECTED] Alex Zepeda wrote: I got this while the system was swapping quite a bit (silly Gtk+ newsreader + supernews's huge retention == lots of memory used). FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 GNU gdb 5.2.0 (FreeBSD) 20020627 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: bremfree: bp 0xc4206410 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4206410 not locked cpuid = 0; lapic.id = Uptime: 1h20m25s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112[CTRL-C to abort] --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, len=14) at ../../../kern/vfs_cluster.c:801 #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) at ../../../kern/vfs_bio.c:1620 #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, td=0xc03ed9c0) at vnode_if.h:545 #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) at ../../../kern/vfs_syscalls.c:129 #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) at ../../../vm/uma_dbg.c:186 #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 zone_drain) at ../../../vm/uma_core.c:1167 #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #18 0xc0212330 in fork_exit (callout=0xc02fe784 vm_pageout, arg=0x0, frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 (kgdb) quit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: oops: panic: bremfree: bp 0xc4206410 not locked
On Wed, Aug 14, 2002 at 05:35:32PM -0400, Jim Bloom wrote: I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Yes, this is the one that interests me as well. In fact I've got another dump with a strikingly similar backtrace (differnet panic messages tho). Is there anything useful I can do with the dumps, or are the backtraces helpful enough? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
