NetBSD Problem Report #59618
From www@netbsd.org Sat Aug 30 11:58:40 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) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 525CC1A923E
for <gnats-bugs@gnats.NetBSD.org>; Sat, 30 Aug 2025 11:58:40 +0000 (UTC)
Message-Id: <20250830115838.A19981A923F@mollari.NetBSD.org>
Date: Sat, 30 Aug 2025 11:58:38 +0000 (UTC)
From: cmeerw@cmeerw.org
Reply-To: cmeerw@cmeerw.org
To: gnats-bugs@NetBSD.org
Subject: occasional virtio block device lock ups/hangs
X-Send-Pr-Version: www-1.0
>Number: 59618
>Notify-List: riastradh@NetBSD.org
>Category: kern
>Synopsis: occasional virtio block device lock ups/hangs
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: riastradh
>State: pending-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Aug 30 12:00:00 +0000 2025
>Closed-Date:
>Last-Modified: Sun Oct 19 13:55:01 +0000 2025
>Originator: Christof Meerwald
>Release: 10.1
>Organization:
>Environment:
NetBSD linveo.cmeerw.net 10.1 NetBSD 10.1 (GENERIC) #22: Sat Aug 30 11:23:19 UTC 2025 cmeerw@linveo.cmeerw.net:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
AMD64 VPS locks up due to missing virtio block device notifications, see thread starting https://mail-index.netbsd.org/netbsd-users/2025/04/08/msg032527.html
db(0)> bt/a ffffdadd0c6dc500
trace: pid 0 lid 195 at 0xffff8981544e0d60
sleepq_block() at netbsd:sleepq_block+0x13a
cv_wait() at netbsd:cv_wait+0xb7
biowait() at netbsd:biowait+0x42
wapbl_buffered_flush() at netbsd:wapbl_buffered_flush+0xa2
wapbl_write_commit() at netbsd:wapbl_write_commit+0x28
wapbl_flush() at netbsd:wapbl_flush+0x552
ffs_sync() at netbsd:ffs_sync+0x176
VFS_SYNC() at netbsd:VFS_SYNC+0x22
sched_sync() at netbsd:sched_sync+0x90
db(0)>
This might be a lot more common on AMD Zen 5 (maybe also Zen 4?) architectures, in my case the VPS is running on an AMD Ryzen 9 9950X 16-Core Processor with 2 cores assigned to the VPS.
From https://mail-index.netbsd.org/netbsd-users/2025/08/29/msg033025.html:
In virtio.c we essentially have
vq->vq_avail->idx = virtio_rw16(sc, vq->vq_avail_idx);
vq_sync_aring_header(sc, vq, BUS_DMASYNC_PREWRITE);
vq_sync_uring_header(sc, vq, BUS_DMASYNC_POSTREAD);
flags = virtio_rw16(sc, vq->vq_used->flags);
where the BUS_DMASYNC_PREWRITE is a sfence and BUS_DMASYNC_PREWRITE is
an lfence, so we have:
vq->vq_avail->idx = virtio_rw16(sc, vq->vq_avail_idx);
x86_sfence();
x86_lfence();
flags = virtio_rw16(sc, vq->vq_used->flags);
And https://stackoverflow.com/a/50322404 argues that the store and
load can be reordered here, and this appears to be exactly what I am
seeing.
>How-To-Repeat:
In a VPS with a virtio block device running on and AMD Zen 5 CPU run frequent syncs, e.g.
while sleep 0.4; do echo Hello >~/stress.txt; sync; rm ~/stress.txt; done
it might lock up after a few hours (maybe up to 2 days).
>Fix:
Add a full memory fence between the "vq->vq_avail_idx" store and the "vq->vq_used->flags" load
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: cmeerw@cmeerw.org
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org, thorpej@NetBSD.org
Subject: Re: kern/59618: occasional virtio block device lock ups/hangs
Date: Sat, 30 Aug 2025 14:08:19 +0000
tl;dr: We need a machine-independent store-before-load barrier for
virtual DMA rings. Not membar_sync, because that's a noop on a single
vCPU and we may be coordinating with a host on another pCPU.
Could make it specific to virtio but it's also needed by hyperv (where
we abuse membar_sync) and Xen (where it's called xen_mb) so bus_dma or
some other part of the kernel API might be a better place.
> Date: Sat, 30 Aug 2025 11:58:38 +0000 (UTC)
> From: Christof Meerwald <cmeerw@cmeerw.org>
>=20
> In virtio.c we essentially have
>=20
> vq->vq_avail->idx =3D virtio_rw16(sc, vq->vq_avail_idx);
> vq_sync_aring_header(sc, vq, BUS_DMASYNC_PREWRITE);
>=20
> vq_sync_uring_header(sc, vq, BUS_DMASYNC_POSTREAD);
> flags =3D virtio_rw16(sc, vq->vq_used->flags);
>=20
> where the BUS_DMASYNC_PREWRITE is a sfence and BUS_DMASYNC_PREWRITE is
> an lfence, so we have:
>=20
> vq->vq_avail->idx =3D virtio_rw16(sc, vq->vq_avail_idx);
> x86_sfence();
>=20
> x86_lfence();
> flags =3D virtio_rw16(sc, vq->vq_used->flags);
>=20
> And https://stackoverflow.com/a/50322404 argues that the store and
> load can be reordered here, and this appears to be exactly what I am
> seeing.
>=20
> [...]
> >Fix:
> Add a full memory fence between the "vq->vq_avail_idx" store and the "vq-=
>vq_used->flags" load
I think this analysis is right (likewise for the
VIRTIO_F_RING_EVENT_IDX branch), and I'm embarrassed to have missed it
when I did a virtio(4) membar audit three years ago!
https://mail-index.netbsd.org/source-changes/2022/08/12/msg140222.html
A better reference is:
AMD64 Architecture Programmer's Manual, Volume 2: System Programming,
24593--Rev. 3.38--November 2021, Sec. 7.4.2 Memory Barrier Interaction
with Memory Types, Table 7-3, p. 196.
https://web.archive.org/web/20220625040004/https://www.amd.com/system/files=
/TechDocs/24593.pdf#page=3D256
The same problem likely appears in virtio_start_vq_intr:
696 if (sc->sc_active_features & VIRTIO_F_RING_EVENT_IDX) {
...
702 *vq->vq_used_event =3D virtio_rw16(sc, vq->vq_used_idx);
703 vq_sync_aring_used(sc, vq, BUS_DMASYNC_PREWRITE);
704 } else {
705 vq->vq_avail->flags &=3D
706 ~virtio_rw16(sc, VRING_AVAIL_F_NO_INTERRUPT);
707 vq_sync_aring_header(sc, vq, BUS_DMASYNC_PREWRITE);
708 }
...
=3D> 711 vq_sync_uring_header(sc, vq, BUS_DMASYNC_POSTREAD);
712 if (vq->vq_used_idx =3D=3D virtio_rw16(sc, vq->vq_used->idx))
713 return 0;
714 vq_sync_uring_payload(sc, vq, BUS_DMASYNC_POSTREAD);
https://nxr.netbsd.org/xref/src/sys/dev/pci/virtio.c?r=3D1.83#692
The store to *vq->vq_used_event or vq->vq_avail->flags must be ordered
before the load from vq->vq_used->idx.
Unfortunately, bus_dma doesn't have a machine-independent concept of a
store-before-load barrier, which is generally needed for idioms of the
form
ring->cpu_producer_index++;
...
if (!ring->device_consumer_is_running)
notify_device();
or
ring->cpu_consuming_interrupts =3D true;
...
if (ring->device_interrupts_pending)
handle_interrupts();
It is _not_ correct to insert membar_sync in the ellipsis, because the
guest may be running with a single _virtual_ CPU and patch away the
barrier inside membar_sync, while the host may be running on another
_physical_ CPU so the virtio driver still requires the barrier.
We really need to create a different machine-independent abstraction
for this. We could create a virtio_membar_sync() like OpenBSD uses
but I suspect this may be relevant beyond virtio(4), so perhaps it
should live in bus_dma or elsewhere in the kernel API. In some bus
dma tags it might be elidable, if the memory is mapped uncached by
those tags.
For Xen we have the xen_mb macro, used in the corresponding ring
producer/consumer logic (but no bus_dma):
295 #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do { =
\
296 RING_IDX __old =3D (_r)->sring->req_prod; =
\
297 RING_IDX __new =3D (_r)->req_prod_pvt; =
\
298 xen_wmb(); /* back sees requests /before/ updated producer inde=
x */ \
299 (_r)->sring->req_prod =3D __new; =
\
300 xen_mb(); /* back sees new requests /before/ we check req_event=
*/ \
301 (_notify) =3D ((RING_IDX)(__new - (_r)->sring->req_event) < =
\
302 (RING_IDX)(__new - __old)); =
\
303 } while (0)
https://nxr.netbsd.org/xref/src/sys/external/mit/xen-include-public/dist/xe=
n/include/public/io/ring.h?r=3D1.1#295
For hyperv, we are incorrectly using membar_sync (but also no
bus_dma):
834 msg->msg_type =3D HYPERV_MSGTYPE_NONE;
835 membar_sync();
836 if (msg->msg_flags & VMBUS_MSGFLAG_PENDING)
837 hyperv_send_eom();
https://nxr.netbsd.org/xref/src/sys/dev/hyperv/vmbus.c?r=3D1.19#835
From: Taylor R Campbell <riastradh@NetBSD.org>
To: cmeerw@cmeerw.org, gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
thorpej@NetBSD.org, skrll@NetBSD.org, jmcneill@NetBSD.org
Cc:
Subject: Re: kern/59618: occasional virtio block device lock ups/hangs
Date: Sun, 31 Aug 2025 23:08:30 +0000
The attached patch adds a new paravirt_membar_sync() and teaches both
virtio(4) and hyperv(4) to use it. ena(4) and any similar drivers
likely need the same treatment -- TBD.
(Xen will still use xen_mb() for now since it's also used in some
upstream Xen public header files.)
Giant diff:
https://www.NetBSD.org/~riastradh/tmp/20250831/pr59618-paravirtmbsync.diff
Itemized patch series:
https://www.NetBSD.org/~riastradh/tmp/20250831/pr59618-paravirtmbsync.patch
Review and testing welcome!
From: Christof Meerwald <cmeerw@cmeerw.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/59618: occasional virtio block device lock ups/hangs
Date: Mon, 1 Sep 2025 22:29:10 +0200
Thanks for the patch, really appreciated (and impressed).
I have applied to patch to NetBSD 10.1, and am running it on the VPS
where I noticed the issue. Not expecting to see any issues, as the
memory barrier I had added earlier had already worked for a few days.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src
Date: Sat, 6 Sep 2025 02:53:24 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 02:53:23 UTC 2025
Modified Files:
src/common/lib/libc/arch/i386/atomic: atomic.S
src/common/lib/libc/arch/sparc/atomic: membar_ops.S
src/common/lib/libc/arch/sparc64/atomic: membar_ops.S
src/common/lib/libc/arch/x86_64/atomic: atomic.S
src/distrib/sets/lists/comp: mi
src/share/man/man9: Makefile
src/sys/arch/alpha/alpha: locore.s
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/arm/arm: cpu_subr.c
src/sys/arch/hppa/hppa: support.S
src/sys/arch/i386/i386: cpufunc.S
src/sys/arch/mips/mips: cpu_subr.c
src/sys/arch/riscv/riscv: cpu_subr.c
src/sys/arch/sparc/sparc: locore.s
src/sys/arch/sparc64/sparc64: locore.s
src/sys/arch/virt68k/virt68k: locore.s
Added Files:
src/share/man/man9: paravirt_membar_sync.9
src/sys/sys: paravirt_membar.h
Log Message:
paravirt_membar_sync(9): New memory barrier.
For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.
This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus. Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/common/lib/libc/arch/i386/atomic/atomic.S
cvs rdiff -u -r1.8 -r1.9 src/common/lib/libc/arch/sparc/atomic/membar_ops.S
cvs rdiff -u -r1.9 -r1.10 \
src/common/lib/libc/arch/sparc64/atomic/membar_ops.S
cvs rdiff -u -r1.31 -r1.32 src/common/lib/libc/arch/x86_64/atomic/atomic.S
cvs rdiff -u -r1.2498 -r1.2499 src/distrib/sets/lists/comp/mi
cvs rdiff -u -r1.474 -r1.475 src/share/man/man9/Makefile
cvs rdiff -u -r0 -r1.1 src/share/man/man9/paravirt_membar_sync.9
cvs rdiff -u -r1.144 -r1.145 src/sys/arch/alpha/alpha/locore.s
cvs rdiff -u -r1.69 -r1.70 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/arm/cpu_subr.c
cvs rdiff -u -r1.8 -r1.9 src/sys/arch/hppa/hppa/support.S
cvs rdiff -u -r1.53 -r1.54 src/sys/arch/i386/i386/cpufunc.S
cvs rdiff -u -r1.64 -r1.65 src/sys/arch/mips/mips/cpu_subr.c
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/riscv/riscv/cpu_subr.c
cvs rdiff -u -r1.286 -r1.287 src/sys/arch/sparc/sparc/locore.s
cvs rdiff -u -r1.435 -r1.436 src/sys/arch/sparc64/sparc64/locore.s
cvs rdiff -u -r1.16 -r1.17 src/sys/arch/virt68k/virt68k/locore.s
cvs rdiff -u -r0 -r1.1 src/sys/sys/paravirt_membar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sat, 06 Sep 2025 02:59:58 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-11, pullup-10, pullup-9
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src/sys/dev/hyperv
Date: Sat, 6 Sep 2025 02:56:07 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 02:56:07 UTC 2025
Modified Files:
src/sys/dev/hyperv: vmbus.c
Log Message:
hyperv(4): Use paravirt_membar_sync(9) where needed.
Annotate each remaining membar_sync with the bus_dmamap_sync that I
think it really ought to be. Sprinkle some more annotations of where
bus_dmamap_sync ought to go. (Although these likely don't matter --
except as __insn_barrier equivalents -- for hyperv on x86, and these
buffers are not likely to ever bounce, the syncs may be needed on Arm
for the underlying r-before-r/w and r/w-before-w ordering if nothing
else.)
PR kern/59618: occasional virtio block device lock ups/hangs
(hyperv(4) is not virtio(4) but the same fundamental issue arises.)
To generate a diff of this commit:
cvs rdiff -u -r1.19 -r1.20 src/sys/dev/hyperv/vmbus.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src/sys/dev/pci
Date: Sat, 6 Sep 2025 02:56:19 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 02:56:18 UTC 2025
Modified Files:
src/sys/dev/pci: virtio.c
Log Message:
virtio(4): Use paravirt_membar_sync(9) where needed.
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.83 -r1.84 src/sys/dev/pci/virtio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src/sys/dev/pci
Date: Sat, 6 Sep 2025 02:56:31 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 02:56:30 UTC 2025
Modified Files:
src/sys/dev/pci: pvscsi.c
Log Message:
pvscsi(4): Use paravirt_membar_sync(9) where needed.
PR kern/59618: occasional virtio block device lock ups/hangs
(pvscsi(4) is not virtio(4) but the same fundamental issue arises.)
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/sys/dev/pci/pvscsi.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src/sys/dev/pci
Date: Sat, 6 Sep 2025 02:56:40 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 02:56:40 UTC 2025
Modified Files:
src/sys/dev/pci: pvscsi.c
Log Message:
pvscsi(4): Use bus_dmamap_sync, not membar_*, for DMA.
membar_* may be a noop if we're booting on a single _virtual_ CPU,
but the barriers are still needed in case the host behind pvscsi(4)
is running on another _physical_ CPU.
Prompted by (and related to but not the same issue as):
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/sys/dev/pci/pvscsi.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src/sys/dev/pci
Date: Sat, 6 Sep 2025 02:56:52 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 02:56:52 UTC 2025
Modified Files:
src/sys/dev/pci: pvscsi.c
Log Message:
pvscsi(4): Zero rings before using them.
bus_dmamem_alloc(9) doesn't guarantee zeroing, as far as I can tell,
and who knows what might happen if the ring header and contents have
anything nonzero initially.
Insert an initial preread/prewrite sync between zeroing and first
use, and, out of paranoia, a final postread/postwrite sync between
last use and unload/free.
Prompted by (but not really related to):
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/sys/dev/pci/pvscsi.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: src/sys/arch/mips/mips
Date: Sat, 6 Sep 2025 12:42:17 +0000
Module Name: src
Committed By: riastradh
Date: Sat Sep 6 12:42:17 UTC 2025
Modified Files:
src/sys/arch/mips/mips: cpu_subr.c
Log Message:
mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync. Fixes:
> /tmp/ccxgOmXc.s: Assembler messages:
> /tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
> --- cpu_subr.o ---
>
> *** Failed target: cpu_subr.o
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.65 -r1.66 src/sys/arch/mips/mips/cpu_subr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Sun, 19 Oct 2025 00:21:45 +0000
Responsible-Changed-Why:
mine
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 19 Oct 2025 00:21:45 +0000
State-Changed-Why:
Adding paravirt_membar_sync:
pullup-11 #60
pullup-10 #1176
pullup-9 #1975
Adapting hyperv to use it:
pullup-11 #61
pullup-10 #1177
pullup-9 #1976
Adapting virtio to use it:
pullup-11 #62
pullup-10 #1178
pullup-9 #1977
Adapting pvscsi to use it, and related followups for pvscsi:
pullup-11 #63
pullup-11 #64
inapplicable <11
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-11] src
Date: Sun, 19 Oct 2025 10:29:22 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 10:29:22 UTC 2025
Modified Files:
src/common/lib/libc/arch/i386/atomic [netbsd-11]: atomic.S
src/common/lib/libc/arch/sparc/atomic [netbsd-11]: membar_ops.S
src/common/lib/libc/arch/sparc64/atomic [netbsd-11]: membar_ops.S
src/common/lib/libc/arch/x86_64/atomic [netbsd-11]: atomic.S
src/distrib/sets/lists/comp [netbsd-11]: mi
src/share/man/man9 [netbsd-11]: Makefile
src/sys/arch/alpha/alpha [netbsd-11]: locore.s
src/sys/arch/amd64/amd64 [netbsd-11]: cpufunc.S
src/sys/arch/arm/arm [netbsd-11]: cpu_subr.c
src/sys/arch/hppa/hppa [netbsd-11]: support.S
src/sys/arch/i386/i386 [netbsd-11]: cpufunc.S
src/sys/arch/mips/mips [netbsd-11]: cpu_subr.c
src/sys/arch/riscv/riscv [netbsd-11]: cpu_subr.c
src/sys/arch/sparc/sparc [netbsd-11]: locore.s
src/sys/arch/sparc64/sparc64 [netbsd-11]: locore.s
src/sys/arch/virt68k/virt68k [netbsd-11]: locore.s
Added Files:
src/share/man/man9 [netbsd-11]: paravirt_membar_sync.9
src/sys/sys [netbsd-11]: paravirt_membar.h
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #60):
sys/arch/sparc/sparc/locore.s: revision 1.287
share/man/man9/Makefile: revision 1.475
sys/arch/mips/mips/cpu_subr.c: revision 1.65
sys/arch/riscv/riscv/cpu_subr.c: revision 1.6
sys/arch/mips/mips/cpu_subr.c: revision 1.66
sys/arch/amd64/amd64/cpufunc.S: revision 1.70
common/lib/libc/arch/i386/atomic/atomic.S: revision 1.38
common/lib/libc/arch/sparc/atomic/membar_ops.S: revision 1.9
sys/arch/hppa/hppa/support.S: revision 1.9
sys/arch/alpha/alpha/locore.s: revision 1.145
share/man/man9/paravirt_membar_sync.9: revision 1.1
sys/arch/sparc64/sparc64/locore.s: revision 1.436
distrib/sets/lists/comp/mi: revision 1.2499
sys/arch/i386/i386/cpufunc.S: revision 1.54
common/lib/libc/arch/sparc64/atomic/membar_ops.S: revision 1.10
sys/sys/paravirt_membar.h: revision 1.1
sys/arch/arm/arm/cpu_subr.c: revision 1.6
sys/arch/virt68k/virt68k/locore.s: revision 1.17
common/lib/libc/arch/x86_64/atomic/atomic.S: revision 1.32
paravirt_membar_sync(9): New memory barrier.
For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.
This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus. Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.
PR kern/59618: occasional virtio block device lock ups/hangs
mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync. Fixes:
/tmp/ccxgOmXc.s: Assembler messages:
/tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
--- cpu_subr.o ---
*** Failed target: cpu_subr.o
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.37.2.1 src/common/lib/libc/arch/i386/atomic/atomic.S
cvs rdiff -u -r1.8 -r1.8.10.1 \
src/common/lib/libc/arch/sparc/atomic/membar_ops.S
cvs rdiff -u -r1.9 -r1.9.10.1 \
src/common/lib/libc/arch/sparc64/atomic/membar_ops.S
cvs rdiff -u -r1.31 -r1.31.2.1 \
src/common/lib/libc/arch/x86_64/atomic/atomic.S
cvs rdiff -u -r1.2497.2.2 -r1.2497.2.3 src/distrib/sets/lists/comp/mi
cvs rdiff -u -r1.474 -r1.474.2.1 src/share/man/man9/Makefile
cvs rdiff -u -r0 -r1.1.2.2 src/share/man/man9/paravirt_membar_sync.9
cvs rdiff -u -r1.144 -r1.144.2.1 src/sys/arch/alpha/alpha/locore.s
cvs rdiff -u -r1.69 -r1.69.2.1 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.5 -r1.5.12.1 src/sys/arch/arm/arm/cpu_subr.c
cvs rdiff -u -r1.8 -r1.8.2.1 src/sys/arch/hppa/hppa/support.S
cvs rdiff -u -r1.53 -r1.53.2.1 src/sys/arch/i386/i386/cpufunc.S
cvs rdiff -u -r1.64 -r1.64.8.1 src/sys/arch/mips/mips/cpu_subr.c
cvs rdiff -u -r1.5 -r1.5.4.1 src/sys/arch/riscv/riscv/cpu_subr.c
cvs rdiff -u -r1.286 -r1.286.2.1 src/sys/arch/sparc/sparc/locore.s
cvs rdiff -u -r1.435 -r1.435.2.1 src/sys/arch/sparc64/sparc64/locore.s
cvs rdiff -u -r1.16 -r1.16.2.1 src/sys/arch/virt68k/virt68k/locore.s
cvs rdiff -u -r0 -r1.1.2.2 src/sys/sys/paravirt_membar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-10] src
Date: Sun, 19 Oct 2025 10:34:44 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 10:34:43 UTC 2025
Modified Files:
src/common/lib/libc/arch/i386/atomic [netbsd-10]: atomic.S
src/common/lib/libc/arch/sparc/atomic [netbsd-10]: membar_ops.S
src/common/lib/libc/arch/sparc64/atomic [netbsd-10]: membar_ops.S
src/common/lib/libc/arch/x86_64/atomic [netbsd-10]: atomic.S
src/distrib/sets/lists/comp [netbsd-10]: mi
src/share/man/man9 [netbsd-10]: Makefile
src/sys/arch/alpha/alpha [netbsd-10]: locore.s
src/sys/arch/amd64/amd64 [netbsd-10]: cpufunc.S
src/sys/arch/arm/arm [netbsd-10]: cpu_subr.c
src/sys/arch/hppa/hppa [netbsd-10]: support.S
src/sys/arch/i386/i386 [netbsd-10]: cpufunc.S
src/sys/arch/mips/mips [netbsd-10]: cpu_subr.c
src/sys/arch/sparc/sparc [netbsd-10]: locore.s
src/sys/arch/sparc64/sparc64 [netbsd-10]: locore.s
Added Files:
src/share/man/man9 [netbsd-10]: paravirt_membar_sync.9
src/sys/sys [netbsd-10]: paravirt_membar.h
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #60):
sys/arch/sparc/sparc/locore.s: revision 1.287
share/man/man9/Makefile: revision 1.475
sys/arch/mips/mips/cpu_subr.c: revision 1.65
sys/arch/mips/mips/cpu_subr.c: revision 1.66
sys/arch/amd64/amd64/cpufunc.S: revision 1.70
common/lib/libc/arch/i386/atomic/atomic.S: revision 1.38
common/lib/libc/arch/sparc/atomic/membar_ops.S: revision 1.9
sys/arch/hppa/hppa/support.S: revision 1.9
sys/arch/alpha/alpha/locore.s: revision 1.145
share/man/man9/paravirt_membar_sync.9: revision 1.1
sys/arch/sparc64/sparc64/locore.s: revision 1.436
distrib/sets/lists/comp/mi: revision 1.2499
sys/arch/i386/i386/cpufunc.S: revision 1.54
common/lib/libc/arch/sparc64/atomic/membar_ops.S: revision 1.10
sys/sys/paravirt_membar.h: revision 1.1
sys/arch/arm/arm/cpu_subr.c: revision 1.6
common/lib/libc/arch/x86_64/atomic/atomic.S: revision 1.32
(all via patch)
paravirt_membar_sync(9): New memory barrier.
For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.
This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus. Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.
PR kern/59618: occasional virtio block device lock ups/hangs
mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync. Fixes:
/tmp/ccxgOmXc.s: Assembler messages:
/tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
--- cpu_subr.o ---
*** Failed target: cpu_subr.o
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.36.2.1 -r1.36.2.2 \
src/common/lib/libc/arch/i386/atomic/atomic.S
cvs rdiff -u -r1.8 -r1.8.2.1 \
src/common/lib/libc/arch/sparc/atomic/membar_ops.S
cvs rdiff -u -r1.9 -r1.9.2.1 \
src/common/lib/libc/arch/sparc64/atomic/membar_ops.S
cvs rdiff -u -r1.29.2.1 -r1.29.2.2 \
src/common/lib/libc/arch/x86_64/atomic/atomic.S
cvs rdiff -u -r1.2425.2.11 -r1.2425.2.12 src/distrib/sets/lists/comp/mi
cvs rdiff -u -r1.465.2.5 -r1.465.2.6 src/share/man/man9/Makefile
cvs rdiff -u -r0 -r1.1.4.2 src/share/man/man9/paravirt_membar_sync.9
cvs rdiff -u -r1.143 -r1.143.4.1 src/sys/arch/alpha/alpha/locore.s
cvs rdiff -u -r1.65.18.1 -r1.65.18.2 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.5 -r1.5.4.1 src/sys/arch/arm/arm/cpu_subr.c
cvs rdiff -u -r1.7.30.1 -r1.7.30.2 src/sys/arch/hppa/hppa/support.S
cvs rdiff -u -r1.49.20.1 -r1.49.20.2 src/sys/arch/i386/i386/cpufunc.S
cvs rdiff -u -r1.62 -r1.62.4.1 src/sys/arch/mips/mips/cpu_subr.c
cvs rdiff -u -r1.283.4.1 -r1.283.4.2 src/sys/arch/sparc/sparc/locore.s
cvs rdiff -u -r1.431.4.1 -r1.431.4.2 src/sys/arch/sparc64/sparc64/locore.s
cvs rdiff -u -r0 -r1.1.4.2 src/sys/sys/paravirt_membar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-9] src
Date: Sun, 19 Oct 2025 10:44:34 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 10:44:33 UTC 2025
Modified Files:
src/distrib/sets/lists/comp [netbsd-9]: mi
src/share/man/man9 [netbsd-9]: Makefile
src/sys/arch/aarch64/aarch64 [netbsd-9]: aarch64_machdep.c
src/sys/arch/alpha/alpha [netbsd-9]: locore.s
src/sys/arch/amd64/amd64 [netbsd-9]: cpufunc.S
src/sys/arch/arm/arm32 [netbsd-9]: arm32_machdep.c
src/sys/arch/hppa/hppa [netbsd-9]: support.S
src/sys/arch/i386/i386 [netbsd-9]: cpufunc.S
src/sys/arch/mips/mips [netbsd-9]: cpu_subr.c
src/sys/arch/sparc/sparc [netbsd-9]: locore.s
src/sys/arch/sparc64/sparc64 [netbsd-9]: locore.s
Added Files:
src/share/man/man9 [netbsd-9]: paravirt_membar_sync.9
src/sys/sys [netbsd-9]: paravirt_membar.h
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #60):
sys/arch/sparc/sparc/locore.s: revision 1.287
share/man/man9/Makefile: revision 1.475
sys/arch/mips/mips/cpu_subr.c: revision 1.65
sys/arch/mips/mips/cpu_subr.c: revision 1.66
sys/arch/amd64/amd64/cpufunc.S: revision 1.70
sys/arch/hppa/hppa/support.S: revision 1.9
sys/arch/alpha/alpha/locore.s: revision 1.145
share/man/man9/paravirt_membar_sync.9: revision 1.1
sys/arch/sparc64/sparc64/locore.s: revision 1.436
distrib/sets/lists/comp/mi: revision 1.2499
sys/arch/i386/i386/cpufunc.S: revision 1.54
sys/sys/paravirt_membar.h: revision 1.1
sys/arch/arm/arm/cpu_subr.c: revision 1.6
(all via patch)
paravirt_membar_sync(9): New memory barrier.
For use in paravirtualized drivers which require store-before-load
ordering -- irrespective of whether the kernel is built for a single
processor, or whether the (virtual) machine is booted with a single
processor.
This is even required on architectures that don't even have a
store-before-load ordering barrier, like m68k; adding, e.g., a virtio
bus is _as if_ the architecture has been extended with relaxed memory
ordering when talking with that new bus. Such architectures need
some way to request the hypervisor enforce that ordering -- on m68k,
that's done by issuing a CASL instruction, which qemu maps to an
atomic r/m/w with sequential consistency ordering in the host.
PR kern/59618: occasional virtio block device lock ups/hangs
mips: Fix asm arch options in new paravirt_membar_sync.
Need to explicitly enable mips2 (MIPS-II) instructions in order to
use sync. Fixes:
/tmp/ccxgOmXc.s: Assembler messages:
/tmp/ccxgOmXc.s:3576: Error: opcode not supported on this processor: mips1 (mips1) `sync'
--- cpu_subr.o ---
*** Failed target: cpu_subr.o
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.2278.2.9 -r1.2278.2.10 src/distrib/sets/lists/comp/mi
cvs rdiff -u -r1.437.2.4 -r1.437.2.5 src/share/man/man9/Makefile
cvs rdiff -u -r0 -r1.1.6.2 src/share/man/man9/paravirt_membar_sync.9
cvs rdiff -u -r1.28.4.4 -r1.28.4.5 \
src/sys/arch/aarch64/aarch64/aarch64_machdep.c
cvs rdiff -u -r1.123.4.1 -r1.123.4.2 src/sys/arch/alpha/alpha/locore.s
cvs rdiff -u -r1.43 -r1.43.2.1 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.128.2.1 -r1.128.2.2 src/sys/arch/arm/arm32/arm32_machdep.c
cvs rdiff -u -r1.7 -r1.7.4.1 src/sys/arch/hppa/hppa/support.S
cvs rdiff -u -r1.34 -r1.34.2.1 src/sys/arch/i386/i386/cpufunc.S
cvs rdiff -u -r1.34 -r1.34.4.1 src/sys/arch/mips/mips/cpu_subr.c
cvs rdiff -u -r1.274.2.1 -r1.274.2.2 src/sys/arch/sparc/sparc/locore.s
cvs rdiff -u -r1.421.2.1 -r1.421.2.2 src/sys/arch/sparc64/sparc64/locore.s
cvs rdiff -u -r0 -r1.1.6.2 src/sys/sys/paravirt_membar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-11] src/sys/dev/hyperv
Date: Sun, 19 Oct 2025 10:51:18 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 10:51:18 UTC 2025
Modified Files:
src/sys/dev/hyperv [netbsd-11]: vmbus.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #61):
sys/dev/hyperv/vmbus.c: revision 1.20
hyperv(4): Use paravirt_membar_sync(9) where needed.
Annotate each remaining membar_sync with the bus_dmamap_sync that I
think it really ought to be. Sprinkle some more annotations of where
bus_dmamap_sync ought to go. (Although these likely don't matter --
except as __insn_barrier equivalents -- for hyperv on x86, and these
buffers are not likely to ever bounce, the syncs may be needed on Arm
for the underlying r-before-r/w and r/w-before-w ordering if nothing
else.)
PR kern/59618: occasional virtio block device lock ups/hangs
(hyperv(4) is not virtio(4) but the same fundamental issue arises.)
To generate a diff of this commit:
cvs rdiff -u -r1.19 -r1.19.2.1 src/sys/dev/hyperv/vmbus.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-10] src/sys/dev/hyperv
Date: Sun, 19 Oct 2025 10:52:32 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 10:52:32 UTC 2025
Modified Files:
src/sys/dev/hyperv [netbsd-10]: vmbus.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1177):
sys/dev/hyperv/vmbus.c: revision 1.20
hyperv(4): Use paravirt_membar_sync(9) where needed.
Annotate each remaining membar_sync with the bus_dmamap_sync that I
think it really ought to be. Sprinkle some more annotations of where
bus_dmamap_sync ought to go. (Although these likely don't matter --
except as __insn_barrier equivalents -- for hyperv on x86, and these
buffers are not likely to ever bounce, the syncs may be needed on Arm
for the underlying r-before-r/w and r/w-before-w ordering if nothing
else.)
PR kern/59618: occasional virtio block device lock ups/hangs
(hyperv(4) is not virtio(4) but the same fundamental issue arises.)
To generate a diff of this commit:
cvs rdiff -u -r1.18.4.1 -r1.18.4.2 src/sys/dev/hyperv/vmbus.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-9] src/sys/dev/hyperv
Date: Sun, 19 Oct 2025 10:55:08 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 10:55:08 UTC 2025
Modified Files:
src/sys/dev/hyperv [netbsd-9]: vmbus.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1976):
sys/dev/hyperv/vmbus.c: revision 1.20 (patch)
hyperv(4): Use paravirt_membar_sync(9) where needed.
Annotate each remaining membar_sync with the bus_dmamap_sync that I
think it really ought to be. Sprinkle some more annotations of where
bus_dmamap_sync ought to go. (Although these likely don't matter --
except as __insn_barrier equivalents -- for hyperv on x86, and these
buffers are not likely to ever bounce, the syncs may be needed on Arm
for the underlying r-before-r/w and r/w-before-w ordering if nothing
else.)
PR kern/59618: occasional virtio block device lock ups/hangs
(hyperv(4) is not virtio(4) but the same fundamental issue arises.)
To generate a diff of this commit:
cvs rdiff -u -r1.4.2.2 -r1.4.2.3 src/sys/dev/hyperv/vmbus.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-11] src/sys/dev/pci
Date: Sun, 19 Oct 2025 11:01:03 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 11:01:03 UTC 2025
Modified Files:
src/sys/dev/pci [netbsd-11]: virtio.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #62):
sys/dev/pci/virtio.c: revision 1.84
virtio(4): Use paravirt_membar_sync(9) where needed.
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.83 -r1.83.2.1 src/sys/dev/pci/virtio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-10] src/sys/dev/pci
Date: Sun, 19 Oct 2025 11:02:48 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 11:02:48 UTC 2025
Modified Files:
src/sys/dev/pci [netbsd-10]: virtio.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1178):
sys/dev/pci/virtio.c: revision 1.84
virtio(4): Use paravirt_membar_sync(9) where needed.
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.63.2.6 -r1.63.2.7 src/sys/dev/pci/virtio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-9] src/sys/dev/pci
Date: Sun, 19 Oct 2025 11:06:00 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 11:06:00 UTC 2025
Modified Files:
src/sys/dev/pci [netbsd-9]: virtio.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1977):
sys/dev/pci/virtio.c: revision 1.84 (patch)
virtio(4): Use paravirt_membar_sync(9) where needed.
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.37.4.1 src/sys/dev/pci/virtio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-11] src/sys/dev/pci
Date: Sun, 19 Oct 2025 11:09:18 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 11:09:18 UTC 2025
Modified Files:
src/sys/dev/pci [netbsd-11]: pvscsi.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #63):
sys/dev/pci/pvscsi.c: revision 1.3
pvscsi(4): Use paravirt_membar_sync(9) where needed.
PR kern/59618: occasional virtio block device lock ups/hangs
(pvscsi(4) is not virtio(4) but the same fundamental issue arises.)
To generate a diff of this commit:
cvs rdiff -u -r1.2.2.2 -r1.2.2.3 src/sys/dev/pci/pvscsi.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59618 CVS commit: [netbsd-11] src/sys/dev/pci
Date: Sun, 19 Oct 2025 13:53:08 +0000
Module Name: src
Committed By: martin
Date: Sun Oct 19 13:53:08 UTC 2025
Modified Files:
src/sys/dev/pci [netbsd-11]: pvscsi.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #64):
sys/dev/pci/pvscsi.c: revision 1.4
sys/dev/pci/pvscsi.c: revision 1.5
pvscsi(4): Use bus_dmamap_sync, not membar_*, for DMA.
membar_* may be a noop if we're booting on a single _virtual_ CPU,
but the barriers are still needed in case the host behind pvscsi(4)
is running on another _physical_ CPU.
Prompted by (and related to but not the same issue as):
PR kern/59618: occasional virtio block device lock ups/hangs
pvscsi(4): Zero rings before using them.
bus_dmamem_alloc(9) doesn't guarantee zeroing, as far as I can tell,
and who knows what might happen if the ring header and contents have
anything nonzero initially.
Insert an initial preread/prewrite sync between zeroing and first
use, and, out of paranoia, a final postread/postwrite sync between
last use and unload/free.
Prompted by (but not really related to):
PR kern/59618: occasional virtio block device lock ups/hangs
To generate a diff of this commit:
cvs rdiff -u -r1.2.2.3 -r1.2.2.4 src/sys/dev/pci/pvscsi.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(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