kern/60458: panic during zfs send: arc_decompress assertion failure

["vezhlys%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60458
>Category:       kern
>Synopsis:       panic during zfs send: arc_decompress assertion failure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 18 09:15:00 +0000 2026
>Originator:     Andrius V
>Release:        NetBSD 11.0 RC5
>Organization:
>Environment:
NetBSD agraphic-nas3 11.0_RC5 NetBSD 11.0_RC5 (GENERIC) #0: Sun Jun 28 15:29:02 UTC 2026  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
I was trying to replicate zfs snapshot between two pools. In several attempts received the same kernel panic (it was running for a while but eventually crashes):

panic: solaris assert: arc_decompress(buf) == 0 (0x5 == 0x0), file: /usr/src/sys/../external/cddl/osnet/dist/uts/common/fs/zfs/arc.c, line: 4962
cpu5: Begin traceback...
vpanic() at netbsd:vpanic+0x171
panic() at netbsd:panic+0x3c
arc_read() at zfs:arc_read+0x9da
dmu_send_impl() at zfs:dmu_send_impl+0x4ba
() at zfs:dmu_send_obj+0x18d
zfs_ioc_send() at zfs:zfs_ioc_send+0x88
zfsdev_ioctl() at zfs:zfsdev_ioctl+0x8aa
nb_zfsdev_ioctl() at zfs:nb_zfsdev_ioctl+0x38
cdev_ioctl() at netbsd:cdev_ioctl+0x9b
spec_ioctl() at netbsd:spec_ioctl+0x59
VOP_IOCTL() at netbsd:VOP_IOCTL+0x47
vn_ioctl() at netbsd:vn_ioctl+0xaa
sys_ioctl() at netbsd:sys_ioctl+0x4ca
syscall() at netbsd:syscall+0x9a
--- syscall (number 54) ---
netbsd:syscall+0x9a:
cpu5: End traceback...

command:
sudo zfs send wddatapool/wddata@initial-backup | \ sudo zfs receive -u wddatabackup/wddata
compression and dedup is on on main dataset, on backup only compression.

main pool:
mirror-0  ONLINE       0     0     0
    dk12    ONLINE       0     0     0
    dk13    ONLINE       0     0     0

backup pool:
dk14      ONLINE       0     0     0
dk15      ONLINE       0     0     0

I can see that PR kern/57024 had same assertion failure but was closed by Taylor as potentially hardware issue. 
Trace and probably use case was different though.

Both pools use HDDs. backup is connected through USB 3 (using HDD dock). Main are connected to SATA ports. System is on SSD drive (SATA).
from dmesg:
wd0 at atabus0 drive 0
wd0: <KINGSTON SKC400S37512G>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 476 GB, 992277 cyl, 16 head, 63 sec, 512 bytes/sect x 1000215216 sectors
wd0: GPT GUID: d220d34c-d8d6-44a9-8a2a-09818d238115
dk8 at wd0: "8baeac2c-5905-4005-a876-f61c560390f8", 262144 blocks at 2048, type: msdos
dk9 at wd0: "nasroot", 724992000 blocks at 264192, type: ffs
dk10 at wd0: "nashome", 242522112 blocks at 725258240, type: ffs
dk11 at wd0: "nasswap", 32434831 blocks at 967780352, type: swap
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags)
wd1 at atabus1 drive 0
wd1: <TOSHIBA MG08ACA16TE>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 14902 GB, 31003729 cyl, 16 head, 63 sec, 512 bytes/sect x 31251759104 sectors (4096 bytes/physsect)
wd1: GPT GUID: 30c0ccbf-13ec-43d1-b48d-b3373ce4fd86
dk12 at wd1: "wddata", 31251750912 blocks at 4096, type: zfs
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO
wd1(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) w/PRIO
wd2 at atabus10 drive 0
wd2: <TOSHIBA MG08ACA16TE>
wd2: drive supports 16-sector PIO transfers, LBA48 addressing
wd2: 14902 GB, 31003729 cyl, 16 head, 63 sec, 512 bytes/sect x 31251759104 sectors (4096 bytes/physsect)
wd2: GPT GUID: 12d6a6bd-31de-4940-958c-f9eb4e131a57
dk13 at wd2: "sgdata", 31251750912 blocks at 4096, type: zfs
wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO
wd2(ahcisata1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) w/PRIO
swwdog0: software watchdog initialized

...
umass2 at uhub0 port 1 configuration 1 interface 0
umass2: ASMedia (0x174c) IB-1232CL-U3 (0x55aa), rev 3.00/1.00, addr 2
umass2: using SCSI over Bulk-Only
scsibus2 at umass2: 2 targets, 2 luns per target
sd2 at scsibus2 target 0 lun 0: <, IB-1232CL-U3, 0> disk fixed
sd2: 5589 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 11721045168 sectors (4096 bytes/physsect)
sd2: GPT GUID: 257256f3-c58f-4369-9a41-023641d9024a
dk14 at sd2: "43a465e7-c1f6-4dcb-98c8-6762b0424714", 11721043087 blocks at 2048, type: zfs
sd3 at scsibus2 target 0 lun 1: <, IB-1232CL-U3, 0> disk fixed
sd3: 5589 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 11721045168 sectors (4096 bytes/physsect)
sd3: GPT GUID: db277c66-7637-4806-adb5-70863dd1e4f0
dk15 at sd3: "c5a9146e-fcc1-40d1-ac27-892d1433e00e", 11721043087 blocks at 2048, type: zfs
dk14 at sd2 (43a465e7-c1f6-4dcb-98c8-6762b0424714) deleted
dk15 at sd3 (c5a9146e-fcc1-40d1-ac27-892d1433e00e) deleted
sd2: GPT GUID: a358f292-eb36-4fe5-b78d-3be58f211f07
dk14 at sd2: "97c0279c-332b-4d81-a8b9-f40c5e66d360", 11721043087 blocks at 2048, type: zfs
sd3: GPT GUID: f9fe4513-0cdc-44d8-baa4-8b571535623d
dk15 at sd3: "69ca3729-edd5-4e2e-8127-4db8d6d336e7", 11721043087 blocks at 2048, type: zfs

>How-To-Repeat:
Try to replicate a snapshot with bigger amount of data(?) (terabytes).
>Fix:
N/A