<feed xmlns='http://www.w3.org/2005/Atom'>
<title>netbsd/sys/kern/kern_cpu.c, branch trunk</title>
<subtitle>NetBSD fork for lockdoc analysis</subtitle>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/'/>
<entry>
<title>heartbeat(9): New mechanism to check progress of kernel.</title>
<updated>2023-07-07T12:34:49+00:00</updated>
<author>
<name>riastradh</name>
<email>riastradh@NetBSD.org</email>
</author>
<published>2023-07-07T12:34:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=de09df2fbee768e9082e19034d75860393b1d8c7'/>
<id>de09df2fbee768e9082e19034d75860393b1d8c7</id>
<content type='text'>
This uses hard interrupts to check progress of low-priority soft
interrupts, and one CPU to check progress of another CPU.

If no progress has been made after a configurable number of seconds
(kern.heartbeat.max_period, default 15), then the system panics --
preferably on the CPU that is stuck so we get a stack trace in dmesg
of where it was stuck, but if the stuckness was detected by another
CPU and the stuck CPU doesn't acknowledge the request to panic within
one second, the detecting CPU panics instead.

This doesn't supplant hardware watchdog timers.  It is possible for
hard interrupts to be stuck on all CPUs for some reason too; in that
case heartbeat(9) has no opportunity to complete.

Downside: heartbeat(9) relies on hardclock to run at a reasonably
consistent rate, which might cause trouble for the glorious tickless
future.  However, it could be adapted to take a parameter for an
approximate number of units that have elapsed since the last call on
the current CPU, rather than treating that as a constant 1.

XXX kernel revbump -- changes struct cpu_info layout</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This uses hard interrupts to check progress of low-priority soft
interrupts, and one CPU to check progress of another CPU.

If no progress has been made after a configurable number of seconds
(kern.heartbeat.max_period, default 15), then the system panics --
preferably on the CPU that is stuck so we get a stack trace in dmesg
of where it was stuck, but if the stuckness was detected by another
CPU and the stuck CPU doesn't acknowledge the request to panic within
one second, the detecting CPU panics instead.

This doesn't supplant hardware watchdog timers.  It is possible for
hard interrupts to be stuck on all CPUs for some reason too; in that
case heartbeat(9) has no opportunity to complete.

Downside: heartbeat(9) relies on hardclock to run at a reasonably
consistent rate, which might cause trouble for the glorious tickless
future.  However, it could be adapted to take a parameter for an
approximate number of units that have elapsed since the last call on
the current CPU, rather than treating that as a constant 1.

XXX kernel revbump -- changes struct cpu_info layout</pre>
</div>
</content>
</entry>
<entry>
<title>ci_data.cpu_kcpuset -&gt; ci_kcpuset</title>
<updated>2023-02-26T07:13:54+00:00</updated>
<author>
<name>skrll</name>
<email>skrll@NetBSD.org</email>
</author>
<published>2023-02-26T07:13:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=c0e83466bbac1fee0902a1ac3c1ad24a968a7d17'/>
<id>c0e83466bbac1fee0902a1ac3c1ad24a968a7d17</id>
<content type='text'>
NFCI.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NFCI.</pre>
</div>
</content>
</entry>
<entry>
<title>PR kern/45117</title>
<updated>2020-10-08T09:16:13+00:00</updated>
<author>
<name>rin</name>
<email>rin@NetBSD.org</email>
</author>
<published>2020-10-08T09:16:13+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=4a250a2808a9925b61b2cafaf35cdd8c3a3690c2'/>
<id>4a250a2808a9925b61b2cafaf35cdd8c3a3690c2</id>
<content type='text'>
Work around regression introduced in rev 1.92:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_cpu.c#rev1.92

by which ``cpuctl offline n'' became broken on architectures without
__HAVE_INTR_CONTROL (i.e., everything other than alpha and x86);
cpu_setintr() always fails on these archs, and we had neglected
return value from that function until rev 1.91.

XXX
As martin pointed out in the PR, I'm not sure whether fix in rev 1.92
itself is correct or not. Insert XXX comment referring the PR there....</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Work around regression introduced in rev 1.92:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_cpu.c#rev1.92

by which ``cpuctl offline n'' became broken on architectures without
__HAVE_INTR_CONTROL (i.e., everything other than alpha and x86);
cpu_setintr() always fails on these archs, and we had neglected
return value from that function until rev 1.91.

XXX
As martin pointed out in the PR, I'm not sure whether fix in rev 1.92
itself is correct or not. Insert XXX comment referring the PR there....</pre>
</div>
</content>
</entry>
<entry>
<title>Do not allow disabling interrupts on the primary CPU. Fixes PR kern/45117.</title>
<updated>2020-07-13T13:16:07+00:00</updated>
<author>
<name>jruoho</name>
<email>jruoho@NetBSD.org</email>
</author>
<published>2020-07-13T13:16:07+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=4b03573d7f3931babf669805d576376d5e7eb5aa'/>
<id>4b03573d7f3931babf669805d576376d5e7eb5aa</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>At least panic with a useful message if there are too many CPUs.</title>
<updated>2020-05-28T20:29:18+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2020-05-28T20:29:18+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=e0b082363e19c8c474ed312d6c7979824be61eb6'/>
<id>e0b082363e19c8c474ed312d6c7979824be61eb6</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Move proc_lock into the data segment.  It was dynamically allocated because</title>
<updated>2020-05-23T23:42:41+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2020-05-23T23:42:41+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=14b4bbb24d6307d383b4d1c8f1052fe81cf5beb2'/>
<id>14b4bbb24d6307d383b4d1c8f1052fe81cf5beb2</id>
<content type='text'>
at the time we had mutex_obj_alloc() but not __cacheline_aligned.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
at the time we had mutex_obj_alloc() but not __cacheline_aligned.</pre>
</div>
</content>
</entry>
<entry>
<title>Fix build failure.</title>
<updated>2019-12-21T11:35:25+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2019-12-21T11:35:25+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=4507c836d4cf54311ebe044883edac07fd35985f'/>
<id>4507c836d4cf54311ebe044883edac07fd35985f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Split subr_cpu.c out of kern_cpu.c, to contain routines shared with rump.</title>
<updated>2019-12-20T21:20:09+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2019-12-20T21:20:09+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=1ba1dc0f77f23a1b74dd71aa453695503d8efa85'/>
<id>1ba1dc0f77f23a1b74dd71aa453695503d8efa85</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Some more CPU topology stuff:</title>
<updated>2019-12-20T21:05:33+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2019-12-20T21:05:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=07cb63d1f7cd0c3066801dd0faab7c37ba6344d6'/>
<id>07cb63d1f7cd0c3066801dd0faab7c37ba6344d6</id>
<content type='text'>
- Use cegger@'s ACPI SRAT parsing code to figure out NUMA node ID for each
  CPU as it is attached.

- For scheduler experiments with SMT, flag CPUs with the lowest numbered SMT
  IDs as "primaries", link back to the primaries from secondaries, and build
  a circular list of CPUs in each package with identical SMT IDs.

- No need for package/core/smt/numa IDs to be anything other than a u_int.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Use cegger@'s ACPI SRAT parsing code to figure out NUMA node ID for each
  CPU as it is attached.

- For scheduler experiments with SMT, flag CPUs with the lowest numbered SMT
  IDs as "primaries", link back to the primaries from secondaries, and build
  a circular list of CPUs in each package with identical SMT IDs.

- No need for package/core/smt/numa IDs to be anything other than a u_int.</pre>
</div>
</content>
</entry>
<entry>
<title>Passify rump build.</title>
<updated>2019-12-18T19:40:34+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2019-12-18T19:40:34+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=fb1584a75022e5d9d95fed448a8de47668d970b5'/>
<id>fb1584a75022e5d9d95fed448a8de47668d970b5</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
