Bug #2396

Latest 3.1 development version core dumps while destroying master PFS

Added by sgeorge almost 2 years ago. Updated about 1 year ago.

Status:FeedbackStart date:07/18/2012
Priority:HighDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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

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 0xffffffe09e20f178
panic() at panic+0x1fb 0xffffffff804bef68
panic() at panic+0x1fb 0xffffffff804bef68
hammer_blockmap_free() at hammer_blockmap_free+0x2e5 0xffffffff80691a0c
hammer_delete_at_cursor() at hammer_delete_at_cursor+0x4e2 0xffffffff806aac62
hammer_pfs_rollback() at hammer_pfs_rollback+0x26c 0xffffffff806b0b20
hammer_ioc_destroy_pseudofs() at hammer_ioc_destroy_pseudofs+0x77 0xffffffff806b0c6c
hammer_ioctl() at hammer_ioctl+0x80e 0xffffffff806a5b1e
hammer_vop_ioctl() at hammer_vop_ioctl+0x58 0xffffffff806be8d3
vop_ioctl() at vop_ioctl+0x98 0xffffffff8053d244
vn_ioctl() at vn_ioctl+0xfd 0xffffffff8053a4d9
fo_ioctl() at fo_ioctl+0x46 0xffffffff804f026e
mapped_ioctl() at mapped_ioctl+0x493 0xffffffff804f0725
sys_ioctl() at sys_ioctl+0x1c 0xffffffff804f07be
syscall2() at syscall2+0x370 0xffffffff807814c1
Xfast_syscall() at Xfast_syscall+0xcb 0xffffffff8076ae2b
(null)() at 0 0
(null)() at 0x723d524553550061 0x723d524553550061

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; lapic->id = 00000000
instruction pointer = 0x8:0xffffffff8077acf9
stack pointer = 0x10:0xffffffe09e20f010
frame pointer = 0x10:0xffffffe09e20f028
code segment = base 0x0, limit 0xfffff, 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: 0x00000002
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

History

#1 Updated by sgeorge almost 2 years ago

  • Status changed from New to Feedback

The link to PFS of Data links strangely :-(

dfly-bkpsrv1# ls -l
total 0
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 Data -> @@0x0000000000000001:00008
lrwxr-xr-x 1 root wheel 10 Nov 24 2011 VersionControl -> @@-1:00011
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 home -> @@-1:00004
lrwxr-xr-x 1 root wheel 10 Nov 24 2011 mysql-hot -> @@-1:00009
lrwxr-xr-x 1 root wheel 10 Nov 24 2011 project-docs -> @@-1:00010
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 tmp -> @@-1:00002
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 usr -> @@-1:00003
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 usr.obj -> @@-1:00005
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 var -> @@-1:00001
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 var.crash -> @@-1:00006
lrwxr-xr-x 1 root wheel 10 Nov 23 2011 var.tmp -> @@-1:00007
lrwxr-xr-x 1 root wheel 10 Nov 24 2011 www-hot -> @@-1:00014

#2 Updated by tuxillo about 1 year ago

Siju,

What happened to this one? Did you arrange it on #dragonflybsd?

Cheers,
Antonio Huete

Also available in: Atom PDF