看板 DFBSD_bugs 關於我們 聯絡資訊
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 condition, right? 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 build.log t $ 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 Debugger("panic") CPU0 stopping CPUs: 0x000000fe stopped Stopped at 0x823b061: movb $0,0x83a7ff4 db> 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?