NetBSD Problem Report #57621
From he@smistad.uninett.no Tue Sep 19 21:38:20 2023
Return-Path: <he@smistad.uninett.no>
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))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id CAA391A9238
for <gnats-bugs@gnats.NetBSD.org>; Tue, 19 Sep 2023 21:38:20 +0000 (UTC)
Message-Id: <20230919213813.58B8A43EEAD@smistad.uninett.no>
Date: Tue, 19 Sep 2023 23:38:13 +0200 (CEST)
From: he@NetBSD.org
Reply-To: he@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: Updated 10.0_BETA macppc MP kernel prone to hangs
X-Send-Pr-Version: 3.95
>Number: 57621
>Category: kern
>Synopsis: Updated 10.0_BETA macppc MP kernel prone to hangs
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Sep 19 21:40:01 +0000 2023
>Last-Modified: Fri Dec 29 20:25:02 +0000 2023
>Originator: he@NetBSD.org
>Release: NetBSD 10.0_BETA
>Organization:
I Try...
>Environment:
System: (it's still wedged, so can't do "uname -a", but it's a
relatively recent macppc 10.0_BETA kernel and user-land)
Architecture: powerpc
Machine: macppc
>Description:
It appears that a reasonably up-to-date 10.0_BETA kernel is
prone to hangs on this particular system. A -current kernel
built from sources dating June 8 2022 appears to be more
stable than a 10.0_BETA kernel from e.g. April 10 2023 or a
more recently updated 10.0_BETA kernel.
The annoying thing is that I can't get DDB to work on this
system.
The symptom is that simply doing a "build.sh -j 2 ... release"
job will with nearly probability 1 trigger a wedge where a few
processes get stuck in "tstile" state, and this disease then
spreads to other activity on the machine which grinds to a
wedge.
However, not *everything* comes to a halt, e.g. a remote xterm
with 'top' running may continue to run. Same for 'systat vm',
and also same with 'crash'.
A fairly typical 'top' output (when it's wedged, cut+pasted
just now, while the host wedged a couple of days ago):
load averages: 0.01, 0.02, 0.00; up 2+11:22:17 23:27:20
83 processes: 81 sleeping, 2 on CPU
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Memory: 911M Act, 560M Inact, 14M Wired, 23M Exec, 1368M File, 249M Free
Swap: 2000M Total, 40K Used, 2000M Free / Pools: 235M Used
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 43 0 0K 83M dbcool/1 11:17 1.90% 1.90% [system]
3361 he 85 0 9996K 1652K ttyraw/0 11:49 0.00% 0.00% systat
1242 he 85 0 17M 6308K select/1 5:14 0.00% 0.00% xterm
1851 he 43 0 10M 2180K CPU/1 2:28 0.00% 0.00% top
1255 he 85 0 24M 6696K poll/0 1:56 0.00% 0.00% sshd
1200 he 85 0 17M 3828K select/1 1:36 0.00% 0.00% xterm
1229 he 85 0 33M 2836K poll/0 1:26 0.00% 0.00% sshd
5367 root 43 0 8024K 2508K CPU/0 0:55 0.00% 0.00% top
1217 he 85 0 17M 7120K select/1 0:20 0.00% 0.00% xterm
1253 he 85 0 23M 1632K poll/1 0:17 0.00% 0.00% sshd
800 root 85 0 15M 14M pause/0 0:10 0.00% 0.00% ntpd
207 root 83 4 9564K 648K poll/0 0:08 0.00% 0.00% nbmake
13699 he 85 0 22M 6132K poll/0 0:06 0.00% 0.00% sshd
24480 root 85 0 6284K 320K kqueue/0 0:06 0.00% 0.00% tail
18249 he 117 0 18M 4912K tstile/0 0:05 0.00% 0.00% xterm
8682 he 85 0 23M 2252K poll/1 0:05 0.00% 0.00% sshd
20207 root 83 4 9404K 2724K poll/0 0:04 0.00% 0.00% nbmake
2217 root 83 4 9404K 2656K poll/0 0:04 0.00% 0.00% nbmake
27442 he 85 0 17M 3260K select/1 0:03 0.00% 0.00% xterm
24118 he 117 0 23M 1748K tstile/1 0:02 0.00% 0.00% sshd
13350 root 85 0 25M 3196K ttyraw/1 0:01 0.00% 0.00% crash
1085 root 117 0 19M 1192K tstile/0 0:00 0.00% 0.00% master
1075 root 117 0 7824K 1068K tstile/0 0:00 0.00% 0.00% cron
1254 postfix 117 0 20M 828K tstile/1 0:00 0.00% 0.00% qmgr
2221 root 108 4 4112K 420K tstile/1 0:00 0.00% 0.00% nbsed
1105 root 108 4 2016K 216K tstile/0 0:00 0.00% 0.00% sh
27957 root 108 4 1608K 176K tstile/0 0:00 0.00% 0.00% nbgrep
9720 root 85 0 22M 9396K poll/1 0:00 0.00% 0.00% sshd
12768 root 85 0 22M 9296K poll/0 0:00 0.00% 0.00% sshd
1218 root 85 0 22M 9188K poll/0 0:00 0.00% 0.00% sshd
1236 root 85 0 22M 8916K poll/1 0:00 0.00% 0.00% sshd
20726 he 85 0 17M 6580K select/1 0:00 0.00% 0.00% xterm
12983 he 85 0 23M 6496K poll/0 0:00 0.00% 0.00% sshd
...
A couple of things can be read out here:
* Several processes are stuck in 'tstile' wait channel (as
described above).
* There does not *appear* to be a drastic physical memory
shortfall, and swap is barely used.
The last point made me think that "this can't be VM related",
but it looks like I was wrong.
I also managed to collect "ps" and, I think, "bt/a" traces of
all the processes stuck in 'tstile' at the time of this run.
The output from those can be seen here:
crash> ps
PID LID S CPU FLAGS STRUCT LWP * NAME WAIT
1105 1105 3 0 0 3347a100 sh tstile
27957 27957 3 0 0 231a5c40 nbgrep tstile
2221 2221 3 1 0 1d2b5380 nbsed tstile
15261 15261 3 0 180 534e3080 sh wait
23256 23256 3 0 180 61dbc3c0 nbmake poll
10572 10572 3 0 180 57015d00 sh wait
17709 17709 3 0 180 34e79a00 nbmake poll
22661 22661 3 0 180 107803c0 nbmake wait
10847 10847 3 1 0 695a10c0 pickup tstile
15598 15598 3 1 180 5c5666c0 sh wait
28627 28627 3 0 180 23276d00 nbmake poll
25303 25303 3 1 180 5c5660c0 sh wait
29847 29847 3 0 180 61dbc6c0 nbmake poll
5367 5367 3 0 180 34e79d00 top select
320 320 3 1 180 1d2b5c80 tcsh pause
2526 2526 3 0 180 15287d00 tcsh pause
13699 13699 3 1 180 15287700 sshd poll
9720 9720 3 1 180 1389ec80 sshd poll
21947 21947 3 1 180 1d7420c0 crash ttyraw
28553 28553 3 0 180 10778040 tcsh pause
12880 12880 3 1 180 21080c40 tcsh pause
1679 1679 3 0 180 5c5663c0 sshd poll
1191 1191 3 1 180 21125080 sshd poll
19615 19615 3 1 180 3343c040 sh wait
2217 2217 3 0 180 3347a400 nbmake poll
1584 1584 3 1 180 3347aa00 sh wait
20207 20207 3 0 180 10780cc0 nbmake poll
11398 11398 3 0 180 61dbccc0 sh wait
207 207 3 0 180 534e3380 nbmake poll
13301 13301 3 0 180 3347ad00 sh wait
24480 24480 3 0 180 205d9940 tail kqueue
23505 23505 3 0 180 22168cc0 tcsh pause
21730 21730 3 1 180 1d7426c0 tcsh ttyraw
20726 20726 3 1 180 5c5669c0 xterm select
7409 7409 3 0 180 34e79100 tcsh pause
12983 12983 3 0 180 23276100 sshd poll
24443 24443 3 1 180 534e3680 sshd poll
13350>13350 7 0 100 57015400 crash
17585 17585 3 0 180 3343c940 tcsh ttyraw
14989 14989 3 0 180 21080340 tcsh pause
27442 27442 3 0 1c0 61dbc0c0 xterm select
27802 27802 3 0 180 1d2b5080 tcsh pause
24118 24118 3 0 180 215b50c0 sshd poll
12768 12768 3 0 180 1d742cc0 sshd poll
8163 8163 3 0 180 231a5340 tcsh pause
10465 10465 3 0 180 21125c80 tcsh pause
18249 18249 3 1 1c0 21080040 xterm poll
10566 10566 3 0 180 21125380 tcsh pause
8682 8682 3 1 180 215b5cc0 sshd poll
10625 10625 3 1 180 34e79400 sshd poll
3361 3361 3 0 180 1d2b5980 systat ttyraw
1851 1851 3 0 180 3343cc40 top select
1103 1103 3 1 180 10778c40 tcsh pause
1378 1378 3 0 180 221689c0 tcsh pause
1200 1200 3 1 180 10338700 xterm select
1277 1277 3 0 180 10778940 tcsh pause
1319 1319 3 0 180 10338d00 tcsh pause
1229 1229 3 1 180 10778640 sshd poll
1241 1241 3 0 180 102ae9c0 tcsh pause
1243 1243 3 1 180 1389e980 sshd poll
1242 1242 3 0 180 107800c0 xterm select
1232 1232 3 0 180 10338a00 tcsh pause
1255 1255 3 0 180 21c79c80 sshd poll
1236 1236 3 1 180 221683c0 sshd poll
1217 1217 3 0 180 1389e380 xterm select
1223 1223 3 0 180 221686c0 tcsh pause
1253 1253 3 0 180 1389e080 sshd poll
1218 1218 3 0 180 221680c0 sshd poll
1084 1084 3 0 180 21c79980 getty ttyraw
1112 1112 3 0 180 21c79680 getty nanoslp
1066 1066 3 0 180 21c79380 getty nanoslp
1275 1275 3 0 180 21c79080 getty nanoslp
1086 1086 3 1 180 1022f100 getty ttyraw
1075 1075 3 0 40 205d9c40 cron tstile
1070 1070 3 1 180 205d9640 inetd kqueue
1254 1254 3 0 180 205d9340 qmgr kqueue
1085 1085 3 0 1000040 10778340 master tstile
825 825 3 0 180 15287100 sshd poll
708 708 3 0 180 107809c0 powerd kqueue
800 800 3 0 180 107806c0 ntpd pause
604 604 3 0 180 1389e680 syslogd kqueue
1 1 3 0 180 102ae0c0 init wait
0 198 3 1 200 102aecc0 physiod physiod
0 166 3 1 200 1022f700 pooldrain pooldrain
0 165 3 0 200 10338400 ioflush syncer
0 164 3 0 200 10338100 pgdaemon pgdaemon
0 126 3 1 200 7f87cc80 swwreboot swwreboot
0 124 3 1 200 102ae6c0 atapibus0 sccomp
0 122 3 0 200 102196c0 usb0 usbevt
0 121 3 0 200 102ae3c0 usb1 usbevt
0 120 3 0 200 1022f400 npfgc0 npfgcw
0 119 3 1 200 1028cc80 rt_free rt_free
0 118 3 1 200 1028c980 unpgc unpgc
0 117 3 0 200 1028c680 key_timehandler key_timehandler
0 116 3 1 200 1028c380 icmp6_wqinput/1 icmp6_wqinput
0 115 3 0 200 1028c080 icmp6_wqinput/0 icmp6_wqinput
0 114 3 0 200 1027ec40 nd6_timer nd6_timer
0 113 3 1 200 1027e940 carp6_wqinput/1 carp6_wqinput
0 112 3 0 200 1027e640 carp6_wqinput/0 carp6_wqinput
0 111 3 1 200 1027e340 carp_wqinput/1 carp_wqinput
0 110 3 0 200 1027e040 carp_wqinput/0 carp_wqinput
0 109 3 1 200 1022fd00 icmp_wqinput/1 icmp_wqinput
0 108 3 0 200 102199c0 icmp_wqinput/0 icmp_wqinput
0 107 3 0 200 1022fa00 rt_timer rt_timer
0 106 3 0 200 10219cc0 vmem_rehash vmem_rehash
0 97 3 1 200 102193c0 lmtemp0 lmtemp0
0 96 3 0 200 102190c0 dbcool0 dbcool0
0 30 3 0 200 7f87c980 entbutler entropy
0 29 3 1 380 7f87c680 fw0probe ieee1394
0 28 3 0 240 7f87c380 atabus2 atath
0 27 3 1 200 7f87c080 usbtask-dr usbtsk
0 26 3 0 200 7f901c40 usbtask-hc usbtsk
0 25 3 1 240 7f901940 atabus1 atath
0 24 3 1 200 7f901640 atabus0 atath
0 23 3 0 200 7f901340 pmu wait
0 22 3 1 200 7f901040 xcall/1 xcall
0 21 1 1 200 7f90ed00 softser/1
0 20 1 1 40200 7f90ea00 softclk/1
0 19 1 1 200 7f90e700 softbio/1
0 18 1 1 200 7f90e400 softnet/1
0 17 1 1 201 7f90e100 idle/1
0 16 3 0 200 7f91acc0 sysmon smtaskq
0 15 3 0 200 7f91a9c0 pmfsuspend pmfsuspend
0 14 3 0 200 7f91a6c0 pmfevent pmfevent
0 13 3 0 200 7f91a3c0 sopendfree sopendfr
0 12 3 0 200 7f91a0c0 ifwdog ifwdog
0 11 3 0 200 7fb26c80 iflnkst iflnkst
0 10 3 0 200 7fb26980 nfssilly nfssilly
0 9 3 1 240 7fb26680 vdrain vdrain
0 8 3 0 200 7fb26380 modunload mod_unld
0 7 3 0 200 7fb26080 xcall/0 xcall
0 6 1 0 200 7fb30c40 softser/0
0 5 1 0 40200 7fb30940 softclk/0
0 4 1 0 200 7fb30640 softbio/0
0 3 1 0 40200 7fb30340 softnet/0
0 > 2 1 0 201 7fb30040 idle/0
0 0 3 1 200 c32dc0 swapper uvm
crash>
crash> bt/a 1027ec40
trace: pid 0 lid 114 at 0x10267de0
0x10267e40: at cpu_switchto+0x28
0x10267e50: at mi_switch+0x140
0x10267e90: at sleepq_block+0xe0
0x10267eb0: at cv_wait+0xc0
0x10267ee0: at workqueue_worker+0x12c
0x10267f20: at cpu_lwp_bootstrap+0xc
0x10267fe8: kernel trap 0 by __end+0xf5fabf8: srr1=0x111f8340
r1=0x2 cr=0x5 xer=0x40000 ctr=0xfffffff0
crash> bt/a 1d2b5380
trace: pid 2221 lid 2221 at 0x4da13bc0
0x4da13c20: at cpu_switchto+0x28
0x4da13c30: at mi_switch+0x140
0x4da13c70: at sleepq_block+0xe0
0x4da13c90: at turnstile_block+0x284
0x4da13cf0: at rw_enter+0x124
0x4da13d30: at uvm_fault_internal+0xa3c
0x4da13e70: at trap+0x674
0x4da13f20: user 0xfded1660: srr1=0xd032
r1=0xffffe1e0 cr=0x84002008 xer=0x20000000 ctr=0xfded1650
crash> bt/a 231a5c40
trace: pid 27957 lid 27957 at 0x21583bc0
0x21583c20: at cpu_switchto+0x28
0x21583c30: at mi_switch+0x140
0x21583c70: at sleepq_block+0xe0
0x21583c90: at turnstile_block+0x284
0x21583cf0: at rw_enter+0x124
0x21583d30: at uvm_fault_internal+0xa3c
0x21583e70: at trap+0x674
0x21583f20: user 0xfded3d80: srr1=0xd032
r1=0xffffda10 cr=0x84008004 xer=0x20000000 ctr=0
crash> bt/a 695a10c0
trace: pid 10847 lid 10847 at 0x5523ec10
0x5523ec70: at cpu_switchto+0x28
0x5523ec80: at mi_switch+0x140
0x5523ecc0: at sleepq_block+0xe0
0x5523ece0: at turnstile_block+0x284
0x5523ed40: at rw_enter+0x124
0x5523ed80: at uvm_unmap_remove+0x158
0x5523edc0: at uvmspace_free+0xe0
0x5523ede0: at exit1+0x1a8
0x5523eea0: at sys_exit+0x44
0x5523eec0: at syscall+0x294
0x5523ef20: user SC trap #1 by 0xfd201548: srr1=0xd032
r1=0xffffe590 cr=0x24442442 xer=0x20000000 ctr=0xfd201540
crash>
crash> bt/a 10778340
trace: pid 1085 lid 1085 at 0x107abbc0
0x107abc20: at cpu_switchto+0x28
0x107abc30: at mi_switch+0x140
0x107abc70: at sleepq_block+0xe0
0x107abc90: at turnstile_block+0x284
0x107abcf0: at rw_enter+0x124
0x107abd30: at uvm_fault_internal+0xa3c
0x107abe70: at trap+0x674
0x107abf20: user 0x18153e0: srr1=0xd032
r1=0xffffd9b0 cr=0x28022444 xer=0 ctr=0xfd2016b8
crash>
crash> bt/a 205d9c40
trace: pid 1075 lid 1075 at 0x17513ca0
0x17513d00: at cpu_switchto+0x28
0x17513d10: at mi_switch+0x140
0x17513d50: at sleepq_block+0xe0
0x17513d70: at turnstile_block+0x284
0x17513dd0: at rw_enter+0x124
0x17513e10: at uvmspace_fork+0x35c
0x17513e40: at uvm_proc_fork+0x34
0x17513e50: at fork1+0x334
0x17513ec0: at syscall+0x294
0x17513f20: user SC trap #2 by 0xfdede44c: srr1=0xd032
r1=0xffffe8c0 cr=0x22000422 xer=0x20000000 ctr=0xfded7ba4
crash>
crash> bt/a 3347a100
trace: pid 1105 lid 1105 at 0x1eb23bc0
0x1eb23c20: at cpu_switchto+0x28
0x1eb23c30: at mi_switch+0x140
0x1eb23c70: at sleepq_block+0xe0
0x1eb23c90: at turnstile_block+0x284
0x1eb23cf0: at rw_enter+0x124
0x1eb23d30: at uvm_fault_internal+0xa3c
0x1eb23e70: at trap+0x674
0x1eb23f20: user 0xfded3d80: srr1=0xd032
r1=0xffffda30 cr=0x84008004 xer=0x20000000 ctr=0
crash>
This, somewhat unexpectedly, points to "something" in the UVM
subsystem which might be amiss(?), but figuring out what is
above my pay grade.
Guidance for next steps in narrowing down the actual root
cause gratefully accepted.
>How-To-Repeat:
Update a dual-CPU macppc G4 system to recent 10.0_BETA code,
and do a "build.sh -j 2 ... release" run. The probability of
it getting stuck sometime along the build is nearly 1.
>Fix:
Sorry, don't know.
>Audit-Trail:
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, Havard Eidnes <he@netbsd.org>
Cc:
Subject: Re: kern/57621: Updated 10.0_BETA macppc MP kernel prone to hangs
Date: Wed, 20 Sep 2023 16:37:00 +0900
Recently, I frequently observe similar stalls on Mac mini G4 (UP).
I can work around the problem by this patch:
https://gist.github.com/rokuyama/53898de1e9ff67b86ac8e53f552dc582
With this patch, general pool allocator is used for struct pmap,
instead of pmap_pool_allocator(), which is intended for PVO
entries below 256MB.
Thanks,
rin
From: Havard Eidnes <he@uninett.no>
To: rokuyama.rk@gmail.com
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57621: Updated 10.0_BETA macppc MP kernel prone to hangs
Date: Wed, 20 Sep 2023 13:14:52 +0200 (CEST)
> Recently, I frequently observe similar stalls on Mac mini G4 (UP).
>
> I can work around the problem by this patch:
Excellent!
I will apply this to my local tree and check the fix from this
coming evening my time.
Regards,
- H=E5vard
From: Havard Eidnes <he@uninett.no>
To: rokuyama.rk@gmail.com
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57621: Updated 10.0_BETA macppc MP kernel prone to hangs
Date: Thu, 21 Sep 2023 08:26:52 +0200 (CEST)
>> Recently, I frequently observe similar stalls on Mac mini G4 (UP).
>>
>> I can work around the problem by this patch:
>
> Excellent!
> I will apply this to my local tree and check the fix from this
> coming evening my time.
Unfortunately, that did not result in a complete success, and the
build got stuck overnight, at
compile libcrypto/x25519_ref10.o
build libcrypto/librumpkern_crypto.so.0.0
build libcrypto/librumpkern_crypto.a
I now have an 'ld' stuck in 'tstile' (probably building the
.so.0.0), together with 'vdrain'. Output from 'crash':
crash> ps
PID LID S CPU FLAGS STRUCT LWP * NAME WAIT
12110 12110 3 1 180 1a41ea00 pickup kqueue
4483 4483 3 0 0 102ee400 ld tstile
26251 26251 3 1 180 15d106c0 collect2 wait
23329 23329 3 1 180 13cff100 powerpc--netbsd- wait
24864 24864 3 0 180 181c3400 sh wait
21433 21433 3 0 180 1a41e100 nbmake poll
14503 14503 3 0 180 19661a00 sh wait
4702 4702 3 0 180 181c3a00 nbmake poll
5602 5602 3 0 180 19661700 sh wait
25075 25075 3 1 180 19661100 nbmake poll
9198 9198 3 0 180 22089340 nbmake wait
8760 8760 3 1 180 13cffd00 sh wait
22443 22443 3 0 180 21f5e3c0 nbmake poll
27361 27361 3 0 180 1ae133c0 sh wait
6730 6730 3 0 180 1e36a640 nbmake poll
1460 1460 3 0 180 1073f340 systat ttyraw
897 > 897 7 0 100 1a41ed00 crash
10856 10856 3 1 180 19996640 tcsh pause
9905 9905 3 1 180 181c3d00 tcsh pause
10297>10297 7 1 100 19661d00 sshd
9285 9285 3 1 180 19996040 sshd poll
6102 6102 3 1 180 1a95f0c0 top select
1826 1826 3 1 180 1e36ac40 sh wait
2345 2345 3 0 180 1df8dc80 nbmake poll
2611 2611 3 1 180 1df8d080 sh wait
2335 2335 3 0 180 1df8d980 nbmake poll
2399 2399 3 1 180 1e36a940 sh wait
2683 2683 3 1 180 1df8d680 nbmake poll
1074 1074 3 0 180 12175d00 sh wait
1072 1072 3 1 180 181c3100 tail kqueue
361 361 3 1 180 10d63cc0 tcsh pause
1108 1108 3 1 180 12175700 tcsh pause
1092 1092 3 1 180 1073f940 tcsh pause
1089 1089 3 0 180 10d87680 tcsh pause
1151 1151 3 0 180 15d10cc0 tcsh pause
850 850 3 0 180 12175400 xterm select
959 959 3 1 180 1073f040 tcsh pause
962 962 3 0 180 15d109c0 sshd poll
952 952 3 0 180 12175100 xterm select
942 942 3 0 180 102eea00 xterm select
949 949 3 0 180 10d639c0 sshd poll
1251 1251 3 0 180 102ee700 tcsh pause
943 943 3 1 180 10d87c80 sshd poll
704 704 3 1 180 1073fc40 sshd poll
928 928 3 0 180 10d87980 tcsh pause
1122 1122 3 0 180 102eed00 sshd poll
983 983 3 1 180 15d103c0 getty ttyraw
981 981 3 1 180 15d100c0 getty nanoslp
813 813 3 0 180 13cd7c80 getty nanoslp
986 986 3 1 180 13cd7980 getty nanoslp
985 985 3 0 180 13cd7680 getty ttyraw
998 998 3 1 180 12b77640 cron nanoslp
974 974 3 1 180 12b77c40 sshd poll
971 971 3 0 180 10d630c0 inetd kqueue
957 957 3 1 180 10d87380 qmgr kqueue
828 828 3 0 180 12175a00 master kqueue
723 723 3 1 180 10d636c0 sshd poll
604 604 3 0 180 12b77940 powerd kqueue
567 567 3 0 180 12b77340 ntpd pause
318 318 3 0 180 10d87080 syslogd kqueue
1 1 3 0 180 102af0c0 init wait
0 198 3 1 200 1022f100 physiod physiod
0 166 3 1 200 102ee100 pooldrain pooldrain
0 165 3 1 200 102afcc0 ioflush syncer
0 164 3 0 200 102af9c0 pgdaemon pgdaemon
0 126 3 0 200 7f87cc80 swwreboot swwreboot
0 124 3 1 200 102af6c0 atapibus0 sccomp
0 122 3 0 200 102196c0 usb0 usbevt
0 121 3 0 200 102af3c0 usb1 usbevt
0 120 3 0 200 1022f400 npfgc0 npfgcw
0 119 3 1 200 1028cc80 rt_free rt_free
0 118 3 1 200 1028c980 unpgc unpgc
0 117 3 0 200 1028c680 key_timehandler key_timehandler
0 116 3 1 200 1028c380 icmp6_wqinput/1 icmp6_wqinput
0 115 3 0 200 1028c080 icmp6_wqinput/0 icmp6_wqinput
0 114 3 1 200 1027ec40 nd6_timer nd6_timer
0 113 3 1 200 1027e940 carp6_wqinput/1 carp6_wqinput
0 112 3 0 200 1027e640 carp6_wqinput/0 carp6_wqinput
0 111 3 1 200 1027e340 carp_wqinput/1 carp_wqinput
0 110 3 0 200 1027e040 carp_wqinput/0 carp_wqinput
0 109 3 1 200 1022fd00 icmp_wqinput/1 icmp_wqinput
0 108 3 0 200 102199c0 icmp_wqinput/0 icmp_wqinput
0 107 3 0 200 1022fa00 rt_timer rt_timer
0 106 3 0 200 10219cc0 vmem_rehash vmem_rehash
0 97 3 0 200 102193c0 lmtemp0 lmtemp0
0 96 3 1 200 102190c0 dbcool0 dbcool0
0 30 3 0 200 7f87c980 entbutler entropy
0 29 3 1 380 7f87c680 fw0probe ieee1394
0 28 3 1 240 7f87c380 atabus2 atath
0 27 3 0 200 7f87c080 usbtask-dr usbtsk
0 26 3 0 200 7f901c40 usbtask-hc usbtsk
0 25 3 1 240 7f901940 atabus1 atath
0 24 3 1 200 7f901640 atabus0 atath
0 23 3 0 200 7f901340 pmu wait
0 22 3 1 200 7f901040 xcall/1 xcall
0 21 1 1 200 7f90ed00 softser/1
0 20 1 1 40200 7f90ea00 softclk/1
0 19 1 1 200 7f90e700 softbio/1
0 18 1 1 200 7f90e400 softnet/1
0 17 1 1 201 7f90e100 idle/1
0 16 3 0 200 7f91acc0 sysmon smtaskq
0 15 3 0 200 7f91a9c0 pmfsuspend pmfsuspend
0 14 3 0 200 7f91a6c0 pmfevent pmfevent
0 13 3 0 200 7f91a3c0 sopendfree sopendfr
0 12 3 0 200 7f91a0c0 ifwdog ifwdog
0 11 3 0 200 7fb26c80 iflnkst iflnkst
0 10 3 0 200 7fb26980 nfssilly nfssilly
0 9 3 1 240 7fb26680 vdrain tstile
0 8 3 1 200 7fb26380 modunload mod_unld
0 7 3 0 200 7fb26080 xcall/0 xcall
0 6 1 0 200 7fb30c40 softser/0
0 5 1 0 40200 7fb30940 softclk/0
0 4 1 0 200 7fb30640 softbio/0
0 3 1 0 40200 7fb30340 softnet/0
0 2 1 0 201 7fb30040 idle/0
0 0 3 0 200 c32dc0 swapper uvm
crash> bt/a 102ee400
trace: pid 4483 lid 4483 at 0x1b623930
0x1b623990: at cpu_switchto+0x28
0x1b6239a0: at mi_switch+0x140
0x1b6239e0: at sleepq_block+0xe0
0x1b623a00: at turnstile_block+0x284
0x1b623a60: at rw_enter+0x124
0x1b623aa0: at cache_lookup+0xe8
0x1b623ad0: at ufs_lookup+0xd4
0x1b623b80: at VOP_LOOKUP+0x4c
0x1b623ba0: at lookup_once+0x1fc
0x1b623bf0: at namei_tryemulroot.constprop.0+0x4a8
0x1b623cc0: at namei+0x58
0x1b623cf0: at vn_open+0xfc
0x1b623e10: at do_open+0xf0
0x1b623e60: at do_sys_openat+0x9c
0x1b623ea0: at sys_open+0x2c
0x1b623ec0: at syscall+0x294
0x1b623f20: user SC trap #5 by 0xfdc70e18: srr1=0xd032
r1=0xffffda20 cr=0x84000444 xer=0x20000000 ctr=0xfdc70e10
crash>
crash> bt/a 7fb26680
trace: pid 0 lid 9 at 0x1001fc60
0x1001fcc0: at cpu_switchto+0x28
0x1001fcd0: at mi_switch+0x140
0x1001fd10: at sleepq_block+0xe0
0x1001fd30: at turnstile_block+0x284
0x1001fd90: at rw_enter+0x124
0x1001fdd0: at cache_purge1+0x198
0x1001fe00: at vcache_reclaim+0xc8
0x1001fe80: at vrecycle.part.0+0xc0
0x1001feb0: at vdrain_thread+0x384
0x1001ff20: at cpu_lwp_bootstrap+0xc
saved LR(0x55aa55a6) is invalid.
crash>
Some of the threads which are not waiting:
crash> bt/a 7f90ed00
trace: pid 0 lid 21 at 0x1004fe40
0x1004fea0: at cpu_switchto+0x28
0x1004feb0: at mi_switch+0x140
0x1004fef0: at softint_thread+0x190
0x1004ff20: at cpu_lwp_bootstrap+0xc
saved LR(0xaa55aa51) is invalid.
crash> bt/a 7f90ea00
trace: pid 0 lid 20 at 0x1004be40
0x1004bea0: at cpu_switchto+0x28
0x1004beb0: at mi_switch+0x140
0x1004bef0: at softint_thread+0x190
0x1004bf20: at cpu_lwp_bootstrap+0xc
saved LR(0xaa55aa51) is invalid.
crash> bt/a 7f90e700
trace: pid 0 lid 19 at 0x10047e40
0x10047ea0: at cpu_switchto+0x28
0x10047eb0: at mi_switch+0x140
0x10047ef0: at softint_thread+0x190
0x10047f20: at cpu_lwp_bootstrap+0xc
saved LR(0xaa55aa51) is invalid.
crash> bt/a 7f90e400
trace: pid 0 lid 18 at 0x10043e40
0x10043ea0: at cpu_switchto+0x28
0x10043eb0: at mi_switch+0x140
0x10043ef0: at softint_thread+0x190
0x10043f20: at cpu_lwp_bootstrap+0xc
saved LR(0xaa55aa51) is invalid.
crash> bt/a 7f90e100
trace: pid 0 lid 17 at 0x1003fdc0
0x1003fe20: at cpu_switchto+0x28
0x1003fe30: at mi_switch+0x140
0x1003fe70: at idle_loop+0x10c
0x1003feb0: at cpu_spinup_trampoline+0x3c
saved LR(0x902e) is invalid.
crash> bt/a 7fb30c40
trace: pid 0 lid 6 at 0x10013e40
0x10013ea0: at cpu_switchto+0x28
0x10013eb0: at mi_switch+0x140
0x10013ef0: at softint_thread+0x190
0x10013f20: at cpu_lwp_bootstrap+0xc
saved LR(0x55aa55a6) is invalid.
crash> bt/a 7fb30940
trace: pid 0 lid 5 at 0x1000fe40
0x1000fea0: at cpu_switchto+0x28
0x1000feb0: at mi_switch+0x140
0x1000fef0: at softint_thread+0x190
0x1000ff20: at cpu_lwp_bootstrap+0xc
saved LR(0x55aa55a6) is invalid.
crash> bt/a 7fb30640
trace: pid 0 lid 4 at 0x1000be40
0x1000bea0: at cpu_switchto+0x28
0x1000beb0: at mi_switch+0x140
0x1000bef0: at softint_thread+0x190
0x1000bf20: at cpu_lwp_bootstrap+0xc
saved LR(0x55aa55a6) is invalid.
crash> bt/a 7fb30340
trace: pid 0 lid 3 at 0x10007e40
0x10007ea0: at cpu_switchto+0x28
0x10007eb0: at mi_switch+0x140
0x10007ef0: at softint_thread+0x190
0x10007f20: at cpu_lwp_bootstrap+0xc
saved LR(0x55aa55a6) is invalid.
crash> bt/a 7fb30040
trace: pid 0 lid 2 at 0x10003e30
0x10003e90: at cpu_switchto+0x28
0x10003ea0: at mi_switch+0x140
0x10003ee0: at idle_loop+0x10c
0x10003f20: at cpu_lwp_bootstrap+0xc
saved LR(0x55aa55a6) is invalid.
crash>
but as near as I can tell these do not provide a 'smoking gun'.
'top' says:
load averages: 0.05, 0.01, 0.00; up 0+09:04:53 08:23:16
62 processes: 61 sleeping, 1 on CPU
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Memory: 1124M Act, 560M Inact, 14M Wired, 23M Exec, 1600M File, 24M Free
Swap: 2000M Total, 2000M Free / Pools: 241M Used
and is still running.
Regards,
Havard
From: Havard Eidnes <he@uninett.no>
To: Rokuyama.Rk@gmail.com
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57621: Updated 10.0_BETA macppc MP kernel prone to hangs
Date: Sun, 24 Sep 2023 19:04:09 +0200 (CEST)
>> Recently, I frequently observe similar stalls on Mac mini G4 (UP).
>>
>> I can work around the problem by this patch:
>
> Excellent!
> I will apply this to my local tree and check the fix from this
> coming evening my time.
As noted already, your patch has been applied, and at least the
system no longer wedges as it did before.
The two-lwp deadlock I observed after booting the kernel with the
patch appears to be unrelated to the original issue I reported, and
appears to be a VFS cache issue, yet to be diagnosed.
I'm now running a "LOCKDEBUG.MP" kernel on this machine, and it has
now managed to complete a full "build.sh -x ... release" without
locking up, something which I could not do before, and the VFS issue
has not re-surfaced either.
I would therefore say that the patch should be committed if it has
not already, and also pulled up to netbsd-10.
Best regards,
- H=E5vard
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc/oea
Date: Mon, 9 Oct 2023 13:01:58 +0000
Module Name: src
Committed By: rin
Date: Mon Oct 9 13:01:58 UTC 2023
Modified Files:
src/sys/arch/powerpc/oea: pmap.c
Log Message:
powerpc/oea: pmap: Use pool_allocator_nointr() for pmap_pool
As done for (majority of) other pmap implementations.
pmap_pool_allocator() allocates memory below 256MB, but it is not
necessary for struct pmap.
Fix part of PR kern/57621, i.e., stall in pmap_create(9).
There should be another bugs that cause (MP?) kernel hangs
reported in the PR, in pmap or other MD components for powerpc
(PR port-powerpc/56922 should be one of the candidates).
XXX
pmap for powerpc/oea apparently needs some clean ups. But leave it
as is, and pull up this minimum fix to netbsd-10 at the moment.
To generate a diff of this commit:
cvs rdiff -u -r1.114 -r1.115 src/sys/arch/powerpc/oea/pmap.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/57621 CVS commit: [netbsd-10] src/sys/arch/powerpc/oea
Date: Mon, 9 Oct 2023 13:36:59 +0000
Module Name: src
Committed By: martin
Date: Mon Oct 9 13:36:59 UTC 2023
Modified Files:
src/sys/arch/powerpc/oea [netbsd-10]: pmap.c
Log Message:
Pull up following revision(s) (requested by rin in ticket #400):
sys/arch/powerpc/oea/pmap.c: revision 1.115
powerpc/oea: pmap: Use pool_allocator_nointr() for pmap_pool
As done for (majority of) other pmap implementations.
pmap_pool_allocator() allocates memory below 256MB, but it is not
necessary for struct pmap.
Fix part of PR kern/57621, i.e., stall in pmap_create(9).
There should be another bugs that cause (MP?) kernel hangs
reported in the PR, in pmap or other MD components for powerpc
(PR port-powerpc/56922 should be one of the candidates).
XXX
pmap for powerpc/oea apparently needs some clean ups. But leave it
as is, and pull up this minimum fix to netbsd-10 at the moment.
To generate a diff of this commit:
cvs rdiff -u -r1.114 -r1.114.4.1 src/sys/arch/powerpc/oea/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Havard Eidnes <he@uninett.no>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57621: Updated 10.0_BETA macppc MP kernel prone to hangs
Date: Tue, 10 Oct 2023 13:42:51 +0900
Hi,
I'm so sorry for the serious delay in my response; I'd been
occupied by another tasks.
On Mon, Sep 25, 2023 at 2:04=E2=80=AFAM Havard Eidnes <he@uninett.no> wrote=
:
> As noted already, your patch has been applied, and at least the
> system no longer wedges as it did before.
>
> The two-lwp deadlock I observed after booting the kernel with the
> patch appears to be unrelated to the original issue I reported, and
> appears to be a VFS cache issue, yet to be diagnosed.
>
> I'm now running a "LOCKDEBUG.MP" kernel on this machine, and it has
> now managed to complete a full "build.sh -x ... release" without
> locking up, something which I could not do before, and the VFS issue
> has not re-surfaced either.
Thanks for your feedback. Yeah, LOCKDEBUG should be a nice approach.
> I would therefore say that the patch should be committed if it has
> not already, and also pulled up to netbsd-10.
I committed the patch and it already got pulled up into netbsd-10.
I guess that another symptoms are due to MD parts for powerpc. The
most suspicious is pmap for powerpc/oea. It really needs clean ups.
The second place is PR port-powerpc/56922.
But in either way, unfortunately, it exceeds capacity for us at the
very moment. I will examine further after 10.0RC1 is out.
Thanks,
rin
From: Jason Thorpe <thorpej@me.com>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: Havard Eidnes <he@uninett.no>, gnats-bugs@netbsd.org,
kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57621: Updated 10.0_BETA macppc MP kernel prone to hangs
Date: Mon, 9 Oct 2023 23:05:11 -0700
Hugely so. Honestly a rewrite might be in order.
-- thorpej
Sent from my iPhone.
> On Oct 9, 2023, at 9:43=E2=80=AFPM, Rin Okuyama <rokuyama.rk@gmail.com> wr=
ote:
>=20
> I guess that another symptoms are due to MD parts for powerpc. The
> most suspicious is pmap for powerpc/oea. It really needs clean ups.
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@NetBSD.org, he@NetBSD.org
Cc: netbsd-bugs@NetBSD.org, Martin Husemann <martin@duskware.de>,
macallan1888@gmail.com
Subject: Re: kern/57621 (Updated 10.0_BETA macppc MP kernel prone to hangs)
Date: Fri, 15 Dec 2023 18:26:11 +0900
It turned out that my "fix" for pmap.c, v.1.115 breaks G5
(OEA64_BRIDGE). struct pmap should be in the direct-mapped
memory, and only the 0th 256MiB segment is direct-mapped
for OEA64_BRIDGE; they do not have BATs and therefore
direct-mapping requires PTEs (i.e., relatively expensive).
However:
(1) 256MiB limit should be too restrictive, which may
results in the stall reported by this PR. See rough
estimation below (*).
Also:
(2) OEA and OEA64_BRIDGE has only 512MiB of kernel
virtual space (13rd and 14th SRs).
For OEA, up to 3GiB memory (0th to 11th SRs, 12th SR is
reserved for copy{in,out}) is directly-mapped, and therefore
allocation from this region does not consume kernel address
space. However, for OEA64_BRIDGE, we need to map everything
within this 512MiB region.
Therefore, I will, at least temporarily for 10.0, directly
map up to 3GiB of physical memory also for OEA64_BRIDGE.
This consumes PTEs, but it should be much better than
(1) stall in pmap_create, or (2) kernel va starvation.
With series of commits, my Mac Mini G4 and Power Mac G5
(late 2005, DP) successfully build some memory-consuming
packages, including lang/rust and lang/clang, with
MAKE_JOBS=2 and 4, respectively.
I will send pullup request to netbsd-10 asap, after next
successful snapshot build for -current.
As a long-term challenge, it must be definitely better to
drastically rewrite low level routines for powerpc,
especially pmap.
(*)
As vendors recommend,
(# of PTEG) = (# of physical pages) / 2,
round-up'ed to power of 2.
Consider the case of 2GiB of physical memory, we have 2^18 PTEG.
As each PTEG has 8 PTEs, we have 2^21 = 2Mi PTEs, which can map
8GiB of memory.
In order to manage 2Mi PTEs, we need
sizeof(struct pvo_entry) * 2Mi = 80MiB
for OEA64_BRIDGE (**). We also have page table itself (16MiB),
kernel image, struct pmap, etc., in the 1:1 mapped segment.
(**)
After pmap_pvo_pool fix, will be committed soon.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc/powerpc
Date: Fri, 15 Dec 2023 09:31:03 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:31:03 UTC 2023
Modified Files:
src/sys/arch/powerpc/powerpc: trap.c
Log Message:
powerpc/oea: trap: pmap_{pte,ste}_spill() even in the interrupt context
Page table for oea is something like L2 TLB on memory; kernel and
processes share its entries, and process entries can be spilled out.
As done for MMU based on software-managed TLB, we need to restore
such entries even in the interrupt context.
Note that pmap_pte_spill() require no resouce to restore entries.
Still-not-implemented pmap_ste_spill() for OEA64 should also.
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.164 -r1.165 src/sys/arch/powerpc/powerpc/trap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc/oea
Date: Fri, 15 Dec 2023 09:32:05 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:32:05 UTC 2023
Modified Files:
src/sys/arch/powerpc/oea: pmap.c
Log Message:
powerpc/oea: pmap: Drop unused argument for pmap_pvo_reclaim(), NFC
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.116 -r1.117 src/sys/arch/powerpc/oea/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc/oea
Date: Fri, 15 Dec 2023 09:33:30 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:33:30 UTC 2023
Modified Files:
src/sys/arch/powerpc/oea: pmap.c
Log Message:
powerpc/oea: pmap: Rework pmap_pte_spill()
It was broken in many ways... Now, it gets working stable both for
OEA and OEA64_BRIDGE, as far as I can see.
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.117 -r1.118 src/sys/arch/powerpc/oea/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc/oea
Date: Fri, 15 Dec 2023 09:35:30 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:35:29 UTC 2023
Modified Files:
src/sys/arch/powerpc/oea: pmap.c
Log Message:
powerpc/oea: pmap: Fix mostly-pointless overhead of pmap_pvo_pool
(1) Drop __aligned(32) from struct pvo_entry; otherwise,
sizeof(struct pvo_entry) is round-up'ed to a multiple of 32.
(2) Do not set sizeof(struct pvo_entry) to `align` argument for
pool_init(9); it must be power of 2.
(3) Align pvo_entry to 32-byte boundary only if reasonably possible,
i.e., OEA without DIAGNOSTIC (--> POOL_REDZONE) for now.
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.118 -r1.119 src/sys/arch/powerpc/oea/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc/oea
Date: Fri, 15 Dec 2023 09:36:36 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:36:36 UTC 2023
Modified Files:
src/sys/arch/powerpc/oea: pmap.c
Log Message:
powerpc/oea: pmap_create: Use PR_ZERO and drop memset(9), NFC
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.119 -r1.120 src/sys/arch/powerpc/oea/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc
Date: Fri, 15 Dec 2023 09:42:33 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:42:33 UTC 2023
Modified Files:
src/sys/arch/powerpc/include: vmparam.h
src/sys/arch/powerpc/include/oea: pmap.h
src/sys/arch/powerpc/oea: pmap.c pmap_kernel.c
Log Message:
powerpc: oea: For OEA64_BRIDGE, 1:1 map up to 3GiB memory
As done for OEA. Note that kva over 3GiB is reserved.
Provide PMAP_MAP_POOLPAGE for OEA64_BRIDGE at the same time, by
which direct-mapped memory is utilized in order to work around
starvation of 512MiB kernel virtual space.
PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.26 -r1.27 src/sys/arch/powerpc/include/vmparam.h
cvs rdiff -u -r1.38 -r1.39 src/sys/arch/powerpc/include/oea/pmap.h
cvs rdiff -u -r1.120 -r1.121 src/sys/arch/powerpc/oea/pmap.c
cvs rdiff -u -r1.13 -r1.14 src/sys/arch/powerpc/oea/pmap_kernel.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57621 CVS commit: src/sys/arch/powerpc
Date: Fri, 15 Dec 2023 09:44:00 +0000
Module Name: src
Committed By: rin
Date: Fri Dec 15 09:44:00 UTC 2023
Modified Files:
src/sys/arch/powerpc/include: pmap.h
src/sys/arch/powerpc/powerpc: bus_dma.c vm_machdep.c
Log Message:
powerpc: Make sure direct-mapped buffer fits within correct range
For OEA and OEA64_BRIDGE, only first 3GiB memory is direct-mapped.
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.42 -r1.43 src/sys/arch/powerpc/include/pmap.h
cvs rdiff -u -r1.55 -r1.56 src/sys/arch/powerpc/powerpc/bus_dma.c
cvs rdiff -u -r1.105 -r1.106 src/sys/arch/powerpc/powerpc/vm_machdep.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/57621 CVS commit: [netbsd-10] src/sys/arch/powerpc
Date: Fri, 29 Dec 2023 20:21:40 +0000
Module Name: src
Committed By: martin
Date: Fri Dec 29 20:21:40 UTC 2023
Modified Files:
src/sys/arch/powerpc/include [netbsd-10]: pmap.h vmparam.h
src/sys/arch/powerpc/include/oea [netbsd-10]: pmap.h
src/sys/arch/powerpc/oea [netbsd-10]: pmap.c pmap_kernel.c
src/sys/arch/powerpc/powerpc [netbsd-10]: bus_dma.c trap.c vm_machdep.c
Log Message:
Additionally pull up following revision(s) (requested by rin in ticket #400):
sys/arch/powerpc/include/oea/pmap.h: revision 1.39
sys/arch/powerpc/include/pmap.h: revision 1.43
sys/arch/powerpc/oea/pmap_kernel.c: revision 1.14
sys/arch/powerpc/oea/pmap.c: revision 1.117
sys/arch/powerpc/oea/pmap.c: revision 1.118
sys/arch/powerpc/oea/pmap.c: revision 1.119
sys/arch/powerpc/include/vmparam.h: revision 1.27
sys/arch/powerpc/powerpc/trap.c: revision 1.165
sys/arch/powerpc/oea/pmap.c: revision 1.120
sys/arch/powerpc/oea/pmap.c: revision 1.121
sys/arch/powerpc/powerpc/vm_machdep.c: revision 1.106
sys/arch/powerpc/powerpc/bus_dma.c: revision 1.56
powerpc/oea: trap: pmap_{pte,ste}_spill() even in the interrupt context
Page table for oea is something like L2 TLB on memory; kernel and
processes share its entries, and process entries can be spilled out.
As done for MMU based on software-managed TLB, we need to restore
such entries even in the interrupt context.
Note that pmap_pte_spill() require no resouce to restore entries.
Still-not-implemented pmap_ste_spill() for OEA64 should also.
Part of PR kern/57621
powerpc/oea: pmap: Drop unused argument for pmap_pvo_reclaim(), NFC
Part of PR kern/57621
powerpc/oea: pmap: Rework pmap_pte_spill()
It was broken in many ways... Now, it gets working stable both for
OEA and OEA64_BRIDGE, as far as I can see.
Part of PR kern/57621
powerpc/oea: pmap: Fix mostly-pointless overhead of pmap_pvo_pool
(1) Drop __aligned(32) from struct pvo_entry; otherwise,
sizeof(struct pvo_entry) is round-up'ed to a multiple of 32.
(2) Do not set sizeof(struct pvo_entry) to `align` argument for
pool_init(9); it must be power of 2.
(3) Align pvo_entry to 32-byte boundary only if reasonably possible,
i.e., OEA without DIAGNOSTIC (--> POOL_REDZONE) for now.
Part of PR kern/57621
powerpc/oea: pmap_create: Use PR_ZERO and drop memset(9), NFC
Part of PR kern/57621
powerpc: oea: For OEA64_BRIDGE, 1:1 map up to 3GiB memory
As done for OEA. Note that kva over 3GiB is reserved.
Provide PMAP_MAP_POOLPAGE for OEA64_BRIDGE at the same time, by
which direct-mapped memory is utilized in order to work around
starvation of 512MiB kernel virtual space.
PR kern/57621
powerpc: Make sure direct-mapped buffer fits within correct range
For OEA and OEA64_BRIDGE, only first 3GiB memory is direct-mapped.
Part of PR kern/57621
To generate a diff of this commit:
cvs rdiff -u -r1.42 -r1.42.4.1 src/sys/arch/powerpc/include/pmap.h
cvs rdiff -u -r1.26 -r1.26.4.1 src/sys/arch/powerpc/include/vmparam.h
cvs rdiff -u -r1.37 -r1.37.4.1 src/sys/arch/powerpc/include/oea/pmap.h
cvs rdiff -u -r1.114.4.1 -r1.114.4.2 src/sys/arch/powerpc/oea/pmap.c
cvs rdiff -u -r1.13 -r1.13.4.1 src/sys/arch/powerpc/oea/pmap_kernel.c
cvs rdiff -u -r1.55 -r1.55.4.1 src/sys/arch/powerpc/powerpc/bus_dma.c
cvs rdiff -u -r1.163 -r1.163.20.1 src/sys/arch/powerpc/powerpc/trap.c
cvs rdiff -u -r1.105 -r1.105.2.1 src/sys/arch/powerpc/powerpc/vm_machdep.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home