DragonFly bugs List (threaded) for 2009-10
Re: panic: assertion: leaf->base.obj_id == ip->obj_id in hammer_ip_delete_range
On Thu, Oct 22, 2009 at 06:19:01PM -0700, Matthew Dillon wrote:
> This is a rollup patch which contains all active uncommitted patches
> for HAMMER.
> fetch http://apollo.backplane.com/DFlyMisc/hammer06.patch
Before starting pbulk after booting the patched kernel, I issued
`hammer cleanup /pfs/archives' where I keep packages built by bulkbuild,
and I noticed the following line in the /var/log/messages:
Oct 23 19:15:49 firebolt kernel: HAMMER: Debug: rebalance hit right bndry
I guess this means that the new code in the patch avoided some bad
By the way, I caught a different panic on vkernel. I think the last
I ran `hammer cleanup' on /usr/obj was before applying hammer05.patch
or hammer06.patch to vkernel.
$ ls /usr/obj
$ rm -rf /usr/obj/*; sync
$ panic: assertion: parent != NULL in hammer_cursor_removed_node
mp_lock = 00000000; cpuid = 0
Trace beginning at frame 0x5b7dfabc
panic(5b7dfae0,0,0,58ba7168,5b7dfaf8) at 0x80dadce
panic(824684c,8269077,82826b7,5e226588,0) at 0x80dadce
hammer_cursor_removed_node(58ba7168,0,0,5b7dfc9c,0) at 0x81fe93a
hammer_btree_do_propagation(58ba7168,0,58ba71b8,58ba71b8,58ba71b8) at 0x81fc4e0
hammer_btree_do_propagation(0,0,52e22040,b,5b7dfbe8) at 0x81fc4c5
hammer_btree_delete(5b7dfc9c,1,1,5b7d0114,52e22040) at 0x81fc8c4
hammer_delete_at_cursor(5b7dfc9c,3,50c7fb30,b,4ae1c1b6) at 0x820b74e
hammer_ip_delete_record(5b7dfc9c,5e41ead0,50c7fb30,b,4000) at 0x820b9b6
hammer_ip_delete_range(5b7dfc9c,5e41ead0,0,0,ffffffff) at 0x820bda0
hammer_sync_inode(5b7d0114,5e41ead0,5b7d0000,5b7d0114,5b7d0000) at 0x82029bd
hammer_flusher_create(561212f0,0,0,0,0) at 0x8200b47
CPU0 stopping CPUs: 0x000000fe
Stopped at 0x823b061: movb $0,0x83a7ff4
So far the panic is repeatable, and removing `build.log' followed
by sync appears to trigger the panic. `undo -i' shows a warning like this.
# undo -i build.log
HAMMER: WARNING: Missing inode for dirent "build.log@@0x0000000b4d648360"
obj_id = 0000000b4d640668, asof=0000000b4d648360, lo=00070000
load: 0.00 cmd: undo 730 [fifoor] 0.00u 0.00s 0% 820k <-- ctrl+T
Since there's no important data in /usr/obj (and it's on vkernel anyway),
I don't mind losing the contents or the history, but will destroying and
recreating the PFS fix the issue?