zfs discuss - Sep 2006 - zfs panic: assertion failed: zp_error != 0 && dzp_error != 0

I made some powernow experiments on a dual core amd64 box, running the
64-bit debug on-20060828 kernel.  At some point the kernel seemed to
make no more progress (probably a bug in the multiprocessor powernow
code), the gui was stuck, so I typed (blind) F1-A + $<systemdump.
Writing the crashdump worked.

When the system rebooted, mounting the zfs filesystems paniced the box
with the following failed assertion; rebooting the debug kernel (both
64-bit and 32-bit) resulted in the same assertion failed panic:
> ::status
debugging crash dump vmcore.12 (32-bit) from moritz
operating system: 5.11 wos_b48_2_debug (i86pc)
panic message:
assertion failed: zp_error != 0 && dzp_error != 0, file:
../../common/fs/zfs/zfs_acl.c, line: 1537
dump content: kernel pages only
> ::stack
vpanic(fea6bfa4, f85a5984, f85a5964, 601)
assfail+0x5a(f85a5984, f85a5964, 601)
zfs_zaccess_delete+0x13a(ca45a790, ca45a670, cd1f1e78)
zfs_remove+0x88(ca453340, caa5b028, cd1f1e78)
fop_remove+0x1e(ca453340, caa5b028, cd1f1e78)
zfs_replay_remove+0x57(c94172c0, caa5b000, 0)
zil_replay_log_record+0x256(c9da24c0, ca9e2708, ca6ded54, 70cf, 0)
zil_parse+0x374(c9da24c0, 0, f8568188, ca6ded54, 70cf, 0)
zil_replay+0xba(ca454f88, c94172c0, c94172e4, c50b2c6c, f8572ba0)
zfs_domount+0x24a(c58cbf00, c79e89c0, cd1f1588)
zfs_mount+0x109(c58cbf00, ca6e4c00, ca6def84, cd1f1588)
fsop_mount+0x1a(c58cbf00, ca6e4c00, ca6def84, cd1f1588)
domount+0x8ad(0, ca6def84, ca6e4c00, cd1f1588, ca6def48)
mount+0x6f(ca6def84, ca6def68)
syscall_ap+0x4d()
sys_sysenter+0x1a2()


Now I see that exactly the same panic with identical stack backtrace
has already filed as bug 6466374, 
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6466374

But why is bug 6466374 closed as a duplicate of bug 6413510?

I''d say that bugs 6466374 and 6413510 are about completely different
issues...

When looking at the code in zfs_zaccess_delete() and zfs_zaccess_common(), 
it seems that when replaying a "remove" from the log, a debug version
of the zfs
filesystem module always panics with the "zp_error != 0 &&
dzp_error != 0"
failed assertion.
 
 
This message posted from opensolaris.org

J?rgen Keil wrote On 09/04/06 05:24,:
> I made some powernow experiments on a dual core amd64 box, running the
> 64-bit debug on-20060828 kernel.  At some point the kernel seemed to
> make no more progress (probably a bug in the multiprocessor powernow
> code), the gui was stuck, so I typed (blind) F1-A + $<systemdump.
> Writing the crashdump worked.
> 
> When the system rebooted, mounting the zfs filesystems paniced the box
> with the following failed assertion; rebooting the debug kernel (both
> 64-bit and 32-bit) resulted in the same assertion failed panic:
> 
> 
>>::status
> 
> debugging crash dump vmcore.12 (32-bit) from moritz
> operating system: 5.11 wos_b48_2_debug (i86pc)
> panic message:
> assertion failed: zp_error != 0 && dzp_error != 0, file:
../../common/fs/zfs/zfs_acl.c, line: 1537
> dump content: kernel pages only
> 
>>::stack
> 
> vpanic(fea6bfa4, f85a5984, f85a5964, 601)
> assfail+0x5a(f85a5984, f85a5964, 601)
> zfs_zaccess_delete+0x13a(ca45a790, ca45a670, cd1f1e78)
> zfs_remove+0x88(ca453340, caa5b028, cd1f1e78)
> fop_remove+0x1e(ca453340, caa5b028, cd1f1e78)
> zfs_replay_remove+0x57(c94172c0, caa5b000, 0)
> zil_replay_log_record+0x256(c9da24c0, ca9e2708, ca6ded54, 70cf, 0)
> zil_parse+0x374(c9da24c0, 0, f8568188, ca6ded54, 70cf, 0)
> zil_replay+0xba(ca454f88, c94172c0, c94172e4, c50b2c6c, f8572ba0)
> zfs_domount+0x24a(c58cbf00, c79e89c0, cd1f1588)
> zfs_mount+0x109(c58cbf00, ca6e4c00, ca6def84, cd1f1588)
> fsop_mount+0x1a(c58cbf00, ca6e4c00, ca6def84, cd1f1588)
> domount+0x8ad(0, ca6def84, ca6e4c00, cd1f1588, ca6def48)
> mount+0x6f(ca6def84, ca6def68)
> syscall_ap+0x4d()
> sys_sysenter+0x1a2()
> 
> 
> Now I see that exactly the same panic with identical stack backtrace
> has already filed as bug 6466374, 
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6466374
> 
> But why is bug 6466374 closed as a duplicate of bug 6413510?
Only because that bug contained the fix for the problem as during testing
I also found the bug. In retrospect we should have opened a new bug for
this zfs_zaccess_delete() bug, but chose just to fix it immediately.
> 
> I''d say that bugs 6466374 and 6413510 are about completely
different
> issues...
Yes, indeed.
> 
> When looking at the code in zfs_zaccess_delete() and zfs_zaccess_common(), 
> it seems that when replaying a "remove" from the log, a debug
version of the zfs
> filesystem module always panics with the "zp_error != 0 &&
dzp_error != 0"
> failed assertion.
Agreed.

Sorry about the problems.
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
-- 

Neil