NetBSD Problem Report #58561
From www@netbsd.org Wed Aug 7 19:51:33 2024
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 714F91A923E
for <gnats-bugs@gnats.NetBSD.org>; Wed, 7 Aug 2024 19:51:33 +0000 (UTC)
Message-Id: <20240807195130.3D7391A9241@mollari.NetBSD.org>
Date: Wed, 7 Aug 2024 19:51:30 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581
X-Send-Pr-Version: www-1.0
>Number: 58561
>Notify-List: cherry@NetBSD.org
>Category: port-xen
>Synopsis: panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bouyer
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Aug 07 19:55:00 +0000 2024
>Closed-Date: Sun Jan 25 17:06:09 +0000 2026
>Last-Modified: Sun Jan 25 18:15:01 +0000 2026
>Originator: Taylor R Campbell
>Release: 10
>Organization:
The NetPSL Mollariation
>Environment:
NetBSD mollari.NetBSD.org 10.0_STABLE NetBSD 10.0_STABLE (amd64-DOMU_SERVER) #1: Sun Jul 21 17:01:48 UTC 2024 spz@franklin.NetBSD.org:/home/netbsd/10/amd64/obj/sys/arch/amd64/compile/amd64-DOMU_SERVER amd64
>Description:
[ 937489.7104957] panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581
[ 937489.7104957] cpu0: Begin traceback...
[ 937489.7104957] vpanic() at netbsd:vpanic+0x177
[ 937489.7104957] kern_assert() at netbsd:kern_assert+0x4b
[ 937489.7104957] pmap_load() at netbsd:pmap_load+0x138
[ 937489.7104957] do_pmap_load() at netbsd:do_pmap_load+0x1d
[ 937489.7104957] cpu0: End traceback...
[ 937489.7104957] fatal breakpoint trap in supervisor mode
[ 937489.7104957] trap type 1 code 0 rip 0xffffffff8022e96d cs 0x10000e030 rflags 0x2 cr2 0x7c8d32b02000 ilevel 0 rsp 0xffffb0825b554de8
[ 937489.7104957] curlwp 0xffffb0801111c700 pid 9925.9925 lowest kstack 0xffffb0825b5502c0
Stopped in pid 9925.9925 (cvs) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x177
kern_assert() at netbsd:kern_assert+0x4b
pmap_load() at netbsd:pmap_load+0x138
do_pmap_load() at netbsd:do_pmap_load+0x1d
ds 0
es 180
fs 4d98
gs 4de8
rdi 0
rsi ffffb0825b554b54
rbp ffffb0825b554de8
rbx ffffffff8064d000 cpu_info_primary
rdx 1
rcx ffffffffffffff
rax 800000000000000
r8 0
r9 0
r10 0
r11 fffffffe
r12 ffffffff80586b90 ostype+0x1d4
r13 ffffb0825b554e30
r14 104
r15 680c
rip ffffffff8022e96d breakpoint+0x5
cs e030
rflags 2
rsp ffffb0825b554de8
ss e02b
netbsd:breakpoint+0x5: leave
db{0}> ps
PID LID S CPU FLAGS STRUCT LWP * NAME WAIT
16235 16235 2 3 0 ffffb080191086c0 httpd
4585 4585 3 2 180 ffffb08050cbd040 ikiwiki lockf
9925 > 9925 7 0 40100 ffffb0801111c700 cvs
10271 10271 3 1 180 ffffb080198eb580 cvs select
3335 3335 3 2 180 ffffb0804bc62bc0 cvsps pipe_rd
2322 2322 3 1 180 ffffb080198eb9c0 postdrop netio
28524 28524 3 0 180 ffffb0805011c600 sendmail pipe_rd
22734 22734 3 0 180 ffffb0801fd1a900 postdrop netio
24610 24610 3 1 180 ffffb08012e78780 sendmail pipe_rd
22584 22584 3 2 180 ffffb0805144b5c0 perl lockf
20549>20549 7 2 100 ffffb080193b5500 perl
13086 13086 3 1 180 ffffb08013185980 perl wait
2285 2285 3 3 180 ffffb08026c6c900 cron pipe_rd
10761 10761 3 2 180 ffffb08050470640 cron pipe_rd
8841 8841 3 2 180 ffffb08012d75b00 vmstat nanoslp
2080 2080 3 0 180 ffffb08050fe9640 sh wait
9843 9843 3 1 180 ffffb08050064780 local kqueue
10095 10095 3 2 180 ffffb08050bdabc0 cleanup kqueue
9468 9468 3 0 180 ffffb08018f25240 trivial-rewrite kqueue
13168 13168 3 3 180 ffffb0801311c0c0 proxymap kqueue
5835 5835 3 1 180 ffffb0801448e080 smtpd kqueue
6298 6298 3 1 0 ffffb08012c6a180 rsync biowait
22918 22918 3 3 180 ffffb0801bc3c5c0 tcsh pause
11322>11322 7 1 100 ffffb0802a47c680 sshd
12860 12860 3 1 180 ffffb0801b3c76c0 sshd poll
27845 27845 3 3 180 ffffb0804e29a240 pickup kqueue
29900 29900 3 0 180 ffffb0801aea46c0 sshd netio
19496 19496 3 2 180 ffffb080391300c0 sshd netio
25462 25462 3 3 180 ffffb0801b3c7b00 sshd netio
29887 29887 3 1 180 ffffb08012d75280 sshd netio
5329 5329 3 3 180 ffffb0804c6c3580 sshd netio
28166 28166 3 2 180 ffffb0804039d600 sshd netio
29378 29378 3 1 180 ffffb08041189340 sshd netio
8881 8881 3 1 180 ffffb08026c6c4c0 sshd netio
7908 7908 3 0 180 ffffb0803fc2aa00 sshd netio
912 912 3 1 180 ffffb080193b50c0 sh ttyraw
13867 13867 3 3 180 ffffb080130ea900 sshd poll
22218 22218 3 0 180 ffffb0802cb7d4c0 sshd poll
4780 4780 3 1 180 ffffb0801318ca00 csh ttyraw
4475 4475 3 2 180 ffffb08041fba280 sshd poll
4915 4915 3 0 180 ffffb08013175280 sshd poll
12921 12921 3 2 180 ffffb08043fddb80 tcsh ttyraw
7044 7044 3 0 180 ffffb08047325500 sshd poll
11778 11778 3 2 180 ffffb08050470200 sshd poll
16813 393 3 1 1c0 ffffb08050994700 httpd kqueue
16813 7578 3 0 180 ffffb080509942c0 httpd parked
16813 13069 3 1 180 ffffb08050991b00 httpd parked
16813 26008 3 3 180 ffffb080509916c0 httpd parked
16813 1101 3 3 180 ffffb08050991280 httpd parked
16813 26798 3 3 1c0 ffffb0805098dac0 httpd parked
16813 6227 3 2 180 ffffb0805098d680 httpd parked
16813 18164 3 2 180 ffffb0805098d240 httpd parked
16813 2253 3 1 180 ffffb0805098ca80 httpd parked
16813 27567 3 0 180 ffffb0805098c640 httpd parked
16813 5206 3 1 180 ffffb0805098c200 httpd parked
16813 21387 3 0 180 ffffb08050989a40 httpd parked
16813 29824 3 3 1c0 ffffb08050989600 httpd parked
16813 28668 3 3 180 ffffb080509891c0 httpd parked
16813 10031 3 1 180 ffffb08050986a00 httpd parked
16813 25938 3 3 180 ffffb080509865c0 httpd parked
16813 4041 3 0 1c0 ffffb08050986180 httpd parked
16813 15839 3 0 180 ffffb080509849c0 httpd parked
16813 23010 3 3 180 ffffb08050984580 httpd parked
16813 18632 3 3 180 ffffb08050984140 httpd parked
16813 28778 3 2 180 ffffb08050982980 httpd parked
16813 2670 3 2 180 ffffb08050982540 httpd parked
16813 7600 3 2 180 ffffb08050982100 httpd parked
16813 3066 3 2 180 ffffb08050978940 httpd parked
16813 4400 3 2 180 ffffb08050978500 httpd parked
16813 15847 3 2 180 ffffb080509780c0 httpd parked
16813 15015 5 0 0 ffffb080440b18c0 httpd
16813 16813 3 2 180 ffffb08050945900 httpd pipe_rd
25746 2402 3 2 1c0 ffffb080501b6bc0 httpd kqueue
25746 7481 3 0 180 ffffb080501b6780 httpd parked
25746 26488 3 1 180 ffffb080501b6340 httpd parked
25746 13080 3 1 180 ffffb080501b5b80 httpd parked
25746 10635 3 1 180 ffffb080501b5740 httpd parked
25746 28211 3 1 180 ffffb080501b5300 httpd parked
25746 1202 3 1 1c0 ffffb080501b3b40 httpd parked
25746 17278 3 1 180 ffffb080501b3700 httpd parked
25746 5459 3 3 1c0 ffffb080501b32c0 httpd parked
25746 18535 3 2 180 ffffb080501b2b00 httpd parked
25746 3043 3 1 1c0 ffffb080501b26c0 httpd parked
25746 7545 3 2 1c0 ffffb080501b2280 httpd parked
25746 26683 3 3 180 ffffb080501b0ac0 httpd parked
25746 10378 3 3 180 ffffb080501b0680 httpd parked
25746 8905 3 3 1c0 ffffb080501b0240 httpd parked
25746 25472 3 1 180 ffffb080501aea80 httpd parked
25746 24458 3 0 180 ffffb080501ae640 httpd parked
25746 16308 3 3 180 ffffb080501ae200 httpd parked
25746 11673 3 3 1c0 ffffb080501ada40 httpd parked
25746 25450 3 3 180 ffffb080501ad600 httpd parked
25746 8060 3 2 1c0 ffffb080501ad1c0 httpd parked
25746 23514 3 1 180 ffffb080501aca00 httpd parked
25746 11197 3 2 1c0 ffffb080501ac5c0 httpd parked
25746 27306 3 2 1c0 ffffb080501ac180 httpd parked
25746 17273 3 2 1c0 ffffb0804039d1c0 httpd parked
25746 15306 3 3 180 ffffb08041fbab00 httpd parked
25746 12238 5 0 0 ffffb08028a32480 httpd
25746 25746 3 1 180 ffffb08049e01140 httpd pipe_rd
22357 6462 3 0 180 ffffb0804ff07940 httpd kqueue
22357 2314 3 2 180 ffffb0804ff07500 httpd parked
22357 22130 3 2 180 ffffb0804ff070c0 httpd parked
22357 10000 3 2 180 ffffb0804ff06900 httpd parked
22357 22036 3 3 180 ffffb0804ff064c0 httpd parked
22357 24731 3 1 180 ffffb0804ff06080 httpd parked
22357 5545 3 1 180 ffffb0804ff058c0 httpd parked
22357 1091 3 1 180 ffffb0804ff05480 httpd parked
22357 5095 3 1 180 ffffb0804ff05040 httpd parked
22357 1813 3 3 1c0 ffffb0804ff04bc0 httpd parked
22357 17775 3 3 180 ffffb0804ff04780 httpd parked
22357 15896 3 3 180 ffffb0804ff04340 httpd parked
22357 22820 3 2 180 ffffb0804ff03b80 httpd parked
22357 8324 3 3 180 ffffb0804ff03740 httpd parked
22357 19263 3 3 180 ffffb0804ff03300 httpd parked
22357 25673 3 3 180 ffffb0804ff02b40 httpd parked
22357 26703 3 2 180 ffffb0804ff02700 httpd parked
22357 11989 3 1 180 ffffb0804ff022c0 httpd parked
22357 10078 3 1 180 ffffb0804ff01b00 httpd parked
22357 22708 3 1 180 ffffb0804ff016c0 httpd parked
22357 25873 3 1 180 ffffb0804ff01280 httpd parked
22357 21648 3 1 180 ffffb0804ff00ac0 httpd parked
22357 2590 3 1 180 ffffb0804ff00680 httpd parked
22357 12608 3 1 180 ffffb0804ff00240 httpd parked
22357 23839 3 1 180 ffffb0804feeda80 httpd parked
22357 22965 3 1 180 ffffb0804feed640 httpd parked
22357 2211 5 0 0 ffffb08019821100 httpd
22357 22357 3 1 180 ffffb0804feed200 httpd pipe_rd
6416 3794 3 2 180 ffffb08047325940 httpd kqueue
6416 1476 3 0 180 ffffb0801fd1a080 httpd parked
6416 12800 3 1 1c0 ffffb08012410b40 httpd parked
6416 17301 3 3 1c0 ffffb08039130500 httpd parked
6416 22367 3 3 180 ffffb0804bb15500 httpd parked
6416 27146 3 3 180 ffffb0804fa6ab80 httpd parked
6416 8806 3 1 180 ffffb0804fa6a740 httpd parked
6416 20215 3 1 1c0 ffffb080116161c0 httpd parked
6416 1666 3 3 180 ffffb08012c9b600 httpd parked
6416 27228 3 1 180 ffffb0804412b740 httpd parked
6416 8926 3 3 1c0 ffffb08012db4700 httpd parked
6416 21082 3 1 180 ffffb0802a47c240 httpd parked
6416 21014 3 1 1c0 ffffb0801391a540 httpd parked
6416 4662 3 0 180 ffffb080411702c0 httpd parked
6416 15649 3 2 180 ffffb08019d868c0 httpd parked
6416 26404 3 1 180 ffffb0801d722300 httpd parked
6416 1880 3 2 180 ffffb080131e3b40 httpd parked
6416 10467 3 3 180 ffffb0801e6018c0 httpd parked
6416 11525 3 3 180 ffffb08019821540 httpd parked
6416 14748 3 1 180 ffffb08012e78bc0 httpd parked
6416 6752 3 3 180 ffffb0804f0d8680 httpd parked
6416 22251 3 0 180 ffffb0801316ea80 httpd poll
6416 14020 3 0 180 ffffb0801317b340 httpd parked
6416 16635 3 3 180 ffffb08022b5d5c0 httpd parked
6416 8428 3 3 180 ffffb08049e08900 httpd parked
6416 17096 3 1 180 ffffb08013190200 httpd parked
6416 18858 5 2 0 ffffb08013184940 httpd
6416 6416 3 3 180 ffffb080244df640 httpd pipe_rd
26495 26811 3 3 180 ffffb0801316ba00 httpd kqueue
26495 15497 3 3 1c0 ffffb08013192ac0 httpd parked
26495 5398 3 3 180 ffffb0801afba300 httpd parked
26495 21312 3 2 180 ffffb0801320c340 httpd parked
26495 29931 3 0 180 ffffb08019d86480 httpd parked
26495 24391 3 1 180 ffffb08012f57580 httpd poll
26495 431 3 1 180 ffffb08019a51740 httpd poll
26495 462 3 1 180 ffffb08013ec25c0 httpd poll
26495 3924 3 3 1c0 ffffb0801b976bc0 httpd parked
26495 8879 3 2 180 ffffb0801d722b80 httpd parked
26495 2613 3 3 1c0 ffffb08012d0a200 httpd parked
26495 28076 3 3 1c0 ffffb0801aea4b00 httpd parked
26495 14196 3 1 180 ffffb08012b78640 httpd parked
26495 3407 3 1 180 ffffb08013192240 httpd poll
26495 1982 3 0 1c0 ffffb0804e29aac0 httpd parked
26495 25828 3 1 1c0 ffffb08010994640 httpd parked
26495 13662 3 2 180 ffffb08013187580 httpd parked
26495 24861 3 1 1c0 ffffb080131879c0 httpd parked
26495 18147 3 3 180 ffffb08012db42c0 httpd parked
26495 11456 2 3 100 ffffb08043fd1780 httpd
26495 9742 3 3 1c0 ffffb08013175b00 httpd parked
26495 11613 3 0 180 ffffb0801317bbc0 httpd parked
26495 21464 3 0 180 ffffb08041170700 httpd poll
26495 7813 3 3 1c0 ffffb0802779eb40 httpd parked
26495 26600 3 3 1c0 ffffb08049e01580 httpd parked
26495 9619 3 0 1c0 ffffb08019a51300 httpd parked
26495 20579 5 3 0 ffffb080109d9680 httpd
26495 26495 3 2 180 ffffb0801be05680 httpd pipe_rd
11122 11122 3 3 180 ffffb0801c10eb40 ksh ttyraw
20810 20810 3 0 180 ffffb08012a544c0 su wait
25250 25250 3 3 180 ffffb08013f39600 tcsh pause
19346 19346 3 2 180 ffffb08013023b40 sudo poll
21652 21652 3 1 180 ffffb0804de37a00 sudo poll
9532 9532 3 2 180 ffffb08012b60100 tcsh pause
27065 27065 3 2 180 ffffb0804bb37180 sshd poll
9808 9808 3 3 180 ffffb0801496bac0 sshd poll
29764 16900 3 0 1c0 ffffb08013177700 httpd kqueue
29764 7357 3 0 180 ffffb08013dfe140 httpd parked
29764 6111 3 1 180 ffffb0801c10e2c0 httpd parked
29764 8462 3 1 180 ffffb0801311c940 httpd parked
29764 27568 3 3 180 ffffb08049e019c0 httpd parked
29764 7451 3 2 180 ffffb08012f579c0 httpd parked
29764 14724 3 3 180 ffffb08049e084c0 httpd parked
29764 17138 3 3 180 ffffb0804bc62340 httpd parked
29764 22893 3 1 180 ffffb0804be28500 httpd parked
29764 12244 3 2 180 ffffb0801318f1c0 httpd parked
29764 17103 3 0 180 ffffb08012db4b40 httpd parked
29764 17013 3 2 180 ffffb0804a3068c0 httpd parked
29764 17793 3 3 180 ffffb08011616600 httpd parked
29764 28836 3 0 180 ffffb0804f0d8240 httpd parked
29764 8089 3 1 180 ffffb08012d756c0 httpd parked
29764 16312 3 1 180 ffffb0804bb375c0 httpd parked
29764 13696 3 1 180 ffffb0801300cb00 httpd parked
29764 25047 3 2 180 ffffb08012c9ba40 httpd parked
29764 8474 3 2 180 ffffb0804bd7b540 httpd parked
29764 23337 3 2 180 ffffb080109d9240 httpd parked
29764 8592 3 1 180 ffffb08043fd1bc0 httpd parked
29764 3280 3 3 180 ffffb08012b78a80 httpd parked
29764 342 3 3 180 ffffb0801311c500 httpd parked
29764 14230 3 2 1c0 ffffb08012e78340 httpd parked
29764 12281 3 1 180 ffffb08012dfa300 httpd parked
29764 24954 3 0 180 ffffb0801318f600 httpd parked
29764 3163 5 2 0 ffffb0804bb681c0 httpd
29764 29764 3 1 180 ffffb08019d86040 httpd pipe_rd
1504 23346 3 2 180 ffffb0801317f4c0 httpd kqueue
1504 21790 3 1 1c0 ffffb0801317e8c0 httpd parked
1504 22872 3 1 1c0 ffffb0801320a300 httpd parked
1504 19309 3 2 180 ffffb0801320a740 httpd parked
1504 1263 3 3 180 ffffb0801320ab80 httpd parked
1504 3712 3 2 180 ffffb0801320c780 httpd parked
1504 20931 3 0 180 ffffb0804bb68600 httpd parked
1504 18405 3 1 1c0 ffffb08013197280 httpd parked
1504 21121 3 1 180 ffffb080130232c0 httpd parked
1504 23386 3 3 180 ffffb080131e32c0 httpd parked
1504 22881 3 3 180 ffffb080131772c0 httpd parked
1504 28502 3 3 180 ffffb08013187140 httpd parked
1504 720 3 2 180 ffffb08013185100 httpd parked
1504 18885 3 2 1c0 ffffb08013184500 httpd parked
1504 21799 3 3 180 ffffb0801317f900 httpd parked
1504 23376 3 1 180 ffffb0801317f080 httpd parked
1504 10646 3 2 1c0 ffffb0801317e480 httpd parked
1504 23355 3 2 180 ffffb08011ca1ac0 httpd parked
1504 23351 3 2 180 ffffb08012c6a5c0 httpd parked
1504 21646 3 2 180 ffffb08013089bc0 httpd parked
1504 1885 3 3 1c0 ffffb080130b18c0 httpd parked
1504 2890 3 2 180 ffffb080130b1040 httpd parked
1504 20692 3 1 180 ffffb080130ea080 httpd parked
1504 26156 3 0 180 ffffb08013089780 httpd parked
1504 2150 3 1 180 ffffb080130b1480 httpd parked
1504 1508 3 0 180 ffffb0801305fb80 httpd parked
1504 2789 5 1 0 ffffb08010114740 httpd
1504 1504 3 3 180 ffffb08013192680 httpd pipe_rd
1692 1505 3 2 180 ffffb0801305f740 httpd kqueue
1692 2395 3 0 180 ffffb08013089340 httpd poll
1692 2396 3 1 180 ffffb08013023700 httpd parked
1692 1630 3 1 180 ffffb0801b992480 httpd parked
1692 2399 3 2 180 ffffb080193b5940 httpd parked
1692 2394 3 3 180 ffffb0804412b300 httpd parked
1692 1629 3 1 1c0 ffffb0801badc100 httpd parked
1692 2648 3 1 180 ffffb08013005200 httpd parked
1692 2649 3 3 1c0 ffffb08019821980 httpd parked
1692 1619 3 0 180 ffffb08013003600 httpd parked
1692 2518 3 3 180 ffffb08013005640 httpd parked
1692 1620 3 3 180 ffffb080198eb140 httpd parked
1692 2263 3 1 180 ffffb08013003a40 httpd parked
1692 1618 3 3 180 ffffb08013005a80 httpd parked
1692 2133 3 1 1c0 ffffb0804541b280 httpd parked
1692 2384 3 2 180 ffffb08013006240 httpd parked
1692 2639 3 3 180 ffffb08012acf500 httpd parked
1692 1617 3 1 180 ffffb08013006ac0 httpd parked
1692 2636 3 1 180 ffffb0801fd1a4c0 httpd parked
1692 2766 3 2 180 ffffb08013006680 httpd parked
1692 2633 3 1 180 ffffb08019a51b80 httpd parked
1692 2637 3 2 180 ffffb0804f52b100 httpd parked
1692 1611 3 1 1c0 ffffb08021bac980 httpd parked
1692 2122 3 3 180 ffffb0801afba740 httpd parked
1692 2632 3 3 1c0 ffffb08012d41ac0 httpd parked
1692 2738 3 3 180 ffffb08013197b00 httpd parked
1692 1986 5 1 10000000 ffffb08039130940 httpd
1692 1692 3 0 180 ffffb08013140980 httpd pipe_rd
1693 2355 3 0 180 ffffb08022a3f140 httpd kqueue
1693 1844 3 0 180 ffffb0801b992040 httpd parked
1693 2229 3 2 1c0 ffffb0801d713340 httpd parked
1693 2358 3 0 180 ffffb08022a3f580 httpd parked
1693 2744 3 1 180 ffffb08011616a40 httpd parked
1693 1594 3 3 180 ffffb0801b976340 httpd parked
1693 2749 3 1 180 ffffb08021bac540 httpd parked
1693 2751 3 3 180 ffffb0801d713780 httpd parked
1693 1985 3 1 180 ffffb0801326b080 httpd parked
1693 1987 3 2 1c0 ffffb0801afbab80 httpd parked
1693 1990 3 3 180 ffffb0801c10e700 httpd parked
1693 1379 3 1 180 ffffb08043fdd300 httpd parked
1693 1798 3 2 1c0 ffffb0801317e040 httpd parked
1693 1797 3 1 180 ffffb0801317b780 httpd poll
1693 1793 3 2 180 ffffb0801317ab80 httpd parked
1693 1677 3 3 1c0 ffffb0802175b500 httpd parked
1693 1684 3 2 180 ffffb08012405280 httpd poll
1693 1689 3 2 1c0 ffffb080199ada40 httpd parked
1693 1823 3 3 180 ffffb0804a306040 httpd parked
1693 2849 3 3 180 ffffb0804bb15940 httpd parked
1693 1682 3 3 180 ffffb08018f25ac0 httpd parked
1693 2734 3 0 180 ffffb080109d9ac0 httpd parked
1693 2622 3 3 180 ffffb0802a50cb00 httpd poll
1693 2592 3 3 180 ffffb0804412bb80 httpd parked
1693 1530 3 1 180 ffffb080440b1480 httpd parked
1693 1799 3 1 180 ffffb0804be28940 httpd parked
1693 1678 5 3 0 ffffb0801a36a9c0 httpd
1693 1693 3 0 180 ffffb08013149140 httpd pipe_rd
2976 2743 3 1 1c0 ffffb0804bb150c0 httpd kqueue
2976 2233 3 0 1c0 ffffb0804541b6c0 httpd parked
2976 2747 3 3 180 ffffb0804bb37a00 httpd parked
2976 1852 3 3 1c0 ffffb0802779e700 httpd parked
2976 2750 3 1 180 ffffb0804bd40180 httpd parked
2976 1600 3 3 180 ffffb0804f0d8ac0 httpd parked
2976 3012 3 3 180 ffffb080131499c0 httpd parked
2976 1989 3 3 180 ffffb0801316b5c0 httpd parked
2976 1351 3 3 1c0 ffffb0801316d1c0 httpd parked
2976 21654 3 3 1c0 ffffb0801316da40 httpd parked
2976 1796 3 1 180 ffffb0801316e640 httpd parked
2976 1794 3 3 1c0 ffffb08013174240 httpd parked
2976 1676 3 1 1c0 ffffb08013174ac0 httpd parked
2976 1681 3 2 180 ffffb080131756c0 httpd parked
2976 1686 3 2 180 ffffb0804a306480 httpd parked
2976 1691 3 3 180 ffffb08012c6aa00 httpd parked
2976 1574 3 3 180 ffffb08012c37140 httpd parked
2976 1575 3 3 1c0 ffffb0801b976780 httpd parked
2976 2987 3 0 180 ffffb08022a3f9c0 httpd parked
2976 2605 3 3 1c0 ffffb0801912f640 httpd parked
2976 2858 3 3 180 ffffb080131e3700 httpd parked
2976 2616 3 1 180 ffffb080131976c0 httpd parked
2976 1533 3 2 180 ffffb08013140100 httpd parked
2976 1792 3 3 180 ffffb08013190640 httpd parked
2976 1675 3 2 1c0 ffffb0801318fa40 httpd parked
2976 1679 3 2 180 ffffb08013140540 httpd parked
2976 1687 5 0 0 ffffb0801be05ac0 httpd
2976 2976 3 3 180 ffffb08012c37580 httpd pipe_rd
2980 2980 3 2 180 ffffb0801305f300 httpd poll
2089 > 2089 7 3 100 ffffb0801300c6c0 httpd
1407 1407 3 0 180 ffffb0801010fb40 rotatelogs pipe_rd
1515 1515 3 3 180 ffffb08012c379c0 rotatelogs pipe_rd
2608 2608 3 0 180 ffffb08012b60540 rotatelogs pipe_rd
2884 2884 3 3 180 ffffb08012b60980 rotatelogs pipe_rd
2623 2623 3 3 180 ffffb08041170b40 rotatelogs pipe_rd
1535 1535 3 0 180 ffffb0801318c5c0 rotatelogs pipe_rd
1532 1532 3 2 180 ffffb0802779e2c0 rotatelogs pipe_rd
1529 1529 3 3 180 ffffb0802175b0c0 rotatelogs pipe_rd
1527 1527 3 3 180 ffffb0804bb68a40 rotatelogs pipe_rd
1525 1525 3 2 180 ffffb0801317a740 rotatelogs pipe_rd
1522 1522 3 1 180 ffffb08013177b40 rotatelogs pipe_rd
1520 1520 3 2 180 ffffb0804bc62780 rotatelogs pipe_rd
1518 1518 3 0 180 ffffb0801329a940 rotatelogs pipe_rd
2796 2796 3 2 180 ffffb0802c1a3740 rotatelogs pipe_rd
1680 1680 3 0 180 ffffb0802c1a3b80 rotatelogs pipe_rd
3050 3050 3 0 180 ffffb0804eaffb00 rotatelogs pipe_rd
1683 1683 3 0 180 ffffb0801af962c0 rotatelogs pipe_rd
1795 1795 3 1 180 ffffb0804eaff6c0 rotatelogs pipe_rd
1685 1685 3 3 180 ffffb0804de375c0 rotatelogs pipe_rd
1688 1688 3 0 180 ffffb080130031c0 rotatelogs pipe_rd
1690 1690 3 2 180 ffffb08012feaa00 rotatelogs pipe_rd
1694 1694 3 3 180 ffffb08012f2e540 rotatelogs pipe_rd
1573 1573 3 1 180 ffffb0802a50c6c0 rotatelogs pipe_rd
2851 2851 3 3 180 ffffb08011ca1680 rotatelogs pipe_rd
1576 1576 3 1 180 ffffb08019108280 rotatelogs pipe_rd
3242 3242 3 1 180 ffffb08013190a80 rotatelogs pipe_rd
3244 3244 3 3 180 ffffb08013149580 rotatelogs pipe_rd
2765 2765 3 2 180 ffffb0801316b180 rotatelogs pipe_rd
2860 2860 3 1 180 ffffb080473250c0 rotatelogs pipe_rd
2621 2621 3 3 180 ffffb0801316d600 rotatelogs pipe_rd
1534 1534 3 1 180 ffffb0801316e200 rotatelogs pipe_rd
1531 1531 3 1 180 ffffb08013ec2180 rotatelogs pipe_rd
1528 1528 3 2 180 ffffb0801320d040 rotatelogs pipe_rd
1526 1526 3 1 180 ffffb08012d0aa80 rotatelogs pipe_rd
1524 1524 3 1 180 ffffb08012d41240 rotatelogs pipe_rd
1521 1521 3 3 180 ffffb08012d41680 rotatelogs pipe_rd
1519 1519 3 2 180 ffffb08012d0a640 rotatelogs pipe_rd
1517 1517 3 1 180 ffffb08012f2e980 rotatelogs pipe_rd
1387 1387 3 1 180 ffffb08010994a80 rotatelogs pipe_rd
2665 2665 3 0 180 ffffb08012fea5c0 rotatelogs pipe_rd
1674 1674 3 2 180 ffffb08012f09940 rotatelogs pipe_rd
22128 22128 3 0 180 ffffb08012f09500 rotatelogs pipe_rd
24789 24789 3 1 180 ffffb08012f2e100 rotatelogs pipe_rd
23656 23656 3 2 180 ffffb08012ef1080 rotatelogs pipe_rd
22125 22125 3 1 180 ffffb08012e958c0 rotatelogs pipe_rd
21126 21126 3 3 180 ffffb08012ef14c0 rotatelogs pipe_rd
21657 21657 3 3 180 ffffb08012ef1900 rotatelogs pipe_rd
24503 24503 3 1 180 ffffb08012f090c0 rotatelogs pipe_rd
17802 17802 3 3 180 ffffb0802a50c280 tcsh ttyraw
24397 24397 3 2 180 ffffb0804be280c0 tcsh ttyraw
2416 2416 3 2 1c0 ffffb08012405b00 screen select
2801 2801 3 0 180 ffffb0802915c300 tcsh ttyraw
21034 21034 3 3 180 ffffb08018f25680 sshd poll
14697 14697 3 0 180 ffffb0802915c740 sshd poll
29856 29856 3 2 180 ffffb0802a47cac0 tlsmgr kqueue
18725 18725 3 2 180 ffffb0804e29a680 qmgr kqueue
23774 23774 3 1 180 ffffb080199ad600 master kqueue
2985 2985 3 1 180 ffffb0801d722740 tcsh ttyraw
17774 17774 3 0 180 ffffb080440b1040 sshd poll
7073 7073 3 2 180 ffffb0802cb7d900 sshd poll
2995 29505 3 1 1c0 ffffb0801ba0d500 gnatsirc parked
2995 4150 3 2 180 ffffb0801bd50200 gnatsirc parked
2995 1785 3 3 10000180 ffffb0801be05240 gnatsirc kqueue
2995 1991 3 2 180 ffffb0801ba0d940 gnatsirc parked
2995 2242 3 1 1c0 ffffb0801bc891c0 gnatsirc parked
2995 3268 3 0 1c0 ffffb0801bc89a40 gnatsirc parked
2995 2241 3 2 180 ffffb0801bc89600 gnatsirc parked
2995 2995 3 0 1c0 ffffb0801ba0d0c0 gnatsirc parked
1889 10621 3 3 180 ffffb0801496b680 gnatsirc kqueue
1889 1262 3 0 180 ffffb08022cac1c0 gnatsirc parked
1889 3512 3 2 180 ffffb0801391a100 gnatsirc parked
1889 3511 3 2 180 ffffb0801bc3ca00 gnatsirc parked
1889 2998 3 0 1c0 ffffb08012410700 gnatsirc parked
1889 2997 3 3 1c0 ffffb0801496b240 gnatsirc parked
1889 4012 3 3 180 ffffb08013f39a40 gnatsirc parked
1889 1889 3 1 180 ffffb0801badc980 gnatsirc parked
2723 26524 3 1 180 ffffb08041189780 gnatsirc parked
2723 4514 3 3 180 ffffb08022b5d180 gnatsirc parked
2723 2993 3 0 180 ffffb0801af96700 gnatsirc kqueue
2723 2989 3 2 180 ffffb0801badc540 gnatsirc parked
2723 1959 3 0 1c0 ffffb0801bc3c180 gnatsirc parked
2723 1960 3 1 180 ffffb0801bafa9c0 gnatsirc parked
2723 1957 3 1 180 ffffb0801bafa580 gnatsirc parked
2723 2723 3 2 180 ffffb08013ec2a00 gnatsirc parked
2462 2462 3 1 180 ffffb0801bafa140 tmux kqueue
1201 1201 3 0 180 ffffb08010994200 getty ttyraw
1327 1327 3 3 180 ffffb08012fea180 httpd select
1243 1243 3 1 180 ffffb08012acf940 postdrop netio
1496 1496 3 3 180 ffffb08012a54900 sendmail pipe_rd
1481 11560 3 3 180 ffffb080124102c0 BulkTracker parked
1481 21309 3 2 180 ffffb0802175b940 BulkTracker parked
1481 21156 3 0 1c0 ffffb08022cac600 BulkTracker parked
1481 20194 3 2 180 ffffb08013dfe580 BulkTracker kqueue
1481 807 3 1 180 ffffb08022b5da00 BulkTracker parked
1481 16605 3 2 180 ffffb08012acf0c0 BulkTracker parked
1481 28994 3 0 180 ffffb0801e601480 BulkTracker parked
1481 23375 3 2 180 ffffb08010df1300 BulkTracker parked
1481 2664 3 0 180 ffffb0801aea4280 BulkTracker parked
1481 1635 3 1 1c0 ffffb0801455c200 BulkTracker parked
1481 1838 3 2 180 ffffb0801320d8c0 BulkTracker parked
1481 1572 3 1 180 ffffb0801320d480 BulkTracker parked
1481 1484 3 2 180 ffffb08012a54080 BulkTracker parked
1481 1480 3 3 180 ffffb0801297f8c0 BulkTracker parked
1481 1642 3 3 180 ffffb08010a2bb00 BulkTracker parked
1481 1487 3 2 180 ffffb08010fb68c0 BulkTracker parked
1481 998 3 2 180 ffffb08010fb6480 BulkTracker parked
1481 1481 3 3 1c0 ffffb08011ca1240 BulkTracker parked
1330 1330 3 0 180 ffffb08011556580 cron pipe_rd
1335 1335 3 1 180 ffffb080119e3200 cron nanoslp
1443 1443 3 2 180 ffffb0801297f480 inetd kqueue
1358 1358 3 0 180 ffffb0801297f040 ircd kqueue
1199 1199 3 0 180 ffffb080128cfbc0 postgres poll
1206 1206 3 3 180 ffffb080128cf780 postgres poll
1203 1203 3 1 180 ffffb080128cf340 postgres poll
1197 1197 3 3 180 ffffb0801256db80 postgres poll
1200 1200 3 0 180 ffffb0801256d740 postgres poll
1323 1323 3 3 180 ffffb0801256d300 postgres poll
1388 1388 3 1 180 ffffb0801011abc0 postgres select
981 981 3 2 180 ffffb080119e3a80 sshd poll
825 825 3 3 180 ffffb080119e3640 powerd kqueue
817 817 3 3 180 ffffb080115baa00 ntpd pause
855 855 3 3 180 ffffb080115ba5c0 xymonlaunch nanoslp
700 700 3 2 180 ffffb08010114b80 racoon select
692 692 3 3 180 ffffb080115569c0 blocklistd poll
478 1084 3 1 180 ffffb0801329a0c0 named parked
478 1595 3 0 180 ffffb0801326b4c0 named parked
478 1338 3 2 180 ffffb0801326b900 named parked
478 1081 3 1 180 ffffb0801329a500 named parked
478 578 3 2 180 ffffb0801152f980 timer parked
478 582 3 1 1c0 ffffb0801152f540 net-0007 kqueue
478 448 3 3 180 ffffb0801152f100 net-0006 kqueue
478 581 3 2 1c0 ffffb0801152e940 net-0005 kqueue
478 681 3 1 180 ffffb0801152e500 net-0004 kqueue
478 577 3 0 180 ffffb0801152e0c0 net-0003 kqueue
478 579 3 1 180 ffffb0801152a900 net-0002 kqueue
478 415 3 3 180 ffffb0801152a4c0 net-0001 kqueue
478 477 3 2 180 ffffb0801152a080 net-0000 kqueue
478 478 3 1 180 ffffb08010e3d340 named sigwait
442 442 3 2 180 ffffb08010df1b80 syslogd kqueue
468 468 3 2 180 ffffb08010fb6040 dhcpcd poll
467 467 3 2 180 ffffb08010e3dbc0 dhcpcd poll
466 466 3 1 180 ffffb08010e3d780 dhcpcd poll
465 465 3 2 180 ffffb08010df1740 dhcpcd poll
1 1 3 1 180 ffffb080107495c0 init wait
0 199 3 1 200 ffffb08010749a00 physiod physiod
0 167 3 2 200 ffffb08010969a40 pooldrain pooldrain
0 166 3 2 200 ffffb08010969600 ioflush syncer
0 165 3 3 200 ffffb080109691c0 pgdaemon pgdaemon
0 126 3 2 200 ffffb0801011a340 npfgc0 npfgcw
0 125 3 2 200 ffffb0801011a780 xen_balloon xen_balloon
0 124 3 3 200 ffffb08010749180 rt_free rt_free
0 123 3 1 240 ffffb0801073f9c0 unpgc unpgc
0 122 3 2 200 ffffb0801073f580 key_timehandler key_timehandler
0 121 3 3 200 ffffb0801073f140 icmp6_wqinput/3 icmp6_wqinput
0 120 3 2 200 ffffb0801073e980 icmp6_wqinput/2 icmp6_wqinput
0 119 3 1 200 ffffb0801073e540 icmp6_wqinput/1 icmp6_wqinput
0 118 3 0 200 ffffb0801073e100 icmp6_wqinput/0 icmp6_wqinput
0 117 3 0 200 ffffb08010129940 nd6_timer nd6_timer
0 116 3 3 200 ffffb08010129500 icmp_wqinput/3 icmp_wqinput
0 115 3 2 200 ffffb080101290c0 icmp_wqinput/2 icmp_wqinput
0 114 3 1 200 ffffb08010128900 icmp_wqinput/1 icmp_wqinput
0 113 3 0 200 ffffb080101284c0 icmp_wqinput/0 icmp_wqinput
0 112 3 1 200 ffffb08010128080 rt_timer rt_timer
0 111 3 1 200 ffffb0801011b8c0 vmem_rehash vmem_rehash
0 110 3 0 200 ffffb0801011b480 xenbus xsio
0 109 3 3 200 ffffb0801011b040 xenwatch evtsq
0 100 3 0 200 ffffb08010114300 entbutler entropy
0 98 3 3 200 ffffb0801010f700 xcall/3 xcall
0 97 1 3 200 ffffb0801010f2c0 softser/3
0 96 1 3 200 ffffb0801010eb00 softclk/3
0 30 1 3 200 ffffb0801010e6c0 softbio/3
0 29 1 3 200 ffffb0801010e280 softnet/3
0 28 1 3 201 ffffb0801010aac0 idle/3
0 27 3 2 200 ffffb0801010a680 xcall/2 xcall
0 26 1 2 200 ffffb0801010a240 softser/2
0 25 1 2 200 ffffb08010109a80 softclk/2
0 24 1 2 200 ffffb08010109640 softbio/2
0 23 1 2 200 ffffb08010109200 softnet/2
0 22 1 2 201 ffffb08010105a40 idle/2
0 21 3 1 200 ffffb08010105600 xcall/1 xcall
0 20 1 1 200 ffffb080101051c0 softser/1
0 19 1 1 200 ffffb08010104a00 softclk/1
0 18 1 1 200 ffffb080101045c0 softbio/1
0 17 1 1 200 ffffb08010104180 softnet/1
0 16 1 1 201 ffffb080100f39c0 idle/1
0 15 3 0 200 ffffb080100f3580 pmfsuspend pmfsuspend
0 14 3 0 200 ffffb080100f3140 pmfevent pmfevent
0 13 3 0 200 ffffb080100f0980 sopendfree sopendfr
0 12 3 3 200 ffffb080100f0540 ifwdog ifwdog
0 11 3 2 200 ffffb080100f0100 iflnkst iflnkst
0 10 3 0 200 ffffb0800f7d5940 nfssilly nfssilly
0 9 3 0 240 ffffb0800f7d5500 vdrain vdrain
0 8 3 1 200 ffffb0800f7d50c0 modunload mod_unld
0 7 3 0 200 ffffb0800f7cd900 xcall/0 xcall
0 6 1 0 200 ffffb0800f7cd4c0 softser/0
0 5 1 0 200 ffffb0800f7cd080 softclk/0
0 4 1 0 200 ffffb0800f7cb8c0 softbio/0
0 3 1 0 200 ffffb0800f7cb480 softnet/0
0 2 1 0 201 ffffb0800f7cb040 idle/0
0 0 3 1 200 ffffffff80660b80 swapper uvm
db{0}> show proc 0t9925
cvs: pid 9925 proc ffffb0801b236400 vmspace/map ffffb0804f1e8470 flags 0
> lwp 9925 ffffb0801111c700 pcb ffffb0825b550000
stat 7 flags 40100 cpu 0 pri 28 ref 0
db{0}> mach cpu 1
using CPU 1
db{0}> bt
address 0x7960bc72a89a is invalid
?() at 7960bc72a89a
address 0x7f7fff733f18 is invalid
address 0x7f7fff733f10 is invalid
?() at ffffb0825b554ad0
addb %al,0(%rax)
db{0}> mach cpu 2
using CPU 2
db{0}> bt
ufs_getattr() at netbsd:ufs_getattr+0x1
vn_stat() at netbsd:vn_stat+0x3d
do_sys_statat() at netbsd:do_sys_statat+0xdf
sys___lstat50() at netbsd:sys___lstat50+0x25
syscall() at netbsd:syscall+0x9c
--- syscall (number 441) ---
netbsd:syscall+0x9c:
db{0}> mach cpu 3
using CPU 3
db{0}> bt
hypercall_page() at netbsd:hypercall_page+0x34a
invlpg() at netbsd:invlpg+0x20
pmap_tlb_shootnow() at netbsd:pmap_tlb_shootnow+0x274
pmap_update() at netbsd:pmap_update+0x17
uvmfault_promote() at netbsd:uvmfault_promote+0x18c
uvm_fault_internal() at netbsd:uvm_fault_internal+0x21b5
trap() at netbsd:trap+0x46a
--- trap (number 6) ---
7a92c7029449:
>How-To-Repeat:
no idea
mollari knows how to repeat that. From Aug 10 ~12:00:
[ 234842.0580163] panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581
[ 234842.0580163] cpu3: Begin traceback...
[ 234842.0580163] vpanic() at netbsd:vpanic+0x177
[ 234842.0580163] kern_assert() at netbsd:kern_assert+0x4b
[ 234842.0580163] pmap_load() at netbsd:pmap_load+0x138
[ 234842.0580163] do_pmap_load() at netbsd:do_pmap_load+0x1d
[ 234842.0580163] copyout() at netbsd:copyout+0x48
[ 234842.0580163] ubc_uiomove() at netbsd:ubc_uiomove+0x165
[ 234842.0580163] ffs_read() at netbsd:ffs_read+0xf0
[ 234842.0580163] VOP_READ() at netbsd:VOP_READ+0x3c
[ 234842.0580163] vn_read() at netbsd:vn_read+0x16f
[ 234842.0580163] dofileread() at netbsd:dofileread+0x6f
[ 234842.0580163] sys_read() at netbsd:sys_read+0x49
[ 234842.0580163] syscall() at netbsd:syscall+0x9c
[ 234842.0580163] --- syscall (number 3) ---
[ 234842.0580163] netbsd:syscall+0x9c:
[ 234842.0580163] cpu3: End traceback...
[ 234842.0580163] fatal breakpoint trap in supervisor mode
[ 234842.0580163] trap type 1 code 0 rip 0xffffffff8022e975 cs 0x10000e030 rflags 0x2 cr2 0xffff980231c49000 ilevel 0 rsp 0xffff980241cb9a90
[ 234842.0580163] curlwp 0xffff980012aae340 pid 1577.1472 lowest kstack 0xffff980241cb52c0
Stopped in pid 1577.1472 (BulkTracker) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x177
kern_assert() at netbsd:kern_assert+0x4b
pmap_load() at netbsd:pmap_load+0x138
do_pmap_load() at netbsd:do_pmap_load+0x1d
copyout() at netbsd:copyout+0x48
ubc_uiomove() at netbsd:ubc_uiomove+0x165
ffs_read() at netbsd:ffs_read+0xf0
VOP_READ() at netbsd:VOP_READ+0x3c
vn_read() at netbsd:vn_read+0x16f
dofileread() at netbsd:dofileread+0x6f
sys_read() at netbsd:sys_read+0x49
syscall() at netbsd:syscall+0x9c
--- syscall (number 3) ---
netbsd:syscall+0x9c:
ds 8
es 3
fs 180
gs 9a40
rdi 0
rsi ffff980241cb97fc
rbp ffff980241cb9a90
rbx ffff9800105e0000
rdx 1
rcx ffffffffffffff
rax 800000000000000
r8 0
r9 0
r10 0
r11 fffffffe
r12 ffffffff80586b90 ostype+0x1d4
r13 ffff980241cb9ad8
r14 104
r15 b219e
rip ffffffff8022e975 breakpoint+0x5
cs e030
rflags 2
rsp ffff980241cb9a90
ss e02b
netbsd:breakpoint+0x5: leave
>Fix:
Yes, please!
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: port-xen-maintainer->bouyer
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Tue, 13 May 2025 15:30:14 +0000
Responsible-Changed-Why:
bouyer, can you take a look?
+cc cherry, who added the assertion back in 2011 with the cherry-xenmp
merge.
It's possible this is just some code path that does x86_disable_intr
without a necessary x86_read/write_psl around it to save and restore
the interrupt-disabled flag. But I think we've only seen it on Xen
so far (see also dup https://gnats.netbsd.org/57543), which might help
to narrow it down.
This #ifndef XENPV x86_disable/enable_intr looks suspicious but I have
only superficially skimmed it and I have no idea what's going on:
https://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/trap.c?r=1.129#554
(This bug has been biting mollari a lot lately, happened again today.)
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@netbsd.org
Cc: port-xen-maintainer@netbsd.org, netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion
"x86_read_psl() == 0" failed: file
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Thu, 12 Jun 2025 17:12:18 +0200
Hello,
sorry for taking so long for reply
On Tue, May 13, 2025 at 03:30:15PM +0000, riastradh@NetBSD.org wrote:
> Synopsis: panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581
>
> Responsible-Changed-From-To: port-xen-maintainer->bouyer
> Responsible-Changed-By: riastradh@NetBSD.org
> Responsible-Changed-When: Tue, 13 May 2025 15:30:14 +0000
> Responsible-Changed-Why:
> bouyer, can you take a look?
>
> +cc cherry, who added the assertion back in 2011 with the cherry-xenmp
> merge.
>
> It's possible this is just some code path that does x86_disable_intr
> without a necessary x86_read/write_psl around it to save and restore
> the interrupt-disabled flag. But I think we've only seen it on Xen
> so far (see also dup https://gnats.netbsd.org/57543), which might help
> to narrow it down.
>
> This #ifndef XENPV x86_disable/enable_intr looks suspicious but I have
> only superficially skimmed it and I have no idea what's going on:
>
> https://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/trap.c?r=1.129#554
>
> (This bug has been biting mollari a lot lately, happened again today.)
I've seen this too but only once in a (long) while. The last one
I found in my logs was last september.
I've no idea why the x86_disable/enable_intr in trap() is #ifndef XENPV.
This was added by ad@ in trap.c 1.46 (in Apr 2008) as part of the
kernel preemption work. AFAIK trap() is always called with events
enabled on Xen, so I can't see why Xen wouldn't need x86_disable_intr()
when bare metal needs it.
I'm now testing the attached patch; both amd64 and i386 domUs have
passed an anita run. I've installed in on the dom0 running the daily Xen
tests (https://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/);
it's in the middle of 2 anita runs. But I don't think I've ever seen
this KASSERT fire on this host.
If mollari is hitting this more often than what I'm seeing maybe it's
worth testing it there in a few days ?
Index: sys/arch/amd64/amd64/trap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/trap.c,v
retrieving revision 1.128
diff -u -p -u -r1.128 trap.c
--- sys/arch/amd64/amd64/trap.c 5 Sep 2020 07:26:37 -0000 1.128
+++ sys/arch/amd64/amd64/trap.c 12 Jun 2025 14:58:17 -0000
@@ -514,6 +514,10 @@ pagefltcommon:
goto we_re_toast;
}
#endif
+#ifdef XENPV
+ /* Check to see if interrupts are enabled (ie; no events are masked) */
+ KASSERT(x86_read_psl() == 0);
+#endif
/* Fault the original page in. */
onfault = pcb->pcb_onfault;
pcb->pcb_onfault = NULL;
@@ -552,17 +556,13 @@ pagefltcommon:
* the copy functions, and so visible
* to cpu_kpreempt_exit().
*/
-#ifndef XENPV
x86_disable_intr();
-#endif
l->l_nopreempt--;
if (l->l_nopreempt > 0 || !l->l_dopreempt ||
pfail) {
return;
}
-#ifndef XENPV
x86_enable_intr();
-#endif
/*
* If preemption fails for some reason,
* don't retry it. The conditions won't
Index: sys/arch/i386/i386/trap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/i386/trap.c,v
retrieving revision 1.308
diff -u -p -u -r1.308 trap.c
--- sys/arch/i386/i386/trap.c 20 Aug 2022 23:48:50 -0000 1.308
+++ sys/arch/i386/i386/trap.c 12 Jun 2025 14:58:17 -0000
@@ -632,6 +632,10 @@ faultcommon:
goto we_re_toast;
}
#endif
+#ifdef XENPV
+ /* Check to see if interrupts are enabled (ie; no events are masked) */
+ KASSERT(x86_read_psl() == 0);
+#endif
/* Fault the original page in. */
onfault = pcb->pcb_onfault;
pcb->pcb_onfault = NULL;
@@ -670,17 +674,13 @@ faultcommon:
* the copy functions, and so visible
* to cpu_kpreempt_exit().
*/
-#ifndef XENPV
x86_disable_intr();
-#endif
l->l_nopreempt--;
if (l->l_nopreempt > 0 || !l->l_dopreempt ||
pfail) {
return;
}
-#ifndef XENPV
x86_enable_intr();
-#endif
/*
* If preemption fails for some reason,
* don't retry it. The conditions won't
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: "Manuel Bouyer" <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58561 CVS commit: src/sys/arch
Date: Fri, 20 Jun 2025 17:02:18 +0000
Module Name: src
Committed By: bouyer
Date: Fri Jun 20 17:02:18 UTC 2025
Modified Files:
src/sys/arch/amd64/amd64: trap.c
src/sys/arch/i386/i386: trap.c
Log Message:
Remove #ifndef XENPV around x86_disable_intr()/enable_intr() in trap().
This was added by ad@ in trap.c 1.46 (in Apr 2008) as part of the
kernel preemption work. AFAIK trap() is always called with events
enabled on Xen, so I can't see why Xen wouldn't need x86_disable_intr()
when bare metal needs it.
Pointed out by riastradh@ in PR port-xen/58561, but it may be completely
irrelevant to the panic reported here.
To generate a diff of this commit:
cvs rdiff -u -r1.129 -r1.130 src/sys/arch/amd64/amd64/trap.c
cvs rdiff -u -r1.309 -r1.310 src/sys/arch/i386/i386/trap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Konrad Schroder <perseant@hhhh.org>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@netbsd.org, netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org, riastradh@NetBSD.org, campbell+netbsd@mumble.net,
cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Fri, 9 Jan 2026 07:24:17 -0800
I can reliably reproduce this issue, quickly enough that a NetBSD tools+release build usually will not complete before the system panics. I am using yesterday's -current, with a kernel config as follows:
netbsd# cat sys/arch/amd64/conf/LFS
include "arch/amd64/conf/XEN3_DOMU"
options LOCKDEBUG
The host system is Ubuntu 22.04.5 running xen-hypervisor-4.16-amd64, and the guest config is:
linux# cat lfs
name = "lfs"
kernel = "/etc/xen/netbsd-lfs.gz"
memory = 16384
vcpus = 2
vif = [ 'bridge=br0' ]
disk = [ '/dev/md3p6,raw,hda,rw' ]
on_poweroff = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
The load running on the system is from
./build.sh -j4 -U -u -O obj.amd64 tools release
in a freshly unpacked src.
If I configure the VM with "vcpus = 1", or turn off LOCKDEBUG, it doesn't panic.
(As the names imply, I'm hoping to use this configuration to test LFS, but the problem is unrelated: the system panics without any LFS file system ever having been active since boot.)
The panic traces vary, but are consistent after the call to copyout():
[ 842.2695658] panic: kernel diagnostic assertion "(psl = x86_read_psl()) == 0" failed: file "/home/src-current/sys/arch/x86/x86/pmap.c", line 3596 psl=0x1
[ 842.2695658] cpu1: Begin traceback...
[ 842.2695658] vpanic() at netbsd:vpanic+0x164
[ 842.2695658] kern_assert() at netbsd:kern_assert+0x4b
[ 842.2695658] pmap_load() at netbsd:pmap_load+0x13d
[ 842.2695658] do_pmap_load() at netbsd:do_pmap_load+0x1d
[ 842.2695658] copyout() at netbsd:copyout+0x48
[ 842.2695658] ubc_uiomove() at netbsd:ubc_uiomove+0x12e
[ 842.2695658] ffs_read() at netbsd:ffs_read+0xf0
[ 842.2695658] VOP_READ() at netbsd:VOP_READ+0x3c
[ 842.2695658] vn_rdwr() at netbsd:vn_rdwr+0x100
[ 842.2695658] vmcmd_readvn() at netbsd:vmcmd_readvn+0x56
[ 842.2695658] execve_runproc() at netbsd:execve_runproc+0x34e
[ 842.2695658] execve1() at netbsd:execve1+0x4c
[ 842.2695658] sys_execve() at netbsd:sys_execve+0x2a
[ 842.2695658] syscall() at netbsd:syscall+0x98
[ 842.2695658] --- syscall (number 59) ---
[ 842.2695658] netbsd:syscall+0x98:
[ 842.2695658] cpu1: End traceback...
Let me know if there is anything you'd like me to do to help test or further diagnose the issue.
Thanks,
Konrad Schroder
perseant@hhhh.org
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Konrad Schroder <perseant@hhhh.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Sat, 10 Jan 2026 13:55:33 +0100
--arOAjUDb+7TMRYPD
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
On Fri, Jan 09, 2026 at 07:24:17AM -0800, Konrad Schroder wrote:
> I can reliably reproduce this issue, quickly enough that a NetBSD
> tools+release build usually will not complete before the system panics. I
> am using yesterday's -current, with a kernel config as follows:
>
> netbsd# cat sys/arch/amd64/conf/LFS
> include "arch/amd64/conf/XEN3_DOMU"
>
> options LOCKDEBUG
>
> The host system is Ubuntu 22.04.5 running xen-hypervisor-4.16-amd64, and the
> guest config is:
>
> linux# cat lfs
> name = "lfs"
> kernel = "/etc/xen/netbsd-lfs.gz"
> memory = 16384
> vcpus = 2
> vif = [ 'bridge=br0' ]
> disk = [ '/dev/md3p6,raw,hda,rw' ]
>
> on_poweroff = 'destroy'
> on_reboot = 'destroy'
> on_crash = 'destroy'
>
> The load running on the system is from
>
> ./build.sh -j4 -U -u -O obj.amd64 tools release
>
> in a freshly unpacked src.
>
> If I configure the VM with "vcpus = 1", or turn off LOCKDEBUG, it doesn't
> panic.
>
> (As the names imply, I'm hoping to use this configuration to test LFS, but
> the problem is unrelated: the system panics without any LFS file system ever
> having been active since boot.)
>
> The panic traces vary, but are consistent after the call to copyout():
>
> [ 842.2695658] panic: kernel diagnostic assertion "(psl =
> x86_read_psl()) == 0" failed: file
> "/home/src-current/sys/arch/x86/x86/pmap.c", line 3596 psl=0x1
> [ 842.2695658] cpu1: Begin traceback...
> [ 842.2695658] vpanic() at netbsd:vpanic+0x164
> [ 842.2695658] kern_assert() at netbsd:kern_assert+0x4b
> [ 842.2695658] pmap_load() at netbsd:pmap_load+0x13d
> [ 842.2695658] do_pmap_load() at netbsd:do_pmap_load+0x1d
> [ 842.2695658] copyout() at netbsd:copyout+0x48
> [ 842.2695658] ubc_uiomove() at netbsd:ubc_uiomove+0x12e
> [ 842.2695658] ffs_read() at netbsd:ffs_read+0xf0
> [ 842.2695658] VOP_READ() at netbsd:VOP_READ+0x3c
> [ 842.2695658] vn_rdwr() at netbsd:vn_rdwr+0x100
> [ 842.2695658] vmcmd_readvn() at netbsd:vmcmd_readvn+0x56
> [ 842.2695658] execve_runproc() at netbsd:execve_runproc+0x34e
> [ 842.2695658] execve1() at netbsd:execve1+0x4c
> [ 842.2695658] sys_execve() at netbsd:sys_execve+0x2a
> [ 842.2695658] syscall() at netbsd:syscall+0x98
> [ 842.2695658] --- syscall (number 59) ---
> [ 842.2695658] netbsd:syscall+0x98:
> [ 842.2695658] cpu1: End traceback...
>
> Let me know if there is anything you'd like me to do to help test or further
> diagnose the issue.
Hello,
can you try with the attached patch ? It won't fix the problem but
should let us know if syscall() is already called with interrupts disabled,
or if they're disabled later
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--arOAjUDb+7TMRYPD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=diff
Index: sys/arch/amd64/amd64/copy.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/copy.S,v
retrieving revision 1.36
diff -u -p -u -r1.36 copy.S
--- sys/arch/amd64/amd64/copy.S 24 Sep 2024 20:19:30 -0000 1.36
+++ sys/arch/amd64/amd64/copy.S 10 Jan 2026 12:52:12 -0000
@@ -176,6 +176,7 @@ ENTRY(kcopy)
END(kcopy)
ENTRY(copyout)
+ call _C_LABEL(amd64_check_psl)
DEFERRED_SWITCH_CHECK
xchgq %rdi,%rsi /* kernel address to %rsi, user to %rdi */
Index: sys/arch/amd64/amd64/trap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/trap.c,v
retrieving revision 1.130
diff -u -p -u -r1.130 trap.c
--- sys/arch/amd64/amd64/trap.c 20 Jun 2025 17:02:18 -0000 1.130
+++ sys/arch/amd64/amd64/trap.c 10 Jan 2026 12:52:12 -0000
@@ -720,3 +722,13 @@ sigdebug(const struct trapframe *tf, con
frame_dump(tf, lwp_getpcb(l));
}
#endif
+
+void amd64_check_psl(void);
+void
+amd64_check_psl(void)
+{
+#ifdef XENPV
+ /* Check to see if interrupts are enabled (ie; no events are masked) */
+ KASSERT(x86_read_psl() == 0);
+#endif
+}
Index: sys/arch/x86/x86/syscall.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/x86/syscall.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 syscall.c
--- sys/arch/x86/x86/syscall.c 5 Oct 2023 19:41:06 -0000 1.22
+++ sys/arch/x86/x86/syscall.c 10 Jan 2026 12:52:12 -0000
@@ -48,6 +48,7 @@ __KERNEL_RCSID(0, "$NetBSD: syscall.c,v
#include <machine/userret.h>
#include "opt_dtrace.h"
+#include "opt_xen.h"
#ifndef __x86_64__
int x86_copyargs(void *, void *, size_t);
@@ -90,6 +91,10 @@ static
void
syscall(struct trapframe *frame)
{
+#ifdef XENPV
+ /* Check to see if interrupts are enabled (ie; no events are masked) */
+ KASSERT(x86_read_psl() == 0);
+#endif
const struct sysent *callp;
struct proc *p;
struct lwp *l;
--arOAjUDb+7TMRYPD--
From: Konrad Schroder <perseant@hhhh.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Sat, 10 Jan 2026 11:30:27 -0800
On 1/10/2026 4:55 AM, Manuel Bouyer wrote:
> Hello,
> can you try with the attached patch ? It won't fix the problem but
> should let us know if syscall() is already called with interrupts disabled,
> or if they're disabled later
Thanks! Unfortunately that blows up almost instantly:
Parsing config from lfs
[Â Â 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[Â Â 1.0000000]Â Â Â 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
2013,
[Â Â 1.0000000]Â Â Â 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022,
2023,
[Â Â 1.0000000]Â Â Â 2024, 2025, 2026
[  1.0000000]   The NetBSD Foundation, Inc. All rights reserved.
[Â Â 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[Â Â 1.0000000]Â Â Â The Regents of the University of California. All
rights reserved.
[Â Â 1.0000000] NetBSD 11.99.4 (LFS) #0: Sat Jan 10 11:16:12 PST 2026
[Â Â 1.0000000]
root@netbsd6:/home/src-current/obj.amd64/sys/arch/amd64/compile/LFS
[Â Â 1.0000000] total memory = 16384 MB
[Â Â 1.0000000] avail memory = 15808 MB
[Â Â 1.0000000] mainbus0 (root)
[Â Â 1.0000000] hypervisor0 at mainbus0: Xen version 4.16.0
[Â Â 1.0000000] vcpu0 at hypervisor0
[Â Â 1.0000000] vcpu0: AMD Opteron(tm) Processor 4334 Â Â Â , id 0x600f20
[Â Â 1.0000000] vcpu0: node 0, package 0, core 0, smt 0
[Â Â 1.0000000] vcpu1 at hypervisor0
[Â Â 1.0000000] vcpu1: AMD Opteron(tm) Processor 4334 Â Â Â , id 0x600f20
[Â Â 1.0000000] vcpu1: node 0, package 0, core 0, smt 0
[Â Â 1.0000000] xenbus0 at hypervisor0: Xen Virtual Bus Interface
[Â Â 1.0000000] xencons0 at hypervisor0: Xen Virtual Console Driver
[Â Â 1.0000000] WARNING: system needs entropy for security; see entropy(7)
[Â Â 1.5600517] xenbus0: can't get state for device/suspend/event-channel (2)
[Â Â 1.5700553] xbd0 at xenbus0 id 768: Xen Virtual Block Device Interface
[Â Â 1.5700553] xennet0 at xenbus0 id 0: Xen Virtual Network Interface
[Â Â 1.5700553] xennet0: backend features 0x7<IPV6-CSUM,SG,RX-COPY>
[Â Â 1.5700553] xennet0: MAC address 00:16:3e:41:a3:13
[Â Â 1.5800784] balloon0 at xenbus0 id 0: Xen Balloon driver
[Â Â 1.5800784] balloon0: current reservation: 16777216 KiB
[Â Â 1.5800784] xenbus0: can't get state for device/suspend/event-channel (2)
[Â Â 1.5800784] balloon0: current reservation: 4194304 pages => target:
4194304 pages
[Â Â 1.5800784] xbd0: 1863 GB, 512 bytes/sect x 3907110912 sectors
[Â Â 1.5800784] xbd0: backend features 0xc<PERSISTENT,INDIRECT>
[Â Â 1.6000892] dk0 at xbd0: "fe6007c0-0019-40f8-a4ed-04267298e957",
2097152 blocks at 2048, type: ffs
[Â Â 1.6000892] dk1 at xbd0: "57ff5f51-1beb-48c8-9eb9-045e087e6217",
4194304 blocks at 2099200, type: swap
[Â Â 1.6000892] dk2 at xbd0: "813c4368-95e7-444a-ae58-44162b21c9c6",
16777216 blocks at 6293504, type: ffs
[Â Â 1.6000892] dk3 at xbd0: "04353643-24a2-4aa0-b864-c5b4e4f928d8",
8388608 blocks at 23070720, type: ffs
[Â Â 1.6000892] dk4 at xbd0: "home", 4194304 blocks at 31459328, type: ffs
[Â Â 1.6000892] dk5 at xbd0: "data", 8388608 blocks at 35653632, type: ffs
[Â Â 1.6000892] dk6 at xbd0: "data2", 16777216 blocks at 44042240, type: ffs
[Â Â 1.6000892] dk7 at xbd0: "data3", 33554432 blocks at 60819456, type: ffs
[Â Â 1.6000892] dk8 at xbd0: "data4", 67108864 blocks at 94373888, type: ffs
[Â Â 1.6000892] dk9 at xbd0: "data5", 134217728 blocks at 161482752,
type: ffs
[Â Â 1.6000892] dk10 at xbd0: "data6", 268435456 blocks at 295700480,
type: ffs
[Â Â 1.6000892] dk11 at xbd0: "data7", 536870912 blocks at 564135936,
type: lfs
[Â Â 1.6000892] dk12 at xbd0: "data8", 1073741824 blocks at 1101006848,
type: lfs
[Â Â 1.6000892] dk13 at xbd0: "data9", 1732360192 blocks at 2174748672,
type: ffs
[Â Â 1.6000892] xenbus0: can't get state for device/suspend/event-channel (2)
[Â Â 1.6100784] WARNING: 3 errors while detecting hardware; check system log.
[Â Â 1.6100784] boot device: dk0
[Â Â 1.6100784] root on dk0 dumps on dk1
[Â Â 1.6100784] Your machine does not initialize mem_clusters;
sparse_dumps disabled
[Â Â 1.6200746] /: replaying log to memory
[Â Â 1.6401308] root file system type: ffs
[Â Â 1.6401308] kern.module.path=/stand/amd64/11.99.4/modules
[Â Â 1.6501331] panic: copyout 14
[Â Â 1.6501331] cpu1: Begin traceback...
[Â Â 1.6501331] vpanic() at netbsd:vpanic+0x164
[Â Â 1.6501331] panic() at netbsd:panic+0x3c
[Â Â 1.7700918] start_init() at netbsd:start_init+0x4be
[Â Â 1.7700918] cpu1: End traceback...
[Â Â 1.7700918] fatal breakpoint trap in supervisor mode
[Â Â 1.7700918] trap type 1 code 0 rip 0xffffffff80230965 cs 0xe030
rflags 0x202 cr2 0 ilevel 0 rsp 0xffffbd84c32f0d20
[Â Â 1.7700918] curlwp 0xffffbd8021aa9000 pid 1.1 lowest kstack
0xffffbd84c32ec2c0
Stopped in pid 1.1 (init) at  netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x164
panic() at netbsd:panic+0x3c
start_init() at netbsd:start_init+0x4be
ds     0
es     1
fs     1
gs     cd0
rdi     0
rsi     2d6
rbp     ffffbd84c32f0d20
rbx     ffffffff806c0663  ostype+0x1337b
rdx     1
rcx     ffffffffffffff
rax     800000000000000
r8Â Â Â Â Â 0
r9Â Â Â Â Â 0
r10Â Â Â Â Â fffffffe
r11Â Â Â Â Â ffffffff806b8ad0Â Â ostype+0xb7e8
r12Â Â Â Â Â ffffbd84c32f0d68
r13Â Â Â Â Â 104
r14Â Â Â Â Â 1
r15Â Â Â Â Â 0
rip     ffffffff80230965  breakpoint+0x5
cs     e030
rflags   202
rsp     ffffbd84c32f0d20
ss     e02b
netbsd:breakpoint+0x5:Â leave
db{1}>
It seems to me like amd64_check_psl() has some side effects that are
messing up the registers for the call to copyout(), but I don't know
almost anything about x86 assembly....
Thanks,
-Konrad
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Konrad Schroder <perseant@hhhh.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Sat, 10 Jan 2026 22:01:05 +0100
--L07qoGXM5nk0oetQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
On Sat, Jan 10, 2026 at 11:30:27AM -0800, Konrad Schroder wrote:
> On 1/10/2026 4:55 AM, Manuel Bouyer wrote:
> > Hello,
> > can you try with the attached patch ? It won't fix the problem but
> > should let us know if syscall() is already called with interrupts disabled,
> > or if they're disabled later
>
> Thanks! Unfortunately that blows up almost instantly:
> [...]
Sorry; I should have checked more carefully. As there's a
call _C_LABEL(do_pmap_load)
early I assumed it was safe to call C functions here but do_pmap_load()
is in fact written in assembly.
Here's an updated patch which uses only assembly in copy.S
Also it adds the check to all copy* functions, not only copyout.
It boots multiuser on my test system.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--L07qoGXM5nk0oetQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=diff
Index: sys/arch/amd64/amd64/copy.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/copy.S,v
retrieving revision 1.36
diff -u -p -u -r1.36 copy.S
--- sys/arch/amd64/amd64/copy.S 24 Sep 2024 20:19:30 -0000 1.36
+++ sys/arch/amd64/amd64/copy.S 10 Jan 2026 20:56:54 -0000
@@ -47,12 +47,14 @@
movq CPUVAR(CURLWP),reg; \
movq L_PCB(reg),reg
+
/*
* These are arranged so that the abnormal case is a forwards
* conditional branch - which will be predicted not-taken by
* both Intel and AMD processors.
*/
#define DEFERRED_SWITCH_CHECK \
+ call _C_LABEL(do_check_psl) ; \
CHECK_DEFERRED_SWITCH ; \
jnz 99f ; \
98:
@@ -70,6 +72,33 @@
x86_copyfunc_start: .globl x86_copyfunc_start
+pslmsg: .ascii "do_check_psl failed"
+ENTRY(do_check_psl)
+ pushq %rbp
+ movq %rsp,%rbp
+ pushq %rbx
+ movq CPUVAR(CURLWP),%rbx
+ incl L_NOPREEMPT(%rbx)
+ movq CPUVAR(VCPU), %rax
+ movzbl EVTCHN_UPCALL_MASK(%rax),%eax
+ decl L_NOPREEMPT(%rbx)
+ test %eax,%eax
+ jne 198f
+ popq %rbx
+ leaveq
+ ret
+198:
+ movq $pslmsg, %rdi
+ callq _C_LABEL(panic)
+ popq %rbx
+ leaveq
+ ret
+END(do_check_psl)
+
+
+
+
+
/*
* Handle deferred pmap switch. We must re-enable preemption without
* making a function call, so that the program counter is visible to
Index: sys/arch/x86/x86/syscall.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/x86/syscall.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 syscall.c
--- sys/arch/x86/x86/syscall.c 5 Oct 2023 19:41:06 -0000 1.22
+++ sys/arch/x86/x86/syscall.c 10 Jan 2026 20:56:54 -0000
@@ -48,6 +48,7 @@ __KERNEL_RCSID(0, "$NetBSD: syscall.c,v
#include <machine/userret.h>
#include "opt_dtrace.h"
+#include "opt_xen.h"
#ifndef __x86_64__
int x86_copyargs(void *, void *, size_t);
@@ -90,6 +91,10 @@ static
void
syscall(struct trapframe *frame)
{
+#ifdef XENPV
+ /* Check to see if interrupts are enabled (ie; no events are masked) */
+ KASSERT(x86_read_psl() == 0);
+#endif
const struct sysent *callp;
struct proc *p;
struct lwp *l;
--L07qoGXM5nk0oetQ--
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Konrad Schroder <perseant@hhhh.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Sat, 10 Jan 2026 23:33:30 +0100
--DyYqzEZ4vXS0XQ4C
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
On Sat, Jan 10, 2026 at 10:01:05PM +0100, Manuel Bouyer wrote:
> On Sat, Jan 10, 2026 at 11:30:27AM -0800, Konrad Schroder wrote:
> > On 1/10/2026 4:55 AM, Manuel Bouyer wrote:
> > > Hello,
> > > can you try with the attached patch ? It won't fix the problem but
> > > should let us know if syscall() is already called with interrupts disabled,
> > > or if they're disabled later
> >
> > Thanks! Unfortunately that blows up almost instantly:
> > [...]
>
>
> Sorry; I should have checked more carefully. As there's a
> call _C_LABEL(do_pmap_load)
> early I assumed it was safe to call C functions here but do_pmap_load()
> is in fact written in assembly.
> Here's an updated patch which uses only assembly in copy.S
> Also it adds the check to all copy* functions, not only copyout.
> It boots multiuser on my test system.
And this assembly work may have allowed me to find the problem.
Basically, the CLI and STI macros are not atomic on Xen PV, and if preemption
happens at a bad time we may end up updating the upcall_mask of our previous
CPU. The attached patch should close this race condition; hopefully it's
the last one.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--DyYqzEZ4vXS0XQ4C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=diff2
Index: sys/arch/amd64/include/frameasm.h
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/include/frameasm.h,v
retrieving revision 1.55
diff -u -p -u -r1.55 frameasm.h
--- sys/arch/amd64/include/frameasm.h 30 Jul 2022 14:11:00 -0000 1.55
+++ sys/arch/amd64/include/frameasm.h 10 Jan 2026 22:30:12 -0000
@@ -24,13 +24,22 @@
#define NOT_XEN(x)
#define CLI(temp_reg) \
+ movq CPUVAR(CURLWP),%r ## temp_reg ; \
+ incl L_NOPREEMPT(%r ## temp_reg); \
movq CPUVAR(VCPU),%r ## temp_reg ; \
- movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
+ movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ movq CPUVAR(CURLWP),%r ## temp_reg ; \
+ decl L_NOPREEMPT(%r ## temp_reg); \
#define STI(temp_reg) \
+ movq CPUVAR(CURLWP),%r ## temp_reg ; \
+ incl L_NOPREEMPT(%r ## temp_reg); \
movq CPUVAR(VCPU),%r ## temp_reg ; \
- movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg);
+ movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ movq CPUVAR(CURLWP),%r ## temp_reg ; \
+ decl L_NOPREEMPT(%r ## temp_reg); \
+#if 0
#define PUSHF(temp_reg) \
movq CPUVAR(VCPU),%r ## temp_reg ; \
movzbl EVTCHN_UPCALL_MASK(%r ## temp_reg), %e ## temp_reg; \
@@ -39,6 +48,7 @@
#define POPF \
popq %rdi; \
call _C_LABEL(xen_write_psl)
+#endif
--DyYqzEZ4vXS0XQ4C--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Konrad Schroder <perseant@hhhh.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
gnats-admin@NetBSD.org, cherry@NetBSD.org, port-xen@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Sun, 11 Jan 2026 17:21:12 +0000
> Date: Sat, 10 Jan 2026 23:33:30 +0100
> From: Manuel Bouyer <bouyer@antioche.eu.org>
>=20
> And this assembly work may have allowed me to find the problem.
> Basically, the CLI and STI macros are not atomic on Xen PV, and if preemp=
tion
> happens at a bad time we may end up updating the upcall_mask of our previ=
ous
> CPU. The attached patch should close this race condition; hopefully it's
> the last one.
Nice! I fixed some of this a few years ago but I must have neglected
to search further for other uses like the assembly stubs using
EVTCHN_UPCALL_MASK and EVTCHN_UPCALL_PENDING:
https://mail-index.netbsd.org/source-changes/2023/02/25/msg143510.html
There are still a lot of suspicious cases that turn up when I grep -i
for evtchn_upcall:
- i386/spl.S -- might be fine because they're in the spllower and
doreti paths, so maybe preemption is already blocked by virtue of
having raised ipl, but needs another set of eyeballs to be sure:
https://nxr.netbsd.org/xref/src/sys/arch/i386/i386/spl.S?r=3D1.58#218
https://nxr.netbsd.org/xref/src/sys/arch/i386/i386/spl.S?r=3D1.58#291
- i386 CLI/STI macros:
https://nxr.netbsd.org/xref/src/sys/arch/i386/include/frameasm.h?r=3D1.35=
#12
(Maybe we can just nix XEN_BLOCK/UNBLOCK_EVENTS and XEN_TEST_PENDING
and merge those into the CLI/STI macros?)
- amd64 profile stubs:
https://nxr.netbsd.org/xref/src/sys/arch/amd64/include/profile.h?r=3D1.21=
#82
(Not sure why there's no obvious i386 analogue of that? The i386
code has no XENPV conditionals.)
- xen_init_amd64/i386_vcpuctxt -- guessing this runs before interrupts
or preemption can happen, but unclear, needs more eyeballs:
https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/cpu.c?r=3D1.145#850
https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/cpu.c?r=3D1.145#947
- do_hypervisor_callback -- does this run with ipl raised so
preemption is not possible? If so, can we assert the ipl is raised?
https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/hypervisor_machdep.c?r=
=3D1.46#301
- hypervisor_send_event -- this is #if 0 code, can we delete it and
the one #if 0 caller in sys/arch/xen/xen/evtchn.c so we don't have
to think about it? If not, I think we should either
KASSERT(kpreempt_disabled()) or assert the ipl is raised.
https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/hypervisor_machdep.c?r=
=3D1.46#336
https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/evtchn.c?r=3D1.100#383
- xen_debug_handler -- this runs with ipl raised, right? Maybe not
worth asserting because this is a debug vector so dumping info is
better than crashing.
https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/evtchn.c?r=3D1.100#1142
Also, I think we should either:
(a) delete the PUSHF/POPF macros altogether, if they're unused, or
(b) make sure they too block preemption in the critical path.
From: Konrad Schroder <perseant@hhhh.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Sun, 11 Jan 2026 20:35:10 -0800
On 1/10/2026 2:33 PM, Manuel Bouyer wrote:
> And this assembly work may have allowed me to find the problem.
> Basically, the CLI and STI macros are not atomic on Xen PV, and if preemption
> happens at a bad time we may end up updating the upcall_mask of our previous
> CPU. The attached patch should close this race condition; hopefully it's
> the last one.
I can confirm that, at least in my case, this allows me to build
continuously all day without a crash.
Thanks!
Konrad Schroder
perseant@hhhh.org
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Konrad Schroder <perseant@hhhh.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
gnats-admin@NetBSD.org, cherry@NetBSD.org, port-xen@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Mon, 12 Jan 2026 22:42:57 +0100
On Sun, Jan 11, 2026 at 05:21:12PM +0000, Taylor R Campbell wrote:
> > Date: Sat, 10 Jan 2026 23:33:30 +0100
> > From: Manuel Bouyer <bouyer@antioche.eu.org>
> >
> > And this assembly work may have allowed me to find the problem.
> > Basically, the CLI and STI macros are not atomic on Xen PV, and if preemption
> > happens at a bad time we may end up updating the upcall_mask of our previous
> > CPU. The attached patch should close this race condition; hopefully it's
> > the last one.
>
> Nice! I fixed some of this a few years ago but I must have neglected
> to search further for other uses like the assembly stubs using
> EVTCHN_UPCALL_MASK and EVTCHN_UPCALL_PENDING:
>
> https://mail-index.netbsd.org/source-changes/2023/02/25/msg143510.html
>
> There are still a lot of suspicious cases that turn up when I grep -i
> for evtchn_upcall:
>
> - i386/spl.S -- might be fine because they're in the spllower and
> doreti paths, so maybe preemption is already blocked by virtue of
> having raised ipl, but needs another set of eyeballs to be sure:
>
> https://nxr.netbsd.org/xref/src/sys/arch/i386/i386/spl.S?r=1.58#218
> https://nxr.netbsd.org/xref/src/sys/arch/i386/i386/spl.S?r=1.58#291
>
> - i386 CLI/STI macros:
>
> https://nxr.netbsd.org/xref/src/sys/arch/i386/include/frameasm.h?r=1.35#12
>
> (Maybe we can just nix XEN_BLOCK/UNBLOCK_EVENTS and XEN_TEST_PENDING
> and merge those into the CLI/STI macros?)
Yes, i386 needs a look too. Wlll do later.
>
> - amd64 profile stubs:
>
> https://nxr.netbsd.org/xref/src/sys/arch/amd64/include/profile.h?r=1.21#82
>
> (Not sure why there's no obvious i386 analogue of that? The i386
> code has no XENPV conditionals.)
Maybe a Xen/i386 profiling kernel has never been tried. Or maybe Xen emulates
cli and related
>
> - xen_init_amd64/i386_vcpuctxt -- guessing this runs before interrupts
> or preemption can happen, but unclear, needs more eyeballs:
>
> https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/cpu.c?r=1.145#850
> https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/cpu.c?r=1.145#947
Yes, this runs before interrupts are enabled.
>
> - do_hypervisor_callback -- does this run with ipl raised so
> preemption is not possible? If so, can we assert the ipl is raised?
>
> https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/hypervisor_machdep.c?r=1.46#301
It's called from interrupt context (with ci_idepth raised) so preemtion should
not be possible.
>
> - hypervisor_send_event -- this is #if 0 code, can we delete it and
> the one #if 0 caller in sys/arch/xen/xen/evtchn.c so we don't have
> to think about it? If not, I think we should either
> KASSERT(kpreempt_disabled()) or assert the ipl is raised.
>
> https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/hypervisor_machdep.c?r=1.46#336
> https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/evtchn.c?r=1.100#383
Sure, I deleted it.
>
> - xen_debug_handler -- this runs with ipl raised, right? Maybe not
> worth asserting because this is a debug vector so dumping info is
> better than crashing.
>
> https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/evtchn.c?r=1.100#1142
That's the idea; and also it's called from interrupt context so no
preemtion possible
>
> Also, I think we should either:
>
> (a) delete the PUSHF/POPF macros altogether, if they're unused, or
>
> (b) make sure they too block preemption in the critical path.
AFAIK they're unused, I will remove them.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Konrad Schroder <perseant@hhhh.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Mon, 12 Jan 2026 23:20:34 +0100
--bYTERQBjABj6NPgt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sun, Jan 11, 2026 at 08:35:10PM -0800, Konrad Schroder wrote:
> On 1/10/2026 2:33 PM, Manuel Bouyer wrote:
> > And this assembly work may have allowed me to find the problem.
> > Basically, the CLI and STI macros are not atomic on Xen PV, and if preemption
> > happens at a bad time we may end up updating the upcall_mask of our previous
> > CPU. The attached patch should close this race condition; hopefully it's
> > the last one.
>
> I can confirm that, at least in my case, this allows me to build
> continuously all day without a crash.
Good, it points that we're on the right track.
Can you try the attached patch instead ? It tries to limit the extra
instructions to only places where it's needed, and add DIAGNOSTIC code
to check it's really not needed in other places.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--bYTERQBjABj6NPgt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=diff2
Index: sys/arch/amd64/amd64/amd64_trap.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/amd64_trap.S,v
retrieving revision 1.55
diff -u -p -u -r1.55 amd64_trap.S
--- sys/arch/amd64/amd64/amd64_trap.S 27 Feb 2023 16:24:28 -0000 1.55
+++ sys/arch/amd64/amd64/amd64_trap.S 12 Jan 2026 22:17:57 -0000
@@ -90,7 +90,7 @@
*/
#ifdef XENPV
-#define PRE_TRAP CLI(cx); movq (%rsp),%rcx ; movq 8(%rsp),%r11 ; addq $0x10,%rsp
+#define PRE_TRAP CLI2(cx,r11); movq (%rsp),%rcx ; movq 8(%rsp),%r11 ; addq $0x10,%rsp
#else
#define PRE_TRAP
#endif
@@ -671,7 +671,7 @@ calltrap:
.Lalltraps_checkast:
movq CPUVAR(CURLWP),%r14
/* Check for ASTs on exit to user mode. */
- CLI(si)
+ CLI2(si, rdi)
CHECK_ASTPENDING(%r14)
je 3f
CLEAR_ASTPENDING(%r14)
Index: sys/arch/amd64/amd64/cpufunc.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/cpufunc.S,v
retrieving revision 1.70
diff -u -p -u -r1.70 cpufunc.S
--- sys/arch/amd64/amd64/cpufunc.S 6 Sep 2025 02:53:22 -0000 1.70
+++ sys/arch/amd64/amd64/cpufunc.S 12 Jan 2026 22:17:57 -0000
@@ -184,7 +184,7 @@ ENTRY(wbinvd)
END(wbinvd)
ENTRY(setusergs)
- CLI(ax)
+ CLI2(ax, rdi)
swapgs
movw %di, %gs
swapgs
Index: sys/arch/amd64/amd64/locore.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v
retrieving revision 1.235
diff -u -p -u -r1.235 locore.S
--- sys/arch/amd64/amd64/locore.S 31 Dec 2025 15:33:50 -0000 1.235
+++ sys/arch/amd64/amd64/locore.S 12 Jan 2026 22:17:57 -0000
@@ -1641,7 +1641,7 @@ ENTRY(handle_syscall)
* to ensure we don't take an interrupt with some of the user
* registers loaded.
*/
- CLI(si)
+ CLI2(si, rax)
/* Check for ASTs on exit to user mode. */
movl L_MD_ASTPENDING(%r14),%eax
orl CPUVAR(WANT_PMAPLOAD),%eax
@@ -1768,7 +1768,9 @@ IDTVEC(\name)
* But it didn't disable events
*/
pushq %rsi
- CLI(si)
+ pushq %rdi
+ CLI2(si, rdi)
+ popq %rdi
popq %rsi
addq $0x10,%rsp /* gap to match cs:rip */
pushq $2 /* error code */
@@ -1813,7 +1815,9 @@ IDTVEC_END(syscall32)
IDTVEC(osyscall)
#ifdef XENPV
pushq %rsi
- CLI(si)
+ pushq %rdi
+ CLI2(si, rdi)
+ popq %rdi
popq %rsi
movq (%rsp),%rcx
movq 8(%rsp),%r11
Index: sys/arch/amd64/amd64/machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.378
diff -u -p -u -r1.378 machdep.c
--- sys/arch/amd64/amd64/machdep.c 21 Dec 2025 07:00:26 -0000 1.378
+++ sys/arch/amd64/amd64/machdep.c 12 Jan 2026 22:17:57 -0000
@@ -2462,3 +2462,8 @@ idt_vec_init_cpu_md(struct idt_vec *iv,
iv->iv_idt = (void *)idt_vaddr;
}
}
+
+#if defined(DIAGNOSTIC) && defined(XENPV)
+const char *cli_panic = "cli with preemtion";
+const char *sti_panic = "sti with interrupts enabled";
+#endif
Index: sys/arch/amd64/amd64/spl.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/spl.S,v
retrieving revision 1.49
diff -u -p -u -r1.49 spl.S
--- sys/arch/amd64/amd64/spl.S 1 Mar 2023 08:38:50 -0000 1.49
+++ sys/arch/amd64/amd64/spl.S 12 Jan 2026 22:17:57 -0000
@@ -378,7 +378,7 @@ IDTVEC(doreti)
movq %rsp,%rdi
KMSAN_INIT_ARG(8)
call _C_LABEL(trap)
- CLI(si)
+ CLI2(si, rdi)
jmp .Ldoreti_checkast
3:
CHECK_DEFERRED_SWITCH
@@ -389,6 +389,6 @@ IDTVEC(doreti)
9:
STI(si)
call _C_LABEL(do_pmap_load)
- CLI(si)
+ CLI2(si, rdi)
jmp .Ldoreti_checkast /* recheck ASTs */
IDTVEC_END(doreti)
Index: sys/arch/amd64/include/frameasm.h
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/include/frameasm.h,v
retrieving revision 1.55
diff -u -p -u -r1.55 frameasm.h
--- sys/arch/amd64/include/frameasm.h 30 Jul 2022 14:11:00 -0000 1.55
+++ sys/arch/amd64/include/frameasm.h 12 Jan 2026 22:17:57 -0000
@@ -23,31 +23,68 @@
#define XEN_ONLY2(x,y) x,y
#define NOT_XEN(x)
+#ifdef DIAGNOSTIC
+/*
+ * acessing EVTCHN_UPCALL_MASK is save only if preemption is disabled, i.e.:
+ * l_nopreempt is not 0, or
+ * ci_ilevel is nit 0, or
+ * EVTCHN_UPCALL_MASK is not 0
+ * ci_idepth is not negative
+ */
#define CLI(temp_reg) \
- movq CPUVAR(VCPU),%r ## temp_reg ; \
+ movq CPUVAR(CURLWP),%r ## temp_reg ; \
+ cmpl $0, L_NOPREEMPT(%r ## temp_reg); \
+ jne 199f; \
+ cmpb $0, CPUVAR(ILEVEL); \
+ jne 199f; \
+ movl CPUVAR(IDEPTH), %e ## temp_reg; \
+ test %eax, %eax; \
+ jns 199f; \
+ movq $panicstr,%r ## temp_reg ; \
+ cmpq $0, 0(%r ## temp_reg); \
+ jne 199f; \
+ movq _C_LABEL(cli_panic), %rdi; \
+ call _C_LABEL(panic); \
+199: movq CPUVAR(VCPU),%r ## temp_reg ; \
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
#define STI(temp_reg) \
movq CPUVAR(VCPU),%r ## temp_reg ; \
- movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg);
+ cmpb $0, EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ jne 198f; \
+ movq $panicstr,%r ## temp_reg ; \
+ cmpq $0, 0(%r ## temp_reg); \
+ jne 198f; \
+ movq _C_LABEL(sti_panic), %rdi; \
+ call _C_LABEL(panic); \
+198: movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ movq CPUVAR(CURLWP),%r ## temp_reg ;
+#else
+
+#define CLI(temp_reg) \
+ movq CPUVAR(VCPU),%r ## temp_reg ; \
+ movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
-#define PUSHF(temp_reg) \
+#define STI(temp_reg) \
movq CPUVAR(VCPU),%r ## temp_reg ; \
- movzbl EVTCHN_UPCALL_MASK(%r ## temp_reg), %e ## temp_reg; \
- pushq %r ## temp_reg
+ movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
-#define POPF \
- popq %rdi; \
- call _C_LABEL(xen_write_psl)
+#endif /* DIAGNOSTIC */
+/* CLI() with preemtion disabled */
+#define CLI2(temp_reg, temp_reg2) \
+ movq CPUVAR(CURLWP),% ## temp_reg2 ; \
+ incl L_NOPREEMPT(% ## temp_reg2); \
+ movq CPUVAR(VCPU),%r ## temp_reg ; \
+ movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ decl L_NOPREEMPT(% ## temp_reg2);
#else /* XENPV */
#define XEN_ONLY2(x,y)
#define NOT_XEN(x) x
#define CLI(temp_reg) cli
+#define CLI2(temp_reg, temp_reg2) cli
#define STI(temp_reg) sti
-#define PUSHF(temp_reg) pushf
-#define POPL popl
#endif /* XENPV */
#define HP_NAME_CLAC 1
--bYTERQBjABj6NPgt--
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Konrad Schroder <perseant@hhhh.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Tue, 13 Jan 2026 15:23:14 +0100
On Mon, Jan 12, 2026 at 11:20:34PM +0100, Manuel Bouyer wrote:
> On Sun, Jan 11, 2026 at 08:35:10PM -0800, Konrad Schroder wrote:
> > On 1/10/2026 2:33 PM, Manuel Bouyer wrote:
> > > And this assembly work may have allowed me to find the problem.
> > > Basically, the CLI and STI macros are not atomic on Xen PV, and if preemption
> > > happens at a bad time we may end up updating the upcall_mask of our previous
> > > CPU. The attached patch should close this race condition; hopefully it's
> > > the last one.
> >
> > I can confirm that, at least in my case, this allows me to build
> > continuously all day without a crash.
>
> Good, it points that we're on the right track.
> Can you try the attached patch instead ? It tries to limit the extra
> instructions to only places where it's needed, and add DIAGNOSTIC code
> to check it's really not needed in other places.
Sorry this patch has a bug; working on an updated version
stay tuned.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Konrad Schroder <perseant@hhhh.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Tue, 13 Jan 2026 15:50:10 +0100
--RDx6QZJo8LJcQjtp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Jan 13, 2026 at 03:23:14PM +0100, Manuel Bouyer wrote:
> On Mon, Jan 12, 2026 at 11:20:34PM +0100, Manuel Bouyer wrote:
> > On Sun, Jan 11, 2026 at 08:35:10PM -0800, Konrad Schroder wrote:
> > > On 1/10/2026 2:33 PM, Manuel Bouyer wrote:
> > > > And this assembly work may have allowed me to find the problem.
> > > > Basically, the CLI and STI macros are not atomic on Xen PV, and if preemption
> > > > happens at a bad time we may end up updating the upcall_mask of our previous
> > > > CPU. The attached patch should close this race condition; hopefully it's
> > > > the last one.
> > >
> > > I can confirm that, at least in my case, this allows me to build
> > > continuously all day without a crash.
> >
> > Good, it points that we're on the right track.
> > Can you try the attached patch instead ? It tries to limit the extra
> > instructions to only places where it's needed, and add DIAGNOSTIC code
> > to check it's really not needed in other places.
>
> Sorry this patch has a bug; working on an updated version
> stay tuned.
Here's the updated patch
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--RDx6QZJo8LJcQjtp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=diff2
Index: amd64/amd64/amd64_trap.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/amd64_trap.S,v
retrieving revision 1.55
diff -u -p -u -r1.55 amd64_trap.S
--- amd64/amd64/amd64_trap.S 27 Feb 2023 16:24:28 -0000 1.55
+++ amd64/amd64/amd64_trap.S 13 Jan 2026 14:48:25 -0000
@@ -90,7 +90,7 @@
*/
#ifdef XENPV
-#define PRE_TRAP CLI(cx); movq (%rsp),%rcx ; movq 8(%rsp),%r11 ; addq $0x10,%rsp
+#define PRE_TRAP CLI2(cx,r11); movq (%rsp),%rcx ; movq 8(%rsp),%r11 ; addq $0x10,%rsp
#else
#define PRE_TRAP
#endif
@@ -671,7 +671,7 @@ calltrap:
.Lalltraps_checkast:
movq CPUVAR(CURLWP),%r14
/* Check for ASTs on exit to user mode. */
- CLI(si)
+ CLI2(si, rdi)
CHECK_ASTPENDING(%r14)
je 3f
CLEAR_ASTPENDING(%r14)
Index: amd64/amd64/cpufunc.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/cpufunc.S,v
retrieving revision 1.70
diff -u -p -u -r1.70 cpufunc.S
--- amd64/amd64/cpufunc.S 6 Sep 2025 02:53:22 -0000 1.70
+++ amd64/amd64/cpufunc.S 13 Jan 2026 14:48:25 -0000
@@ -184,7 +184,7 @@ ENTRY(wbinvd)
END(wbinvd)
ENTRY(setusergs)
- CLI(ax)
+ CLI2(ax, rdi)
swapgs
movw %di, %gs
swapgs
Index: amd64/amd64/locore.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v
retrieving revision 1.235
diff -u -p -u -r1.235 locore.S
--- amd64/amd64/locore.S 31 Dec 2025 15:33:50 -0000 1.235
+++ amd64/amd64/locore.S 13 Jan 2026 14:48:25 -0000
@@ -1641,7 +1641,7 @@ ENTRY(handle_syscall)
* to ensure we don't take an interrupt with some of the user
* registers loaded.
*/
- CLI(si)
+ CLI2(si, rax)
/* Check for ASTs on exit to user mode. */
movl L_MD_ASTPENDING(%r14),%eax
orl CPUVAR(WANT_PMAPLOAD),%eax
@@ -1768,7 +1768,9 @@ IDTVEC(\name)
* But it didn't disable events
*/
pushq %rsi
- CLI(si)
+ pushq %rdi
+ CLI2(si, rdi)
+ popq %rdi
popq %rsi
addq $0x10,%rsp /* gap to match cs:rip */
pushq $2 /* error code */
@@ -1813,7 +1815,9 @@ IDTVEC_END(syscall32)
IDTVEC(osyscall)
#ifdef XENPV
pushq %rsi
- CLI(si)
+ pushq %rdi
+ CLI2(si, rdi)
+ popq %rdi
popq %rsi
movq (%rsp),%rcx
movq 8(%rsp),%r11
Index: amd64/amd64/spl.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/spl.S,v
retrieving revision 1.49
diff -u -p -u -r1.49 spl.S
--- amd64/amd64/spl.S 1 Mar 2023 08:38:50 -0000 1.49
+++ amd64/amd64/spl.S 13 Jan 2026 14:48:25 -0000
@@ -313,6 +313,7 @@ END(spllower)
* a lower-prio one first, which needs to take the kernel lock -->
* the sending CPU will never see the that CPU accept the IPI
* (see pmap_tlb_shootnow).
+ * XenPV note: it seems that we can be called at spl0, so need to use CLI2()
*/
IDTVEC(spllower)
pushq %rbx
@@ -323,7 +324,7 @@ IDTVEC(spllower)
1:
movl %ebx,%eax /* get cpl */
movq CPUVAR(IUNMASK)(,%rax,8),%rax
- CLI(si)
+ CLI2(si, r12)
andq CPUVAR(IPENDING),%rax /* any non-masked bits left? */
jz 2f
bsrq %rax,%rax
@@ -355,7 +356,7 @@ IDTVEC(doreti)
1:
movl %ebx,%eax
movq CPUVAR(IUNMASK)(,%rax,8),%rax
- CLI(si)
+ CLI2(si, r14)
andq CPUVAR(IPENDING),%rax
jz 2f
bsrq %rax,%rax /* slow, but not worth optimizing */
@@ -378,7 +379,7 @@ IDTVEC(doreti)
movq %rsp,%rdi
KMSAN_INIT_ARG(8)
call _C_LABEL(trap)
- CLI(si)
+ CLI2(si, rdi)
jmp .Ldoreti_checkast
3:
CHECK_DEFERRED_SWITCH
@@ -389,6 +390,6 @@ IDTVEC(doreti)
9:
STI(si)
call _C_LABEL(do_pmap_load)
- CLI(si)
+ CLI2(si, rdi)
jmp .Ldoreti_checkast /* recheck ASTs */
IDTVEC_END(doreti)
Index: amd64/include/frameasm.h
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/include/frameasm.h,v
retrieving revision 1.55
diff -u -p -u -r1.55 frameasm.h
--- amd64/include/frameasm.h 30 Jul 2022 14:11:00 -0000 1.55
+++ amd64/include/frameasm.h 13 Jan 2026 14:48:25 -0000
@@ -23,31 +23,68 @@
#define XEN_ONLY2(x,y) x,y
#define NOT_XEN(x)
+#ifdef DIAGNOSTIC
+/*
+ * acessing EVTCHN_UPCALL_MASK is save only if preemption is disabled, i.e.:
+ * l_nopreempt is not 0, or
+ * ci_ilevel is nit 0, or
+ * EVTCHN_UPCALL_MASK is not 0
+ * ci_idepth is not negative
+ */
#define CLI(temp_reg) \
- movq CPUVAR(VCPU),%r ## temp_reg ; \
+ movq CPUVAR(CURLWP),%r ## temp_reg ; \
+ cmpl $0, L_NOPREEMPT(%r ## temp_reg); \
+ jne 199f; \
+ cmpb $0, CPUVAR(ILEVEL); \
+ jne 199f; \
+ movl CPUVAR(IDEPTH), %e ## temp_reg; \
+ test %e ## temp_reg, %e ## temp_reg; \
+ jns 199f; \
+ movq $panicstr,%r ## temp_reg ; \
+ cmpq $0, 0(%r ## temp_reg); \
+ jne 199f; \
+ movq _C_LABEL(cli_panic), %rdi; \
+ call _C_LABEL(panic); \
+199: movq CPUVAR(VCPU),%r ## temp_reg ; \
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
#define STI(temp_reg) \
movq CPUVAR(VCPU),%r ## temp_reg ; \
- movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg);
+ cmpb $0, EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ jne 198f; \
+ movq $panicstr,%r ## temp_reg ; \
+ cmpq $0, 0(%r ## temp_reg); \
+ jne 198f; \
+ movq _C_LABEL(sti_panic), %rdi; \
+ call _C_LABEL(panic); \
+198: movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ movq CPUVAR(CURLWP),%r ## temp_reg ;
+#else
+
+#define CLI(temp_reg) \
+ movq CPUVAR(VCPU),%r ## temp_reg ; \
+ movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
-#define PUSHF(temp_reg) \
+#define STI(temp_reg) \
movq CPUVAR(VCPU),%r ## temp_reg ; \
- movzbl EVTCHN_UPCALL_MASK(%r ## temp_reg), %e ## temp_reg; \
- pushq %r ## temp_reg
+ movb $0,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
-#define POPF \
- popq %rdi; \
- call _C_LABEL(xen_write_psl)
+#endif /* DIAGNOSTIC */
+/* CLI() with preemtion disabled */
+#define CLI2(temp_reg, temp_reg2) \
+ movq CPUVAR(CURLWP),% ## temp_reg2 ; \
+ incl L_NOPREEMPT(% ## temp_reg2); \
+ movq CPUVAR(VCPU),%r ## temp_reg ; \
+ movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
+ decl L_NOPREEMPT(% ## temp_reg2);
#else /* XENPV */
#define XEN_ONLY2(x,y)
#define NOT_XEN(x) x
#define CLI(temp_reg) cli
+#define CLI2(temp_reg, temp_reg2) cli
#define STI(temp_reg) sti
-#define PUSHF(temp_reg) pushf
-#define POPL popl
#endif /* XENPV */
#define HP_NAME_CLAC 1
Index: xen/x86/xen_intr.c
===================================================================
RCS file: /cvsroot/src/sys/arch/xen/x86/xen_intr.c,v
retrieving revision 1.31
diff -u -p -u -r1.31 xen_intr.c
--- xen/x86/xen_intr.c 25 Feb 2023 00:32:13 -0000 1.31
+++ xen/x86/xen_intr.c 13 Jan 2026 14:48:26 -0000
@@ -540,3 +547,9 @@ __strong_alias(cpu_intr_init, xen_cpu_in
__strong_alias(intr_allocate_io_intrsource, xen_intr_allocate_io_intrsource);
__strong_alias(intr_free_io_intrsource, xen_intr_free_io_intrsource);
#endif /* XENPV */
+
+
+#if defined(DIAGNOSTIC) && defined(XENPV)
+const char *cli_panic = "cli with preemtion";
+const char *sti_panic = "sti with interrupts enabled";
+#endif
--RDx6QZJo8LJcQjtp--
From: Konrad Schroder <perseant@hhhh.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org,
campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Wed, 14 Jan 2026 11:22:36 -0800
On 1/13/26 06:50, Manuel Bouyer wrote:
> On Tue, Jan 13, 2026 at 03:23:14PM +0100, Manuel Bouyer wrote:
>> On Mon, Jan 12, 2026 at 11:20:34PM +0100, Manuel Bouyer wrote:
>>
>> Sorry this patch has a bug; working on an updated version
>> stay tuned.
> Here's the updated patch
>
The updated patch also survived an entire day of builds without
crashing. Thanks!
Konrad Schroder
perseant@hhhh.org
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Konrad Schroder <perseant@hhhh.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@netbsd.org, netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org, campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Wed, 14 Jan 2026 23:00:10 +0000
> Date: Tue, 13 Jan 2026 15:50:10 +0100
> From: Manuel Bouyer <bouyer@antioche.eu.org>
>=20
> Here's the updated patch
Thanks for working on this! Some small issues:
> --- amd64/amd64/cpufunc.S 6 Sep 2025 02:53:22 -0000 1.70
> +++ amd64/amd64/cpufunc.S 13 Jan 2026 14:48:25 -0000
> @@ -184,7 +184,7 @@ ENTRY(wbinvd)
> END(wbinvd)
> =20
> ENTRY(setusergs)
> - CLI(ax)
> + CLI2(ax, rdi)
> swapgs
> movw %di, %gs
> swapgs
I think this can't be right. %rdi is obviously not a free scratch
register: it's the first argument register. But also, this code isn't
even used in Xen builds, is it? Xen has its own setusergs in
xenfunc.c, doesn't it?
https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/xenfunc.c?r=3D1.29#270
> --- amd64/amd64/spl.S 1 Mar 2023 08:38:50 -0000 1.49
> +++ amd64/amd64/spl.S 13 Jan 2026 14:48:25 -0000
> ...
> @@ -355,7 +356,7 @@ IDTVEC(doreti)
> 1:
> movl %ebx,%eax
> movq CPUVAR(IUNMASK)(,%rax,8),%rax
> - CLI(si)
> + CLI2(si, r14)
> andq CPUVAR(IPENDING),%rax
> jz 2f
> bsrq %rax,%rax /* slow, but not worth optimizing */
> @@ -378,7 +379,7 @@ IDTVEC(doreti)
> movq %rsp,%rdi
> KMSAN_INIT_ARG(8)
> call _C_LABEL(trap)
> - CLI(si)
> + CLI2(si, rdi)
> jmp .Ldoreti_checkast
> 3:
> CHECK_DEFERRED_SWITCH
> @@ -389,6 +390,6 @@ IDTVEC(doreti)
> 9:
> STI(si)
> call _C_LABEL(do_pmap_load)
> - CLI(si)
> + CLI2(si, rdi)
> jmp .Ldoreti_checkast /* recheck ASTs */
> IDTVEC_END(doreti)
Not immediately clear these registers are free here, can we
double-check and document in a comment exactly what registers are
involved on entry and exit to doreti?
> --- amd64/include/frameasm.h 30 Jul 2022 14:11:00 -0000 1.55
> +++ amd64/include/frameasm.h 13 Jan 2026 14:48:25 -0000
> ...
> + * ci_ilevel is nit 0, or
Nit: not `nit', `not'!
> + cmpl $0, L_NOPREEMPT(%r ## temp_reg); \
> + jne 199f; \
> ...
> +199: movq CPUVAR(VCPU),%r ## temp_reg ; \
> movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
Would be nice if we could make this work so the static branch
prediction (forward jump not taken) takes the right path here, but I
guess it's a pain because this is really doing
KASSERT(l->l_nopreempt !=3D 0 || curcpu()->ci_ilevel !=3D 0 || ...)
> + movq $panicstr,%r ## temp_reg ; \
Should this use _C_LABEL for consistency?
> + cmpq $0, 0(%r ## temp_reg); \
I always get confused about C symbols in MOV assembly directives.
Does temp_reg at this point hold a (possibly null) pointer to the
first character of the panic string, or a (possibly null) pointer to
the _pointer to_ first character of the panic string?
Shouldn't this be one of the two options?
leaq $panicstr,%rtmp
cmpq $0, 0(%rtmp)
or
movq $panicstr,%rtmp
cmpq $0,%rtmp
> + movq _C_LABEL(cli_panic), %rdi; \
> + call _C_LABEL(panic); \
Have you tested provoking this path to make sure it leads to a
sensible-looking panic?
> +/* CLI() with preemtion disabled */
> +#define CLI2(temp_reg, temp_reg2) \
> + movq CPUVAR(CURLWP),% ## temp_reg2 ; \
> + incl L_NOPREEMPT(% ## temp_reg2); \
> + movq CPUVAR(VCPU),%r ## temp_reg ; \
> + movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
> + decl L_NOPREEMPT(% ## temp_reg2);
Or, as an alternative to all the above issues... What if we just make
CLI work using a single temporary register? Requires one extra load
to reuse the register but I bet modern x86 CPUs will do enough fancy
register renaming and caching internally that it makes essentially no
difference except perhaps for a few bytes of code size:
movq CPUVAR(curlwp),%r ## temp_reg;
incl L_NOPREEMPT(%r ## temp_reg);
movq CPUVAR(VCPU),%r ## temp_reg2;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
movq CPUVAR(curlwp),%r ## temp_reg;
decl L_NOPREEMPT(%r ## temp_reg);
> --- xen/x86/xen_intr.c 25 Feb 2023 00:32:13 -0000 1.31
> +++ xen/x86/xen_intr.c 13 Jan 2026 14:48:26 -0000
> @@ -540,3 +547,9 @@ __strong_alias(cpu_intr_init, xen_cpu_in
> __strong_alias(intr_allocate_io_intrsource, xen_intr_allocate_io_intrsou=
rce);
> __strong_alias(intr_free_io_intrsource, xen_intr_free_io_intrsource);
> #endif /* XENPV */
> +
> +
> +#if defined(DIAGNOSTIC) && defined(XENPV)
> +const char *cli_panic =3D "cli with preemtion";
> +const char *sti_panic =3D "sti with interrupts enabled";
> +#endif
const char cli_panic[] =3D "cli with preemtion";
const char sti_panic[] =3D "sti with interrupts enabled";
Don't need a mutable pointer to the immutable string in memory -- just
a symbol for the string is enough.
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Konrad Schroder <perseant@hhhh.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@netbsd.org, netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org, campbell+netbsd@mumble.net, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Thu, 15 Jan 2026 11:25:33 +0100
On Wed, Jan 14, 2026 at 11:00:10PM +0000, Taylor R Campbell wrote:
> > Date: Tue, 13 Jan 2026 15:50:10 +0100
> > From: Manuel Bouyer <bouyer@antioche.eu.org>
> >
> > Here's the updated patch
>
> Thanks for working on this! Some small issues:
thanks for the review,
>
> > --- amd64/amd64/cpufunc.S 6 Sep 2025 02:53:22 -0000 1.70
> > +++ amd64/amd64/cpufunc.S 13 Jan 2026 14:48:25 -0000
> > @@ -184,7 +184,7 @@ ENTRY(wbinvd)
> > END(wbinvd)
> >
> > ENTRY(setusergs)
> > - CLI(ax)
> > + CLI2(ax, rdi)
> > swapgs
> > movw %di, %gs
> > swapgs
>
> I think this can't be right. %rdi is obviously not a free scratch
> register: it's the first argument register. But also, this code isn't
> even used in Xen builds, is it? Xen has its own setusergs in
> xenfunc.c, doesn't it?
Right, I changed it to use %rsi. Also as you noted this is not used for
Xen at this time (which is why I didn't notice I guess), but I think it's
better to be correct and use the appropriate macro here (even if it always
end up being a single cli instruction at this time)
>
> https://nxr.netbsd.org/xref/src/sys/arch/xen/x86/xenfunc.c?r=1.29#270
>
> > --- amd64/amd64/spl.S 1 Mar 2023 08:38:50 -0000 1.49
> > +++ amd64/amd64/spl.S 13 Jan 2026 14:48:25 -0000
> > ...
> > @@ -355,7 +356,7 @@ IDTVEC(doreti)
> > 1:
> > movl %ebx,%eax
> > movq CPUVAR(IUNMASK)(,%rax,8),%rax
> > - CLI(si)
> > + CLI2(si, r14)
> > andq CPUVAR(IPENDING),%rax
> > jz 2f
> > bsrq %rax,%rax /* slow, but not worth optimizing */
> > @@ -378,7 +379,7 @@ IDTVEC(doreti)
> > movq %rsp,%rdi
> > KMSAN_INIT_ARG(8)
> > call _C_LABEL(trap)
> > - CLI(si)
> > + CLI2(si, rdi)
> > jmp .Ldoreti_checkast
> > 3:
> > CHECK_DEFERRED_SWITCH
> > @@ -389,6 +390,6 @@ IDTVEC(doreti)
> > 9:
> > STI(si)
> > call _C_LABEL(do_pmap_load)
> > - CLI(si)
> > + CLI2(si, rdi)
> > jmp .Ldoreti_checkast /* recheck ASTs */
> > IDTVEC_END(doreti)
>
> Not immediately clear these registers are free here, can we
> double-check and document in a comment exactly what registers are
> involved on entry and exit to doreti?
I added "rsi, rdi and r14 - free for local use". rsi was already used here,
r14 is also used by CHECK_ASTPENDING()/CLEAR_ASTPENDING() and rdi for the
call to trap().
>
> > --- amd64/include/frameasm.h 30 Jul 2022 14:11:00 -0000 1.55
> > +++ amd64/include/frameasm.h 13 Jan 2026 14:48:25 -0000
> > ...
> > + * ci_ilevel is nit 0, or
>
> Nit: not `nit', `not'!
>
> > + cmpl $0, L_NOPREEMPT(%r ## temp_reg); \
> > + jne 199f; \
> > ...
> > +199: movq CPUVAR(VCPU),%r ## temp_reg ; \
> > movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
>
> Would be nice if we could make this work so the static branch
> prediction (forward jump not taken) takes the right path here, but I
> guess it's a pain because this is really doing
>
> KASSERT(l->l_nopreempt != 0 || curcpu()->ci_ilevel != 0 || ...)
yes, that's the problem. Also it's DIAGNOSTIC code so I prefer to
keep it easy to read.
>
> > + movq $panicstr,%r ## temp_reg ; \
>
> Should this use _C_LABEL for consistency?
Fixed
>
> > + cmpq $0, 0(%r ## temp_reg); \
>
> I always get confused about C symbols in MOV assembly directives.
> Does temp_reg at this point hold a (possibly null) pointer to the
> first character of the panic string, or a (possibly null) pointer to
> the _pointer to_ first character of the panic string?
temp_reg holds the address of the pointer (that is, &panicstr), and this
cannot be NULL. So the cmpq checks the pointer itself.
I know this code works because I went there multiple times while debugging :)
>
> Shouldn't this be one of the two options?
>
> leaq $panicstr,%rtmp
> cmpq $0, 0(%rtmp)
I guess this would check *panicstr, that is, the 8 first character of the
panicstr string
>
> or
>
> movq $panicstr,%rtmp
> cmpq $0,%rtmp
that would check &panicstr, which cannot be NULL
>
> > + movq _C_LABEL(cli_panic), %rdi; \
> > + call _C_LABEL(panic); \
>
> Have you tested provoking this path to make sure it leads to a
> sensible-looking panic?
Ho yes, multiple times :)
>
> > +/* CLI() with preemtion disabled */
> > +#define CLI2(temp_reg, temp_reg2) \
> > + movq CPUVAR(CURLWP),% ## temp_reg2 ; \
> > + incl L_NOPREEMPT(% ## temp_reg2); \
> > + movq CPUVAR(VCPU),%r ## temp_reg ; \
> > + movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg); \
> > + decl L_NOPREEMPT(% ## temp_reg2);
>
> Or, as an alternative to all the above issues... What if we just make
> CLI work using a single temporary register? Requires one extra load
> to reuse the register but I bet modern x86 CPUs will do enough fancy
> register renaming and caching internally that it makes essentially no
> difference except perhaps for a few bytes of code size:
Yes, you're probably right it wouldn't make much difference.
But we always have an extra free register, except in syscall entries.
I choose to save an instruction most of the time.
>
> movq CPUVAR(curlwp),%r ## temp_reg;
> incl L_NOPREEMPT(%r ## temp_reg);
> movq CPUVAR(VCPU),%r ## temp_reg2;
> movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
> movq CPUVAR(curlwp),%r ## temp_reg;
> decl L_NOPREEMPT(%r ## temp_reg);
>
> > --- xen/x86/xen_intr.c 25 Feb 2023 00:32:13 -0000 1.31
> > +++ xen/x86/xen_intr.c 13 Jan 2026 14:48:26 -0000
> > @@ -540,3 +547,9 @@ __strong_alias(cpu_intr_init, xen_cpu_in
> > __strong_alias(intr_allocate_io_intrsource, xen_intr_allocate_io_intrsource);
> > __strong_alias(intr_free_io_intrsource, xen_intr_free_io_intrsource);
> > #endif /* XENPV */
> > +
> > +
> > +#if defined(DIAGNOSTIC) && defined(XENPV)
> > +const char *cli_panic = "cli with preemtion";
> > +const char *sti_panic = "sti with interrupts enabled";
> > +#endif
>
> const char cli_panic[] = "cli with preemtion";
> const char sti_panic[] = "sti with interrupts enabled";
>
> Don't need a mutable pointer to the immutable string in memory -- just
> a symbol for the string is enough.
Yes, but how do we do this in C ?
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Konrad Schroder <perseant@hhhh.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
gnats-admin@NetBSD.org, cherry@NetBSD.org
Subject: Re: port-xen/58561 (panic: kernel diagnostic assertion,
"x86_read_psl() == 0" failed: file,
"/home/netbsd/10/src/sys/arch/x86/x86/pmap.c", line 3581)
Date: Fri, 16 Jan 2026 00:44:04 +0000
> Date: Thu, 15 Jan 2026 11:25:33 +0100
> From: Manuel Bouyer <bouyer@antioche.eu.org>
>=20
> On Wed, Jan 14, 2026 at 11:00:10PM +0000, Taylor R Campbell wrote:
> > > Date: Tue, 13 Jan 2026 15:50:10 +0100
> > > From: Manuel Bouyer <bouyer@antioche.eu.org>
> > >=20
> > > ENTRY(setusergs)
> > > - CLI(ax)
> > > + CLI2(ax, rdi)
> > > swapgs
> > > movw %di, %gs
> > > swapgs
> >=20
> > I think this can't be right. %rdi is obviously not a free scratch
> > register: it's the first argument register. But also, this code isn't
> > even used in Xen builds, is it? Xen has its own setusergs in
> > xenfunc.c, doesn't it?
>=20
> Right, I changed it to use %rsi. Also as you noted this is not used for
> Xen at this time (which is why I didn't notice I guess), but I think it's
> better to be correct and use the appropriate macro here (even if it always
> end up being a single cli instruction at this time)
OK, fair enough.
> > Not immediately clear these registers are free here, can we
> > double-check and document in a comment exactly what registers are
> > involved on entry and exit to doreti?
>=20
> I added "rsi, rdi and r14 - free for local use". rsi was already used her=
e,=20
> r14 is also used by CHECK_ASTPENDING()/CLEAR_ASTPENDING() and rdi for the
> call to trap().
OK, thanks!
> > > + cmpq $0, 0(%r ## temp_reg); \
> >=20
> > I always get confused about C symbols in MOV assembly directives.
> > Does temp_reg at this point hold a (possibly null) pointer to the
> > first character of the panic string, or a (possibly null) pointer to
> > the _pointer to_ first character of the panic string?
>=20
> temp_reg holds the address of the pointer (that is, &panicstr), and this
> cannot be NULL. So the cmpq checks the pointer itself.
> I know this code works because I went there multiple times while debuggin=
g :)
Great! Thanks, yes, my LEA suggestion was nonsense and my MOV
suggestion was useless. I was confusing
movq $foo,%reg
with
movq foo,%reg
> > > +#if defined(DIAGNOSTIC) && defined(XENPV)
> > > +const char *cli_panic =3D "cli with preemtion";
> > > +const char *sti_panic =3D "sti with interrupts enabled";
> > > +#endif
> >=20
> > const char cli_panic[] =3D "cli with preemtion";
> > const char sti_panic[] =3D "sti with interrupts enabled";
> >=20
> > Don't need a mutable pointer to the immutable string in memory -- just
> > a symbol for the string is enough.
>=20
> Yes, but how do we do this in C ?
I'm saying right now you're using
const char *sli_panic =3D ...
but if you use
const char sli_panic[] =3D ...
it'll save some .data space.
$ head morespace.c lessspace.c
=3D=3D> morespace.c <=3D=3D
const char *msg =3D "hello";
=3D=3D> lessspace.c <=3D=3D
const char msg[] =3D "hello";
$ make morespace.o lessspace.o
cc -O2 -c morespace.c
cc -O2 -c lessspace.c
$ size morespace.o lessspace.o
text data bss dec hex filename
6 8 0 14 e morespace.o
6 0 0 6 6 lessspace.o
From: "Manuel Bouyer" <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58561 CVS commit: src/sys/arch/x86/x86
Date: Sat, 17 Jan 2026 10:42:39 +0000
Module Name: src
Committed By: bouyer
Date: Sat Jan 17 10:42:39 UTC 2026
Modified Files:
src/sys/arch/x86/x86: fpu.c
Log Message:
fputrap: enable interrupts before panic(), for consistency.
noticed while working on PR port-xen/58561
To generate a diff of this commit:
cvs rdiff -u -r1.93 -r1.94 src/sys/arch/x86/x86/fpu.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Manuel Bouyer" <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58561 CVS commit: src/sys/arch
Date: Sat, 17 Jan 2026 10:53:20 +0000
Module Name: src
Committed By: bouyer
Date: Sat Jan 17 10:53:19 UTC 2026
Modified Files:
src/sys/arch/amd64/amd64: amd64_trap.S cpufunc.S locore.S spl.S
src/sys/arch/amd64/include: frameasm.h
src/sys/arch/xen/x86: xen_intr.c
Log Message:
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movq CPUVAR(VCPU),%r ## temp_reg ;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/amd64:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI
while there, remove PUSHF/POPF macros which are unused
Hopefully fixes PR port-xen/58561
Thanks to Konrad Schroder for testing and Taylor R Campbell for review.
To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.56 src/sys/arch/amd64/amd64/amd64_trap.S
cvs rdiff -u -r1.70 -r1.71 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.235 -r1.236 src/sys/arch/amd64/amd64/locore.S
cvs rdiff -u -r1.49 -r1.50 src/sys/arch/amd64/amd64/spl.S
cvs rdiff -u -r1.55 -r1.56 src/sys/arch/amd64/include/frameasm.h
cvs rdiff -u -r1.31 -r1.32 src/sys/arch/xen/x86/xen_intr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Manuel Bouyer" <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58561 CVS commit: src/sys/arch/i386
Date: Sat, 17 Jan 2026 10:59:10 +0000
Module Name: src
Committed By: bouyer
Date: Sat Jan 17 10:59:10 UTC 2026
Modified Files:
src/sys/arch/i386/i386: i386_trap.S locore.S spl.S
src/sys/arch/i386/include: frameasm.h
Log Message:
Port amd64 fix for PR port-xen/58561 to i386, with one extra fix:
with recent Xen (maybe since pvshim), traps handlers are called with
interrupts enabled, so adjust the i386 assembly code for this.
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movl CPUVAR(VCPU),reg
movb $1,EVTCHN_UPCALL_MASK(reg)
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/i386:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI and STIC
- rename PUSHF to PUSHFCLI and change it to both read and disable
EVTCHN_UPCALL_MASK with preemption disabled
- remove the XENPVHVM version of STIC which is unused
To generate a diff of this commit:
cvs rdiff -u -r1.24 -r1.25 src/sys/arch/i386/i386/i386_trap.S
cvs rdiff -u -r1.205 -r1.206 src/sys/arch/i386/i386/locore.S
cvs rdiff -u -r1.58 -r1.59 src/sys/arch/i386/i386/spl.S
cvs rdiff -u -r1.35 -r1.36 src/sys/arch/i386/include/frameasm.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: bouyer@NetBSD.org
State-Changed-When: Sat, 17 Jan 2026 11:03:13 +0000
State-Changed-Why:
Hopefully fixed in HEAD; needs pullups to -9, -10, -11
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Sat, 24 Jan 2026 22:34:35 +0000
State-Changed-Why:
pullup-11 #165
pullup-10 #1226
pullup-9 #1998
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58561 CVS commit: [netbsd-11] src/sys/arch
Date: Sun, 25 Jan 2026 16:36:41 +0000
Module Name: src
Committed By: martin
Date: Sun Jan 25 16:36:40 UTC 2026
Modified Files:
src/sys/arch/amd64/amd64 [netbsd-11]: amd64_trap.S cpufunc.S locore.S
spl.S
src/sys/arch/amd64/include [netbsd-11]: frameasm.h
src/sys/arch/i386/i386 [netbsd-11]: i386_trap.S locore.S spl.S
src/sys/arch/i386/include [netbsd-11]: frameasm.h
src/sys/arch/x86/x86 [netbsd-11]: fpu.c
src/sys/arch/xen/x86 [netbsd-11]: xen_intr.c
Log Message:
Pull up following revision(s) (requested by bouyer in ticket #165):
sys/arch/amd64/include/frameasm.h: revision 1.56
sys/arch/xen/x86/xen_intr.c: revision 1.32
sys/arch/i386/include/frameasm.h: revision 1.36
sys/arch/i386/i386/locore.S: revision 1.206
sys/arch/amd64/amd64/cpufunc.S: revision 1.71
sys/arch/i386/i386/i386_trap.S: revision 1.25
sys/arch/i386/i386/spl.S: revision 1.59
sys/arch/amd64/amd64/locore.S: revision 1.236
sys/arch/amd64/amd64/spl.S: revision 1.50
sys/arch/x86/x86/fpu.c: revision 1.94
sys/arch/amd64/amd64/amd64_trap.S: revision 1.56
fputrap: enable interrupts before panic(), for consistency.
noticed while working on PR port-xen/58561
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movq CPUVAR(VCPU),%r ## temp_reg ;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/amd64:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI
while there, remove PUSHF/POPF macros which are unused
Hopefully fixes PR port-xen/58561
Thanks to Konrad Schroder for testing and Taylor R Campbell for review.
Port amd64 fix for PR port-xen/58561 to i386, with one extra fix:
with recent Xen (maybe since pvshim), traps handlers are called with
interrupts enabled, so adjust the i386 assembly code for this.
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movl CPUVAR(VCPU),reg
movb $1,EVTCHN_UPCALL_MASK(reg)
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/i386:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI and STIC
- rename PUSHF to PUSHFCLI and change it to both read and disable
EVTCHN_UPCALL_MASK with preemption disabled
- remove the XENPVHVM version of STIC which is unused
To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.55.8.1 src/sys/arch/amd64/amd64/amd64_trap.S
cvs rdiff -u -r1.69.2.1 -r1.69.2.2 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.230.2.1 -r1.230.2.2 src/sys/arch/amd64/amd64/locore.S
cvs rdiff -u -r1.49 -r1.49.8.1 src/sys/arch/amd64/amd64/spl.S
cvs rdiff -u -r1.55 -r1.55.12.1 src/sys/arch/amd64/include/frameasm.h
cvs rdiff -u -r1.24 -r1.24.2.1 src/sys/arch/i386/i386/i386_trap.S
cvs rdiff -u -r1.201.2.1 -r1.201.2.2 src/sys/arch/i386/i386/locore.S
cvs rdiff -u -r1.58 -r1.58.8.1 src/sys/arch/i386/i386/spl.S
cvs rdiff -u -r1.35 -r1.35.12.1 src/sys/arch/i386/include/frameasm.h
cvs rdiff -u -r1.93 -r1.93.2.1 src/sys/arch/x86/x86/fpu.c
cvs rdiff -u -r1.31 -r1.31.8.1 src/sys/arch/xen/x86/xen_intr.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/58561 CVS commit: [netbsd-10] src/sys/arch
Date: Sun, 25 Jan 2026 16:38:54 +0000
Module Name: src
Committed By: martin
Date: Sun Jan 25 16:38:53 UTC 2026
Modified Files:
src/sys/arch/amd64/amd64 [netbsd-10]: amd64_trap.S cpufunc.S locore.S
spl.S
src/sys/arch/amd64/include [netbsd-10]: frameasm.h
src/sys/arch/i386/i386 [netbsd-10]: i386_trap.S locore.S spl.S
src/sys/arch/i386/include [netbsd-10]: frameasm.h
src/sys/arch/x86/x86 [netbsd-10]: fpu.c
src/sys/arch/xen/x86 [netbsd-10]: xen_intr.c
Log Message:
Pull up following revision(s) (requested by bouyer in ticket #1226):
sys/arch/amd64/include/frameasm.h: revision 1.56
sys/arch/xen/x86/xen_intr.c: revision 1.32
sys/arch/i386/include/frameasm.h: revision 1.36
sys/arch/i386/i386/locore.S: revision 1.206
sys/arch/amd64/amd64/cpufunc.S: revision 1.71
sys/arch/i386/i386/i386_trap.S: revision 1.25
sys/arch/i386/i386/spl.S: revision 1.59
sys/arch/amd64/amd64/locore.S: revision 1.236
sys/arch/amd64/amd64/spl.S: revision 1.50
sys/arch/x86/x86/fpu.c: revision 1.94
sys/arch/amd64/amd64/amd64_trap.S: revision 1.56
fputrap: enable interrupts before panic(), for consistency.
noticed while working on PR port-xen/58561
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movq CPUVAR(VCPU),%r ## temp_reg ;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/amd64:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI
while there, remove PUSHF/POPF macros which are unused
Hopefully fixes PR port-xen/58561
Thanks to Konrad Schroder for testing and Taylor R Campbell for review.
Port amd64 fix for PR port-xen/58561 to i386, with one extra fix:
with recent Xen (maybe since pvshim), traps handlers are called with
interrupts enabled, so adjust the i386 assembly code for this.
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movl CPUVAR(VCPU),reg
movb $1,EVTCHN_UPCALL_MASK(reg)
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/i386:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI and STIC
- rename PUSHF to PUSHFCLI and change it to both read and disable
EVTCHN_UPCALL_MASK with preemption disabled
- remove the XENPVHVM version of STIC which is unused
To generate a diff of this commit:
cvs rdiff -u -r1.54.4.1 -r1.54.4.2 src/sys/arch/amd64/amd64/amd64_trap.S
cvs rdiff -u -r1.65.18.2 -r1.65.18.3 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.214.4.4 -r1.214.4.5 src/sys/arch/amd64/amd64/locore.S
cvs rdiff -u -r1.48 -r1.48.4.1 src/sys/arch/amd64/amd64/spl.S
cvs rdiff -u -r1.55 -r1.55.4.1 src/sys/arch/amd64/include/frameasm.h
cvs rdiff -u -r1.23 -r1.23.4.1 src/sys/arch/i386/i386/i386_trap.S
cvs rdiff -u -r1.190.4.3 -r1.190.4.4 src/sys/arch/i386/i386/locore.S
cvs rdiff -u -r1.57 -r1.57.4.1 src/sys/arch/i386/i386/spl.S
cvs rdiff -u -r1.35 -r1.35.4.1 src/sys/arch/i386/include/frameasm.h
cvs rdiff -u -r1.79.4.5 -r1.79.4.6 src/sys/arch/x86/x86/fpu.c
cvs rdiff -u -r1.30.4.1 -r1.30.4.2 src/sys/arch/xen/x86/xen_intr.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/58561 CVS commit: [netbsd-9] src/sys/arch
Date: Sun, 25 Jan 2026 16:41:14 +0000
Module Name: src
Committed By: martin
Date: Sun Jan 25 16:41:14 UTC 2026
Modified Files:
src/sys/arch/amd64/amd64 [netbsd-9]: amd64_trap.S cpufunc.S locore.S
spl.S
src/sys/arch/amd64/include [netbsd-9]: frameasm.h
src/sys/arch/i386/i386 [netbsd-9]: i386_trap.S locore.S spl.S
src/sys/arch/i386/include [netbsd-9]: frameasm.h
src/sys/arch/x86/x86 [netbsd-9]: fpu.c
src/sys/arch/xen/x86 [netbsd-9]: xen_intr.c
Log Message:
Pull up following revision(s) (requested by bouyer in ticket #1998):
sys/arch/amd64/include/frameasm.h: revision 1.56
sys/arch/xen/x86/xen_intr.c: revision 1.32
sys/arch/i386/include/frameasm.h: revision 1.36
sys/arch/i386/i386/locore.S: revision 1.206
sys/arch/amd64/amd64/cpufunc.S: revision 1.71
sys/arch/i386/i386/i386_trap.S: revision 1.25
sys/arch/i386/i386/spl.S: revision 1.59
sys/arch/amd64/amd64/locore.S: revision 1.236
sys/arch/amd64/amd64/spl.S: revision 1.50
sys/arch/x86/x86/fpu.c: revision 1.94
sys/arch/amd64/amd64/amd64_trap.S: revision 1.56
(all via patch)
fputrap: enable interrupts before panic(), for consistency.
noticed while working on PR port-xen/58561
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movq CPUVAR(VCPU),%r ## temp_reg ;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/amd64:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI
while there, remove PUSHF/POPF macros which are unused
Hopefully fixes PR port-xen/58561
Thanks to Konrad Schroder for testing and Taylor R Campbell for review.
Port amd64 fix for PR port-xen/58561 to i386, with one extra fix:
with recent Xen (maybe since pvshim), traps handlers are called with
interrupts enabled, so adjust the i386 assembly code for this.
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movl CPUVAR(VCPU),reg
movb $1,EVTCHN_UPCALL_MASK(reg)
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
than the one we're now running on.
Fix for Xen/i386:
- Add a CLI2 macro, which disables preemtion before the above sequence.
Use it instead of CLI where preemtion may be enabled
- Add DIAGNOSTIC code to check that preemtion is disabled in CLI
- Add DIAGNOSTIC code to check that interrupts are disabled when calling STI and STIC
- rename PUSHF to PUSHFCLI and change it to both read and disable
EVTCHN_UPCALL_MASK with preemption disabled
- remove the XENPVHVM version of STIC which is unused
To generate a diff of this commit:
cvs rdiff -u -r1.48 -r1.48.2.1 src/sys/arch/amd64/amd64/amd64_trap.S
cvs rdiff -u -r1.43.2.1 -r1.43.2.2 src/sys/arch/amd64/amd64/cpufunc.S
cvs rdiff -u -r1.185.2.1 -r1.185.2.2 src/sys/arch/amd64/amd64/locore.S
cvs rdiff -u -r1.40 -r1.40.4.1 src/sys/arch/amd64/amd64/spl.S
cvs rdiff -u -r1.44 -r1.44.2.1 src/sys/arch/amd64/include/frameasm.h
cvs rdiff -u -r1.18 -r1.18.4.1 src/sys/arch/i386/i386/i386_trap.S
cvs rdiff -u -r1.168 -r1.168.2.1 src/sys/arch/i386/i386/locore.S
cvs rdiff -u -r1.47 -r1.47.4.1 src/sys/arch/i386/i386/spl.S
cvs rdiff -u -r1.28 -r1.28.4.1 src/sys/arch/i386/include/frameasm.h
cvs rdiff -u -r1.55.2.2 -r1.55.2.3 src/sys/arch/x86/x86/fpu.c
cvs rdiff -u -r1.17.2.1 -r1.17.2.2 src/sys/arch/xen/x86/xen_intr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Sun, 25 Jan 2026 17:06:09 +0000
State-Changed-Why:
pullups complete on all active branches. Hopefully fixed, finally
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58561 CVS commit: [netbsd-9] src
Date: Sun, 25 Jan 2026 18:11:30 +0000
Module Name: src
Committed By: martin
Date: Sun Jan 25 18:11:30 UTC 2026
Modified Files:
src/doc [netbsd-9]: CHANGES-9.5
src/sys/arch/i386/i386 [netbsd-9]: vector.S
Log Message:
Apply patch, requested by bouyer in ticket #1998:
sys/arch/i386/i386/vector.S (apply patch)
xen: PR 58561: make sure kernel preemption won't cause write of
evtchn_upcall_mask of the wrong virtual CPU.
(file accidently missed in the original commit for ticket #1998)
To generate a diff of this commit:
cvs rdiff -u -r1.1.2.94 -r1.1.2.95 src/doc/CHANGES-9.5
cvs rdiff -u -r1.83 -r1.83.4.1 src/sys/arch/i386/i386/vector.S
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.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home