Latest 3.1 development version core dumps while destroying master PFS
Hi, I was destroying a master PFS on the ROOT volume and the system ( v3.1.0.827.gf6167a5-DEVELOPMENT )core dumped. I tried today's latest snapshot and got the same result. The Coredump is uploaded to sgeorge@leaf:~/crash/Coredump20120718.tbz I have reported this through redmine. Is that enough or should I notify bugs@ also? https://bugs.dragonflybsd.org/issues/2396 Thanks Siju panic: assertion layer2-zone == zone failed in hammer_blockmap_free at /usr/src/sys/vfs/hammer/hammer_blockmap.c:1020 cpuid = 0 Trace beginning at frame 0xffe09e20f178 panic() at panic+0x1fb 0x804bef68 panic() at panic+0x1fb 0x804bef68 hammer_blockmap_free() at hammer_blockmap_free+0x2e5 0x80691a0c hammer_delete_at_cursor() at hammer_delete_at_cursor+0x4e2 0x806aac62 hammer_pfs_rollback() at hammer_pfs_rollback+0x26c 0x806b0b20 hammer_ioc_destroy_pseudofs() at hammer_ioc_destroy_pseudofs+0x77 0x806b0c6c hammer_ioctl() at hammer_ioctl+0x80e 0x806a5b1e hammer_vop_ioctl() at hammer_vop_ioctl+0x58 0x806be8d3 vop_ioctl() at vop_ioctl+0x98 0x8053d244 vn_ioctl() at vn_ioctl+0xfd 0x8053a4d9 fo_ioctl() at fo_ioctl+0x46 0x804f026e mapped_ioctl() at mapped_ioctl+0x493 0x804f0725 sys_ioctl() at sys_ioctl+0x1c 0x804f07be syscall2() at syscall2+0x370 0x807814c1 Xfast_syscall() at Xfast_syscall+0xcb 0x8076ae2b (null)() at 0 0 (null)() at 0x723d524553550061 0x723d524553550061 Fatal trap 9: general protection fault while in kernel mode cpuid = 0; lapic-id = instruction pointer = 0x8:0x8077acf9 stack pointer = 0x10:0xffe09e20f010 frame pointer = 0x10:0xffe09e20f028 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 0, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 957 current thread = pri 10 kernel: type 9 trap, code=0 CPU0 stopping CPUs: 0x0002 stopped Physical memory: 3787 MB Dumping 1055 MB: 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
leaf server boot partition full 101%
Hi, /boot is 101% on leaf server :-(
Re: leaf server boot partition full 101%
On Wed, 18 Jul 2012 12:57:45 +0200, Siju George sgeorge@gmail.com wrote: Hi, /boot is 101% on leaf server :-( Thanks, I've freed it up a bit.
Hammer log message
I saw this message in the log: HAMMER debug: shifted cursor pointing at parent parent 81992a0f:13 onode 819961415000:0 nnode 8199609b:50 I suspect this is just informational, but wanted to be sure. Tim
Re: Latest 3.1 development version core dumps while destroying master PFS
Hi, I tried to destroy the PFS after unmounting 1. after downgrading 2. with latest dev snapshot usb stick 3. in single user mode 4. after creating a link DataNew - @@-1:8 The system always core dumps. I guess Matt will be busy working on HAMMER2 and wonder if i should keep waiting till the bug is fixed. Since this is my Main backup Server Should I just re-install the whole thing and move forward? Thanks --Siju On Wed, Jul 18, 2012 at 4:22 PM, Siju George sgeorge@gmail.com wrote: Hi, I was destroying a master PFS on the ROOT volume and the system ( v3.1.0.827.gf6167a5-DEVELOPMENT )core dumped. I tried today's latest snapshot and got the same result. The Coredump is uploaded to sgeorge@leaf:~/crash/Coredump20120718.tbz I have reported this through redmine. Is that enough or should I notify bugs@ also? https://bugs.dragonflybsd.org/issues/2396 Thanks Siju panic: assertion layer2-zone == zone failed in hammer_blockmap_free at /usr/src/sys/vfs/hammer/hammer_blockmap.c:1020 cpuid = 0 Trace beginning at frame 0xffe09e20f178 panic() at panic+0x1fb 0x804bef68 panic() at panic+0x1fb 0x804bef68 hammer_blockmap_free() at hammer_blockmap_free+0x2e5 0x80691a0c hammer_delete_at_cursor() at hammer_delete_at_cursor+0x4e2 0x806aac62 hammer_pfs_rollback() at hammer_pfs_rollback+0x26c 0x806b0b20 hammer_ioc_destroy_pseudofs() at hammer_ioc_destroy_pseudofs+0x77 0x806b0c6c hammer_ioctl() at hammer_ioctl+0x80e 0x806a5b1e hammer_vop_ioctl() at hammer_vop_ioctl+0x58 0x806be8d3 vop_ioctl() at vop_ioctl+0x98 0x8053d244 vn_ioctl() at vn_ioctl+0xfd 0x8053a4d9 fo_ioctl() at fo_ioctl+0x46 0x804f026e mapped_ioctl() at mapped_ioctl+0x493 0x804f0725 sys_ioctl() at sys_ioctl+0x1c 0x804f07be syscall2() at syscall2+0x370 0x807814c1 Xfast_syscall() at Xfast_syscall+0xcb 0x8076ae2b (null)() at 0 0 (null)() at 0x723d524553550061 0x723d524553550061 Fatal trap 9: general protection fault while in kernel mode cpuid = 0; lapic-id = instruction pointer = 0x8:0x8077acf9 stack pointer = 0x10:0xffe09e20f010 frame pointer = 0x10:0xffe09e20f028 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 0, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 957 current thread = pri 10 kernel: type 9 trap, code=0 CPU0 stopping CPUs: 0x0002 stopped Physical memory: 3787 MB Dumping 1055 MB: 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
