NetBSD Problem Report #59663
From www@netbsd.org Sun Sep 21 07:26:30 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id A19091A923F
for <gnats-bugs@gnats.NetBSD.org>; Sun, 21 Sep 2025 07:26:30 +0000 (UTC)
Message-Id: <20250921072628.C084D1A9241@mollari.NetBSD.org>
Date: Sun, 21 Sep 2025 07:26:28 +0000 (UTC)
From: hpaluch@seznam.cz
Reply-To: hpaluch@seznam.cz
To: gnats-bugs@NetBSD.org
Subject: ffs_snapshot_read -> uvm_fault (or pool page empty) doing dump/restore with snapshot
X-Send-Pr-Version: www-1.0
>Number: 59663
>Category: kern
>Synopsis: ffs_snapshot_read -> uvm_fault (or pool page empty) doing dump/restore with snapshot
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Sep 21 07:30:03 +0000 2025
>Last-Modified: Thu Sep 25 14:45:01 +0000 2025
>Originator: Henryk Paluch
>Release: 11.0_BETA 20250916040529Z
>Organization:
N/A
>Environment:
NetBSD nbsd11-4zotac.example.com 11.0_BETA NetBSD 11.0_BETA (GENERIC) #0: Tue Sep 16 04:05:29 UTC 2025 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
Having NetBSD 11.0_BETA guest (Host is Linux KVM, openSUSE LEAP 15.6).
1. NetBSD installed on Virtio-BLK disk ld0 64GB
2. target ld1 is 500GB SATA SSD attached to host via USB JMicron adapter, exposed as Virtio-BLK /dev/sdb block device from host
When I bulk copy lot of data (46GB) using dump/restore with snapshot I will after while get panic:
uvm_fault(0xffffffff81976c20, 0x0, 1) -> e
[ 883.0589643] fatal page fault in supervisor mode
[ 883.0589643] trap type 6 code 0 rip 0xffffffff80e261f3 cs 0x8 rflags 0x10202 cr2 0x9 ilevel 0 rsp 0xffff9d04c49d4c10
[ 883.0589643] curlwp 0xffff8b60ae5fe400 pid 0.1215 lowest kstack 0xffff9d04c49d02c0
kernel: page fault trap, code=0
Stopped in pid 0.1215 (system) at netbsd:pool_get+0x2b9: cmpq %r15,8(%
rax)
pool_get() at netbsd:pool_get+0x2b9
allocbuf() at netbsd:allocbuf+0x113
getblk() at netbsd:getblk+0x18c
bio_doread() at netbsd:bio_doread+0x1d
breadn() at netbsd:breadn+0x8b
ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
VOP_READ() at netbsd:VOP_READ+0x42
vn_rdwr() at netbsd:vn_rdwr+0xf1
fss_bs_io() at netbsd:fss_bs_io+0x89
fss_bs_thread() at netbsd:fss_bs_thread+0x50f
ds 1
es e400
fs 4bf0
gs 5ff8
rdi ffffffff819835e0 bmempools+0x7e0
rsi 2
rbp ffff9d04c49d4c70
rbx ffffffff81983530 bmempools+0x730
rdx ffffffff
rcx 0
--db_more-- rax 1
r8 0
r9 ffff9d04cbea0030
r10 fffffffe
r11 0
r12 2
r13 ffffffff819835e0 bmempools+0x7e0
r14 ffff9d04cbea0c00
r15 ffff9d04cbea0000
rip ffffffff80e261f3 pool_get+0x2b9
cs 8
rflags 10202
rsp ffff9d04c49d4c10
ss 10
netbsd:pool_get+0x2b9: cmpq %r15,8(%rax)
db{0}> ?
Because there is ffs_snapshot_read() right before panic I suspect that it somehow exhaust all buffers.
Below is output from: vmstat -M netbsd.2.core -N netbsd.2 -m
Memory resource pool statistics
Name Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
amappl 128 1171 0 130 36 1 35 36 0 inf 0
anonpl 40 76445 0 576 755 0 755 755 0 inf 0
biopl 280 54387 0 42890 1176 354 822 971 0 inf 0
buf16k 16896 183710 0 180200 50961 49790 1171 35313 0 inf 0
buf1k 1536 2 0 2 2 1 1 2 0 inf 1
buf2k 2048 372 0 344 187 172 15 173 0 inf 1
buf32k 32768 16466 0 4355 6893 837 6056 6064 0 inf 0
buf4k 4096 280578 0 173240 280579 173240 107339 226999 0 inf 1
buf512b 1024 3 0 3 1 0 1 1 0 inf 1
buf64k 65536 6 0 2 7 2 5 7 0 inf 1
buf8k 8704 1143 0 745 75 18 57 65 0 inf 0
bufpl 280 256490 0 133102 16813 5064 11749 16813 0 inf 0
dirhash 376 2262 0 411 186 0 186 186 0 inf 0
dirhashblk 2048 7684 0 1147 3269 0 3269 3269 0 inf 0
ehcixfer 376 4 0 3 1 0 1 1 0 inf 0
execargs 262144 243 0 243 8 7 1 4 0 16 1
ffsdino2 264 980776 0 155749 55861 0 55861 55861 0 inf 859
ffsino 280 980333 0 155306 59851 0 59851 59851 0 inf 920
file 128 275 0 81 8 0 8 8 0 inf 0
filedesc 832 119 0 86 28 10 18 28 0 inf 0
fstlwp 128 149 0 59 4 0 4 4 0 inf 0
in4pcbpl 256 13 0 7 1 0 1 1 0 inf 0
in6pcbpl 320 11 0 8 1 0 1 1 0 inf 0
inmltpl 56 2 0 0 1 0 1 1 0 inf 0
kcredpl 192 85 0 22 4 0 4 4 0 inf 0
kmem-00016 16 2209 0 301 8 0 8 8 0 inf 0
kmem-00032 32 3652 0 440 26 0 26 26 0 inf 0
kmem-00064 128 9172 0 6193 292 170 122 292 0 inf 0
kmem-00128 192 1907040 0 250751 80096 2 80094 80096 0 inf 1223
kmem-00192 256 362516 0 50703 20293 804 19489 20251 0 inf 0
kmem-00256 320 430 0 89 30 0 30 30 0 inf 0
kmem-00320 384 743 0 76 72 0 72 72 0 inf 0
kmem-00384 448 669 0 106 73 3 70 73 0 inf 0
kmem-00448 512 157 0 56 18 0 18 18 0 inf 0
kmem-00512 576 113 0 58 14 1 13 14 0 inf 0
kmem-00768 832 344 0 66 83 3 80 83 0 inf 0
kmem-01024 1088 723 0 47 238 0 238 238 0 inf 0
kmem-02048 2048 710 0 231 259 19 240 253 0 inf 0
kmem-04096 4096 121 0 30 116 25 91 115 0 inf 0
ksiginfo 136 359 0 260 5 1 4 4 0 inf 0
kva-12288 12288 526 0 7 26 0 26 26 0 inf 0
kva-16384 16384 11 0 8 1 0 1 1 0 inf 0
kva-20480 20480 17 0 10 2 1 1 2 0 inf 0
kva-24576 24576 1 0 1 1 1 0 1 0 inf 0
kva-28672 28672 10 0 0 2 0 2 2 0 inf 0
kva-32768 32768 3 0 2 1 0 1 1 0 inf 0
kva-36864 36864 77 0 0 11 0 11 11 0 inf 0
kva-65536 65536 2 0 0 1 0 1 1 0 inf 0
kva-8192 8192 27 0 7 1 0 1 1 0 inf 0
llentrypl 280 1 0 0 1 0 1 1 0 inf 0
lwppl 1024 182 0 15 45 0 45 45 0 inf 0
mbpl 520 1032 0 579 73 6 67 68 0 inf 2
mclpl 2048 1043 0 592 242 12 230 234 0 261831 4
msdosnopl 208 3 0 2 3 2 1 1 0 inf 0
namecache 192 885618 0 75876 38560 0 38560 38560 0 inf 0
pcache 2688 92 0 4 88 0 88 88 0 inf 0
pcachecpu 128 651 0 0 21 0 21 21 0 inf 0
pcglarge 1088 740 0 629 56 19 37 46 0 inf 0
pcgnormal 320 200584 0 197957 3795 1976 1819 3020 0 inf 1193
pdict16 80 262 0 216 1 0 1 1 0 inf 0
pdict32 96 11 0 1 1 0 1 1 0 inf 0
pdppl 4096 122 0 87 115 80 35 114 0 inf 0
phpool-128 72 26 0 0 1 0 1 1 0 inf 0
phpool-256 88 8 0 0 1 0 1 1 0 inf 0
phpool-64 64 313108 0 175253 4007 577 3430 4007 0 inf 0
piperd 256 19 0 13 2 1 1 2 0 inf 0
pipewr 256 52 0 45 4 1 3 4 0 inf 0
pmappl 512 122 0 87 15 2 13 15 0 inf 0
procpl 896 50 0 16 12 1 11 12 0 inf 0
proparay 56 117 0 0 2 0 2 2 0 inf 0
propdict 56 447 0 107 5 0 5 5 0 inf 0
propnmbr 64 47 0 3 1 0 1 1 0 inf 0
propstng 72 742 0 558 4 0 4 4 0 inf 0
pvpage 4096 831 0 40 819 28 791 813 0 inf 0
rtentpl 320 28 0 2 3 0 3 3 0 inf 0
scxspl 264 30 0 30 1 0 1 1 1 inf 1
sigacts 3088 113 0 79 111 77 34 110 0 inf 0
socket 592 141 0 21 23 1 22 23 0 inf 0
synpl 320 1 0 1 1 1 0 1 0 inf 0
tcpcbpl 832 65 0 62 1 0 1 1 0 inf 0
thplthrd 72 3 0 2 1 0 1 1 0 inf 0
tmpfs_dirent 56 5 0 1 1 0 1 1 0 inf 0
tmpfs_node 232 7 0 1 1 0 1 1 0 inf 0
uarea 24576 49 0 15 47 13 34 46 0 inf 0
uareasys 24576 141 0 8 141 8 133 141 0 inf 0
ufsdir 272 32 0 24 1 0 1 1 0 inf 0
uhcixfer 376 3 0 2 1 0 1 1 0 inf 0
uhcixfer 376 3 0 2 1 0 1 1 0 inf 0
uhcixfer 376 3 0 2 1 0 1 1 0 inf 0
vcachepl 640 923969 0 86108 139653 0 139653 139653 0 inf 9
vmembt 64 16546 0 4964 237 0 237 237 0 inf 0
vmmpepl 192 27152 0 16682 523 24 499 499 0 inf 0
wapbldealloc 40 8 0 8 1 1 0 1 0 inf 0
wapblentrypl 48 84 0 84 2 1 1 1 0 inf 1
wapblinopl 40 176 0 175 1 0 1 1 0 inf 0
Totals 7506830 0 1718506 767003 233357 533646
In use 2459547K, total allocated 2576816K; utilization 95.4%
>How-To-Repeat:
Have disk with lot of data (46GB in my case). Clone one disk to another using dump/restore with snapshot:
newfs -O 2 /dev/dk8
mkdir /mnt/target
mount -o async /dev/dk8 /mnt/target
df -h / /mnt/target
Filesystem Size Used Avail %Cap Mounted on
/dev/dk1 58G 46G 9.5G 82% /
/dev/dk8 197G 4.0K 187G 0% /mnt/target
# commands below will trigger panic after a while (around 20GB copied):
cd /mnt/target
dump -0uaX -f - / | restore rf -
Note: my NetBSD VM has lot of RAM (16GB) and cores (8) - I guess that lowering RAM will trigger panic sooner - need to test it.
Note: the system is otherwise idle while doing dump/restore (so snapshot device should not fill).
>Fix:
N/A
Even using SCSI emulation for target disk will cause similar panic - this time not uvm_fault
but rather "pool_get: [buf16k] pool page empty" - but again FFS snapshot is involved in stacktrace:
[ 2161.615264] panic: kernel diagnostic assertion "(ph->ph_nmissing < pp->pr_itemsperpage)" failed: file "/usr/src/sys/kern/subr_pool.c", l[0/1368]
pool_get: [buf16k] pool page empty
[ 2161.625407] cpu1: Begin traceback...
[ 2161.625407] vpanic() at netbsd:vpanic+0x171
[ 2161.625407] kern_assert() at netbsd:kern_assert+0x4b
[ 2161.625407] pool_get() at netbsd:pool_get+0x7c9
[ 2161.625407] allocbuf() at netbsd:allocbuf+0x113
[ 2161.625407] getblk() at netbsd:getblk+0x18c
[ 2161.625407] bio_doread() at netbsd:bio_doread+0x1d
[ 2161.625407] breadn() at netbsd:breadn+0x8b
[ 2161.625407] ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
[ 2161.625407] VOP_READ() at netbsd:VOP_READ+0x42
[ 2161.625407] vn_rdwr() at netbsd:vn_rdwr+0xf1
[ 2161.625407] fss_bs_io() at netbsd:fss_bs_io+0x89
[ 2161.625407] fss_bs_thread() at netbsd:fss_bs_thread+0x50f
[ 2161.625407] cpu1: End traceback...
>Audit-Trail:
From: "Henryk Paluch" <hpaluch@seznam.cz>
To: <gnats-bugs@NetBSD.org>
Cc:
Subject: Subject: Re: kern/59663
Date: Tue, 23 Sep 2025 19:50:35 +0200 (CEST)
I found reliable way how to crash above "NetBSD 11.0_BETA (GENERIC) #0: Tu=
e Sep 16 04:05:29 UTC 2025" in *few seconds*.
Just these 2 commands are enough (reproducible on both VMD and bare metal)=
:
nbsd11-test3# fssconfig -cx fss0 / /root/backup
nbsd11-test3# dd if=3D/dev/fss0 of=3D/dev/null bs=3D1024k
After few seconds:
[ 58.8640367] panic: kernel diagnostic assertion "(i * BITMAP_SIZE) < pp-=
>pr_itemsperpage" failed: file "/usr/src/sys/kern/subr_pool.c", line 450 =
[ 58.8640367] cpu0: Begin traceback...
[ 58.8741603] vpanic() at netbsd:vpanic+0x171
[ 58.8741603] kern_assert() at netbsd:kern_assert+0x4b
[ 58.8741603] pool_get() at netbsd:pool_get+0x46b
[ 58.8741603] allocbuf() at netbsd:allocbuf+0x113
[ 58.8741603] getblk() at netbsd:getblk+0x18c
[ 58.8741603] bio_doread() at netbsd:bio_doread+0x1d
[ 58.8842815] breadn() at netbsd:breadn+0x24
[ 58.8842815] ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
[ 58.8842815] VOP_READ() at netbsd:VOP_READ+0x42
[ 58.8842815] vn_rdwr() at netbsd:vn_rdwr+0xf1
[ 58.8842815] fss_bs_io() at netbsd:fss_bs_io+0x89
[ 58.8842815] fss_bs_thread() at netbsd:fss_bs_thread+0x50f
[ 58.8842815] cpu0: End traceback...
[ 58.8842815] fatal breakpoint trap in supervisor mode
[ 58.8842815] trap type 1 code 0 rip 0xffffffff8023541d cs 0x8 rflags 0x2=
02 cr2 0xffff8f026ade5000 ilevel 0 rsp 0xffff8f0277ef7b70
[ 58.8955114] curlwp 0xffff8889b54f7800 pid 0.1426 lowest kstack 0xffff8f=
0277ef32c0
Stopped in pid 0.1426 (system) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x171
kern_assert() at netbsd:kern_assert+0x4b
pool_get() at netbsd:pool_get+0x46b
allocbuf() at netbsd:allocbuf+0x113
getblk() at netbsd:getblk+0x18c
bio_doread() at netbsd:bio_doread+0x1d
breadn() at netbsd:breadn+0x24
ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
VOP_READ() at netbsd:VOP_READ+0x42
vn_rdwr() at netbsd:vn_rdwr+0xf1
fss_bs_io() at netbsd:fss_bs_io+0x89
fss_bs_thread() at netbsd:fss_bs_thread+0x50f
ds 0
es 0
fs 180
gs 7b20
rdi 0
rsi 3f8
rbp ffff8f0277ef7b70
rbx ffffffff8142a670 ostype+0x7867e
rdx 1
--db_more--rcx ffffffffffffff
rax 800000000000000
r8 0
r9 0
r10 0
r11 0
r12 ffff8f0277ef7bb8
r13 104
r14 1
r15 ffff8f02670b0000
rip ffffffff8023541d breakpoint+0x5
cs 8
rflags 202
rsp ffff8f0277ef7b70
ss 10
netbsd:breakpoint+0x5: leave
db{0}> bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x171
kern_assert() at netbsd:kern_assert+0x4b
pool_get() at netbsd:pool_get+0x46b
allocbuf() at netbsd:allocbuf+0x113
getblk() at netbsd:getblk+0x18c
bio_doread() at netbsd:bio_doread+0x1d
breadn() at netbsd:breadn+0x24
ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
VOP_READ() at netbsd:VOP_READ+0x42
vn_rdwr() at netbsd:vn_rdwr+0xf1
fss_bs_io() at netbsd:fss_bs_io+0x89
fss_bs_thread() at netbsd:fss_bs_thread+0x50f
From: "Henryk Paluch" <hpaluch@seznam.cz>
To: <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: kern/59663
Date: Tue, 23 Sep 2025 20:04:20 +0200 (CEST)
I found reliable way how to crash above "NetBSD 11.0_BETA (GENERIC) #0: Tu=
e Sep 16 04:05:29 UTC 2025" in *few seconds*.
Just these 2 commands are enough (reproducible on both VM and bare metal):=
nbsd11-test3# fssconfig -cx fss0 / /root/backup
nbsd11-test3# dd if=3D/dev/fss0 of=3D/dev/null bs=3D1024k
After few seconds:
[ 58.8640367] panic: kernel diagnostic assertion "(i * BITMAP_SIZE) < pp->=
pr_itemsperpage" failed: file "/usr/src/sys/kern/subr_pool.c", line 450
[ 58.8640367] cpu0: Begin traceback...
[ 58.8741603] vpanic() at netbsd:vpanic+0x171
[ 58.8741603] kern_assert() at netbsd:kern_assert+0x4b
[ 58.8741603] pool_get() at netbsd:pool_get+0x46b
[ 58.8741603] allocbuf() at netbsd:allocbuf+0x113
[ 58.8741603] getblk() at netbsd:getblk+0x18c
[ 58.8741603] bio_doread() at netbsd:bio_doread+0x1d
[ 58.8842815] breadn() at netbsd:breadn+0x24
[ 58.8842815] ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
[ 58.8842815] VOP_READ() at netbsd:VOP_READ+0x42
[ 58.8842815] vn_rdwr() at netbsd:vn_rdwr+0xf1
[ 58.8842815] fss_bs_io() at netbsd:fss_bs_io+0x89
[ 58.8842815] fss_bs_thread() at netbsd:fss_bs_thread+0x50f
[ 58.8842815] cpu0: End traceback...
[ 58.8842815] fatal breakpoint trap in supervisor mode
[ 58.8842815] trap type 1 code 0 rip 0xffffffff8023541d cs 0x8 rflags 0x20=
2 cr2 0xffff8f026ade5000 ilevel 0 rsp 0xffff8f0277ef7b70
[ 58.8955114] curlwp 0xffff8889b54f7800 pid 0.1426 lowest kstack 0xffff8f0=
277ef32c0
Stopped in pid 0.1426 (system) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x171
kern_assert() at netbsd:kern_assert+0x4b
pool_get() at netbsd:pool_get+0x46b
allocbuf() at netbsd:allocbuf+0x113
getblk() at netbsd:getblk+0x18c
bio_doread() at netbsd:bio_doread+0x1d
breadn() at netbsd:breadn+0x24
ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
VOP_READ() at netbsd:VOP_READ+0x42
vn_rdwr() at netbsd:vn_rdwr+0xf1
fss_bs_io() at netbsd:fss_bs_io+0x89
fss_bs_thread() at netbsd:fss_bs_thread+0x50f
ds 0
es 0
fs 180
gs 7b20
rdi 0
rsi 3f8
rbp ffff8f0277ef7b70
rbx ffffffff8142a670 ostype+0x7867e
rdx 1
--db_more--rcx ffffffffffffff
rax 800000000000000
r8 0
r9 0
r10 0
r11 0
r12 ffff8f0277ef7bb8
r13 104
r14 1
r15 ffff8f02670b0000
rip ffffffff8023541d breakpoint+0x5
cs 8
rflags 202
rsp ffff8f0277ef7b70
ss 10
netbsd:breakpoint+0x5: leave
db{0}> bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x171
kern_assert() at netbsd:kern_assert+0x4b
pool_get() at netbsd:pool_get+0x46b
allocbuf() at netbsd:allocbuf+0x113
getblk() at netbsd:getblk+0x18c
bio_doread() at netbsd:bio_doread+0x1d
breadn() at netbsd:breadn+0x24
ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
VOP_READ() at netbsd:VOP_READ+0x42
vn_rdwr() at netbsd:vn_rdwr+0xf1
fss_bs_io() at netbsd:fss_bs_io+0x89
fss_bs_thread() at netbsd:fss_bs_thread+0x50f
From: Henryk Paluch <hpaluch@seznam.cz>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/59663: ffs_snapshot_read -> uvm_fault (or pool page empty)
doing dump/restore with snapshot
Date: Thu, 25 Sep 2025 16:40:31 +0200
Building my own kernel with netbsd.gdb I was able to get full backtrace
with source lines. Just enabled:
options DEBUG # expensive debugging checks/support
options LOCKDEBUG # expensive locking checks/support
Source code is:
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/20250916040529Z/source/sets/syssrc.tgz
MD5: MD5 (syssrc.tgz) = 35f104087fa2eab6ef7804f411c529cf
uname -a: NetBSD nbsd-crash3.example.com 11.0_BETA NetBSD 11.0_BETA (HP)
#0: Wed Sep 24 20:47:28 CEST 2025
root@nbsd-crash3.example.com:/usr/src/sys/arch/amd64/compile/HP amd64
Commands quickly leading to panic (few seconds):
fssconfig -cx fss0 / /root/backup
dd if=/dev/fss0 of=/dev/null bs=1024k
[ 34.9028584] panic: kernel diagnostic assertion "(i * BITMAP_SIZE) <
pp->pr_itemsperpage" failed: file "../../../../kern/subr_pool.c", line 450
[ 34.9129630] cpu1: Begin traceback...
[ 34.9129630] vpanic() at netbsd:vpanic+0x171
[ 34.9129630] kern_assert() at netbsd:kern_assert+0x4b
[ 34.9129630] pool_get() at netbsd:pool_get+0x496
[ 34.9129630] allocbuf() at netbsd:allocbuf+0x113
[ 34.9129630] getblk() at netbsd:getblk+0x18c
[ 34.9129630] bio_doread() at netbsd:bio_doread+0x1d
[ 34.9129630] breadn() at netbsd:breadn+0x24
[ 34.9230632] ffs_snapshot_read() at netbsd:ffs_snapshot_read+0x1b2
[ 34.9230632] VOP_READ() at netbsd:VOP_READ+0x42
[ 34.9230632] vn_rdwr() at netbsd:vn_rdwr+0xf1
[ 34.9230632] fss_bs_io() at netbsd:fss_bs_io+0x89
[ 34.9230632] fss_bs_thread() at netbsd:fss_bs_thread+0x50f
[ 34.9230632] cpu1: End traceback...
[ 34.9230632] fatal breakpoint trap in supervisor mode
[ 34.9230632] trap type 1 code 0 rip 0xffffffff8023541d cs 0x8 rflags
0x202 cr2 0x764ef540bce0 ilevel 0 rsp 0xffffcf0154c99b70
[ 34.9331650] curlwp 0xffff8591f760f000 pid 0.1320 lowest kstack
0xffffcf0154c952c0
Stacktrace from gdb:
Reading symbols from /usr/src/sys/arch/amd64/compile/HP/netbsd.gdb...
+target kvm netbsd.0.core
0xffffffff80239b95 in cpu_reboot (howto=howto@entry=256,
bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:709
709 dumpsys();
+bt
#0 0xffffffff80239b95 in cpu_reboot (howto=howto@entry=256,
bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:709
#1 0xffffffff80df1efe in kern_reboot (howto=howto@entry=256,
bootstr=bootstr@entry=0x0) at ../../../../kern/kern_reboot.c:91
#2 0xffffffff80b6c1d4 in db_sync_cmd (addr=<optimized out>,
have_addr=<optimized out>, count=<optimized out>, modif=<optimized out>)
at ../../../../ddb/db_command.c:1651
#3 0xffffffff80b6c9c4 in db_command
(last_cmdp=last_cmdp@entry=0xffffffff81a74220 <db_last_command>) at
../../../../ddb/db_command.c:970
#4 0xffffffff80b6ce53 in db_command_loop () at
../../../../ddb/db_command.c:629
#5 0xffffffff80b7119d in db_trap (type=type@entry=1, code=code@entry=0)
at ../../../../ddb/db_trap.c:91
#6 0xffffffff80236a1b in kdb_trap (type=type@entry=1,
code=code@entry=0, regs=regs@entry=0xffffcf0154c99a80) at
../../../../arch/amd64/amd64/db_interface.c:251
#7 0xffffffff8023bf96 in trap (frame=0xffffcf0154c99a80) at
../../../../arch/amd64/amd64/trap.c:314
#8 0xffffffff80234ad4 in alltraps ()
#9 0xffffffff8023541d in breakpoint ()
#10 0xffffffff80e3a289 in vpanic (fmt=0xffffffff8162d8f8 "kernel
%sassertion \"%s\" failed: file \"%s\", line %d ",
ap=ap@entry=0xffffcf0154c99bb8) at ../../../../kern/subr_prf.c:286
#11 0xffffffff8100c76e in kern_assert (fmt=fmt@entry=0xffffffff8162d8f8
"kernel %sassertion \"%s\" failed: file \"%s\", line %d ") at
../../../../../../lib/libkern/kern_assert.c:51
#12 0xffffffff80e34f33 in pr_item_bitmap_get (ph=0xffffcf0144320000,
pp=0xffffffff81b9c790 <bmempools+1840>) at ../../../../kern/subr_pool.c:450
#13 pool_get (pp=pp@entry=0xffffffff81b9c790 <bmempools+1840>,
flags=flags@entry=2) at ../../../../kern/subr_pool.c:1217
#14 0xffffffff80e8fca1 in buf_alloc (size=<optimized out>) at
../../../../kern/vfs_bio.c:652
#15 allocbuf (bp=bp@entry=0xffff8591dc3211b0, size=size@entry=16384,
preserve=preserve@entry=0) at ../../../../kern/vfs_bio.c:1337
#16 0xffffffff80e90cb3 in getblk (vp=vp@entry=0xffff8591f190d840,
blkno=16516, size=size@entry=16384, slpflag=slpflag@entry=0,
slptimeo=slptimeo@entry=0) at ../../../../kern/vfs_bio.c:1262
#17 0xffffffff80e90f05 in bio_doread (vp=vp@entry=0xffff8591f190d840,
blkno=<optimized out>, size=size@entry=16384, async=async@entry=0) at
../../../../kern/vfs_bio.c:692
#18 0xffffffff80e9115e in breadn (vp=vp@entry=0xffff8591f190d840,
blkno=<optimized out>, size=size@entry=16384,
rablks=rablks@entry=0xffffcf0154c99dd8,
rasizes=rasizes@entry=0xffffcf0154c99dcc, nrablks=nrablks@entry=1,
flags=flags@entry=0, bpp=bpp@entry=0xffffcf0154c99dd0) at
../../../../kern/vfs_bio.c:783
#19 0xffffffff80d2bef4 in ffs_snapshot_read (vp=0xffff8591f190d840,
uio=0xffffcf0154c99e90, ioflag=<optimized out>) at
../../../../ufs/ffs/ffs_snapshot.c:2104
#20 0xffffffff80ebe5b2 in VOP_READ (vp=0xffff8591f190d840,
uio=<optimized out>, ioflag=<optimized out>, cred=<optimized out>) at
../../../../kern/vnode_if.c:785
#21 0xffffffff80eb5737 in vn_rdwr (rw=rw@entry=UIO_READ,
vp=0xffff8591f190d840, base=base@entry=0xffff8591dba51000,
len=len@entry=2048, offset=offset@entry=270600192,
segflg=segflg@entry=UIO_SYSSPACE, ioflg=ioflg@entry=129,
cred=0xffff8591f8725040, aresid=0xffffcf0154c99fb8, l=0x0) at
../../../../kern/vfs_vnops.c:558
#22 0xffffffff80edd2c6 in fss_bs_io (sc=sc@entry=0xffff8591f7380ac0,
rw=rw@entry=FSS_READ, cl=cl@entry=0, off=270600192, len=2048,
data=0xffff8591dba51000, resid=resid@entry=0xffffcf0154c99fb8) at
../../../../dev/fss.c:1100
#23 0xffffffff80eddb06 in fss_bs_thread (arg=0xffff8591f7380ac0) at
../../../../dev/fss.c:1198
#24 0xffffffff80210327 in lwp_trampoline ()
#25 0x0000000000000000 in ?? ()
+q
Please note that quite often I get various uvm_traps when accessing pool
which often prevents me to dump core at all.
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2025
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home