#
e1f14dc3 |
| 08-Apr-2024 |
miod <miod@openbsd.org> |
There is too much #ifdef DEBUG stuff cluttering locore, really. While some of it had sense in the early days of the sparc64 port, this code has bitrotten and is getting in the way. Time for a visit t
There is too much #ifdef DEBUG stuff cluttering locore, really. While some of it had sense in the early days of the sparc64 port, this code has bitrotten and is getting in the way. Time for a visit to the Attic.
This removes: - interrupt handling debug code (forcing hz = 1, probably broken since years). - unused or too invasive DEBUG code which noone will ever use in this state. - #if 0 code blocks which have been this way since locore.s revision 1.1 and will never get enabled.
ok kettenis@
show more ...
|
#
8a1e8cca |
| 29-Mar-2024 |
miod <miod@openbsd.org> |
Drop the first argument of intr_establish().
Instead, require all callers to put the right value in the ih_pil field, and have intr_establish() trust them rather than assigning this field again from
Drop the first argument of intr_establish().
Instead, require all callers to put the right value in the ih_pil field, and have intr_establish() trust them rather than assigning this field again from its first argument.
ok claudio@ kettenis@
show more ...
|
#
f635dc10 |
| 29-Mar-2024 |
miod <miod@openbsd.org> |
Remove truly unneeded includes (not included indirectly).
ok claudio@ kettenis@
|
#
bdd1b079 |
| 29-Mar-2024 |
miod <miod@openbsd.org> |
send_softint() was designed as being able to target a particular cpu, but the code for this was never written and all uses target the running cpu anyway, so stop pretending it may do things it won't
send_softint() was designed as being able to target a particular cpu, but the code for this was never written and all uses target the running cpu anyway, so stop pretending it may do things it won't do and drop that cpu argument.
ok claudio@ kettenis@
show more ...
|
#
e78c98cb |
| 29-Mar-2024 |
miod <miod@openbsd.org> |
Remove dead defines, prototypes and data, and duplicate or misleading comments.
ok claudio@ kettenis@
|
#
0ed1bf01 |
| 17-Sep-2023 |
cheloha <cheloha@openbsd.org> |
clockintr: remove clockintr_init(), clockintr_flags
All the state initialization once done in clockintr_init() has been moved to other parts of the kernel. It's a dead function. Remove it.
Likewi
clockintr: remove clockintr_init(), clockintr_flags
All the state initialization once done in clockintr_init() has been moved to other parts of the kernel. It's a dead function. Remove it.
Likewise, the clockintr_flags variable no longer sports any meaningful flags. Remove it. This frees up the CL_* flag namespace, which might be useful to the clockintr frontend if we ever need to add behavior flags to any of those functions.
show more ...
|
#
b3ef18bd |
| 14-Sep-2023 |
cheloha <cheloha@openbsd.org> |
clockintr: replace CL_RNDSTAT with global variable statclock_is_randomized
In order to separate the statclock from the clock interrupt subsystem we need to move all statclock state out into the broa
clockintr: replace CL_RNDSTAT with global variable statclock_is_randomized
In order to separate the statclock from the clock interrupt subsystem we need to move all statclock state out into the broader kernel.
Start by replacing the CL_RNDSTAT flag with a new global variable, "statclock_is_randomized", in kern_clock.c. Update all clockintr_init() callers to set the boolean instead of passing the flag.
Thread: https://marc.info/?l=openbsd-tech&m=169428749720476&w=2
show more ...
|
#
11d1f9b2 |
| 23-Aug-2023 |
cheloha <cheloha@openbsd.org> |
all platforms: separate cpu_initclocks() from cpu_startclock()
To give the primary CPU an opportunity to perform clock interrupt preparation in a machine-independent manner we need to separate the "
all platforms: separate cpu_initclocks() from cpu_startclock()
To give the primary CPU an opportunity to perform clock interrupt preparation in a machine-independent manner we need to separate the "initialization" parts of cpu_initclocks() from the "start the clock interrupt" parts. Currently, cpu_initclocks() does everything all at once, so there is no space for this MI setup.
Many platforms have more-or-less already done this separation by implementing a separate routine named "cpu_startclock()". This patch promotes cpu_startclock() from de facto standard to mandatory API.
- Prototype cpu_startclock() in sys/systm.h alongside cpu_initclocks(). The separation of responsibility between the two routines is a bit fuzzy but the basic guidelines are as follows:
+ cpu_initclocks() must initialize hz, stathz, and profhz, and call clockintr_init().
+ cpu_startclock() must call clockintr_cpu_init() and start the clock interrupt cycle on the calling CPU.
These guidelines will shift in the future, but that's the way things stand as of *this* commit.
- In initclocks(): first call cpu_initclocks(), then do MI setup, and last call cpu_startclock().
- On platforms where cpu_startclock() already exists: don't call cpu_startclock() from cpu_initclocks() anymore.
- On platforms where cpu_startclock() doesn't yet exist: implement it. Usually this is as simple as dividing cpu_initclocks() in two.
Tested on amd64 (i8254, lapic), arm64, i386 (i8254, lapic), macppc, mips64/octeon, and sparc64. Tested on arm/armv7 (agtimer(4)) by phessler@ and jmatthew@. Tested on m88k/luna88k by aoyama@. Tested on powerpc64 by gkoehler@ and mlarkin@. Tested on riscv64 by jmatthew@.
Thread: https://marc.info/?l=openbsd-tech&m=169195251322149&w=2
show more ...
|
#
3342c5b5 |
| 07-Aug-2023 |
miod <miod@openbsd.org> |
Revert 1.43 and always make our own mapping of the Mostek chip. Trying to reuse the prom mapping here is a bad idea because we alter its writeability and the prom will not always expect this.
Repair
Revert 1.43 and always make our own mapping of the Mostek chip. Trying to reuse the prom mapping here is a bad idea because we alter its writeability and the prom will not always expect this.
Repairs powerdown on Tapdole Ultrabook IIe.
discussed with and ok kettenis@
show more ...
|
#
671537bf |
| 25-Jul-2023 |
cheloha <cheloha@openbsd.org> |
statclock: move profil(2), GPROF code to profclock(), gmonclock()
This patch isolates profil(2) and GPROF from statclock(). Currently, statclock() implements both profil(2) and GPROF through a comp
statclock: move profil(2), GPROF code to profclock(), gmonclock()
This patch isolates profil(2) and GPROF from statclock(). Currently, statclock() implements both profil(2) and GPROF through a complex mechanism involving both platform code (setstatclockrate) and the scheduler (pscnt, psdiv, and psratio). We have a machine-independent interface to the clock interrupt hardware now, so we no longer need to do it this way.
- Move profil(2)-specific code from statclock() to a new clock interrupt callback, profclock(), in subr_prof.c. Each schedstate_percpu has its own profclock handle. The profclock is enabled/disabled for a given CPU when it is needed by the running thread during mi_switch() and sched_exit().
- Move GPROF-specific code from statclock() to a new clock interrupt callback, gmonclock(), in subr_prof.c. Where available, each cpu_info has its own gmonclock handle . The gmonclock is enabled/disabled for a given CPU via sysctl(2) in prof_state_toggle().
- Both profclock() and gmonclock() have a fixed period, profclock_period, that is initialized during initclocks().
- Export clockintr_advance(), clockintr_cancel(), clockintr_establish(), and clockintr_stagger() via <sys/clockintr.h>. They have external callers now.
- Delete pscnt, psdiv, psratio. From schedstate_percpu, also delete spc_pscnt and spc_psdiv. The statclock frequency is not dynamic anymore so these variables are now useless.
- Delete code/state related to the dynamic statclock frequency from kern_clockintr.c. The statclock frequency can still be pseudo-random, so move the contents of clockintr_statvar_init() into clockintr_init().
With input from miod@, deraadt@, and claudio@. Early revisions cleaned up by claudio. Early revisions tested by claudio@. Tested by cheloha@ on amd64, arm64, macppc, octeon, and sparc64 (sun4v). Compile- and boot- tested on i386 by mlarkin@. riscv64 compilation bugs found by mlarkin@. Tested on riscv64 by jca@. Tested on powerpc64 by gkoehler@.
show more ...
|
#
d4028b06 |
| 28-Apr-2023 |
cheloha <cheloha@openbsd.org> |
timer(4/sparc64): remove driver
The timer(4/sparc64) driver was effectively disabled during the previous release. Nobody has come forward asking for it to be adapted to work with the new clockintr
timer(4/sparc64): remove driver
The timer(4/sparc64) driver was effectively disabled during the previous release. Nobody has come forward asking for it to be adapted to work with the new clockintr framework, so it's time to remove the driver from the tree.
As of today, if you want to run OpenBSD on SPARC v9 hardware, that hardware needs to sport either %tick and %tick_compare (%asr23), or %stick (%asr24) and %stick_compare (%asr25).
All Sun/Oracle SPARC v9 hardware meets these conditions, from the UltraSPARC I onward.
Most HAL/Fujitsu SPARC v9 hardware meets these conditions, from the SPARC64 III onward. The only HAL/Fujitsu hardware that might not have %tick_compare are the HAL SPARC64 I and SPARC64 II, for which I can find no documentation. However, those processors are currently unsupported by OpenBSD for other reasons, so their support status is unchanged by the removal of this driver.
With help from miod@.
Link: https://marc.info/?l=openbsd-tech&m=167898759928206&w=2
"after unlock" deraadt@, ok mlarkin@ miod@
show more ...
|
#
24ee467d |
| 04-Feb-2023 |
cheloha <cheloha@openbsd.org> |
timecounting: remove incomplete PPS support
The timecounting code has had stubs for pulse-per-second (PPS) polling since it was imported in 2004. At this point it seems unlikely that anyone is goin
timecounting: remove incomplete PPS support
The timecounting code has had stubs for pulse-per-second (PPS) polling since it was imported in 2004. At this point it seems unlikely that anyone is going to finish adding PPS support, so let's remove the stubs:
- Delete the dead tc_poll_pps() call from tc_windup(). - Remove all tc_poll_pps symbols from the kernel.
Link: https://marc.info/?l=openbsd-tech&m=167519035723210&w=2
ok miod@
show more ...
|
#
573d576b |
| 13-Jan-2023 |
cheloha <cheloha@openbsd.org> |
sparc64: switch to clockintr
- Remove all use of timer(4/sparc64) from sparc64/clock.c. - Don't map interrupts in timer_match(), effectively disabling timer(4/sparc64). The driver will be complet
sparc64: switch to clockintr
- Remove all use of timer(4/sparc64) from sparc64/clock.c. - Don't map interrupts in timer_match(), effectively disabling timer(4/sparc64). The driver will be completely removed in a later commit. - Wire up tick_intrclock, stick_intrclock, and sys_tick_intrclock. - All sparc64 machines now have a randomized statclock; stathz = hz, profhz = stathz * 10.
Very special thanks to miod@, without whom this would have been impossible.
sun4v testing by kmos@, mlarkin@, and kn@. sun4u testing (%tick and the oddball USIIe %stick) by miod@. With input from miod@, mlarkin@, and kettenis@.
v1: https://marc.info/?l=openbsd-tech&m=166776418803680&w=2 v2: https://marc.info/?l=openbsd-tech&m=167287772220176&w=2 v3: https://marc.info/?l=openbsd-tech&m=167322011602530&w=2
ok mlarkin@ kettenis@ miod@
show more ...
|
#
4b28d16f |
| 29-Dec-2022 |
cheloha <cheloha@openbsd.org> |
sparc64: pull retry logic out of tickcmpr_set(), sys_tickcmpr_set()
Pull the retry logic out of tickcmpr_set() and sys_tickcmpr_set() into C functions tick_rearm() and sys_tick_rearm(), respectively
sparc64: pull retry logic out of tickcmpr_set(), sys_tickcmpr_set()
Pull the retry logic out of tickcmpr_set() and sys_tickcmpr_set() into C functions tick_rearm() and sys_tick_rearm(), respectively. There is nothing wrong with the retry logic in these assembly functions, but it's better to keep equivalent code similar and this change realigns the %TICK and %SYS_TICK rearm code with that of the Hummingbird %STICK.
Tested by miod@ on UltraSPARC I, UltraSPARC II, and UltraSPARC IIe.
Link: https://marc.info/?l=openbsd-tech&m=167175014315419&w=2
ok kettenis@
show more ...
|
#
2f31c0f7 |
| 22-Dec-2022 |
cheloha <cheloha@openbsd.org> |
sparc64: move retry logic out of stickcmpr_set()
In some cases, stickcmpr_set() fails to ensure that %STICK_CMPR leads %STICK before returning to the caller. Rewriting the retry logic in C triviall
sparc64: move retry logic out of stickcmpr_set()
In some cases, stickcmpr_set() fails to ensure that %STICK_CMPR leads %STICK before returning to the caller. Rewriting the retry logic in C trivially fixes the issue. So move the retry logic out into a new function, stick_rearm().
Issue discovered by miod@, fix tested by miod@.
Link: https://marc.info/?l=openbsd-tech&m=167122933414238&w=2
ok kettenis@
show more ...
|
#
11e6c7e4 |
| 10-Nov-2022 |
jmatthew <jmatthew@openbsd.org> |
Convert sparc64 clock event counter to per-cpu and increment using evcount_inc() rather than atomic operations.
ok kettenis@ jca@ cheloha@
|
#
eb7eaf8d |
| 24-Oct-2021 |
mpi <mpi@openbsd.org> |
Constify struct cfattach.
ok visa@ a long time ago
|
#
36fd90dc |
| 11-Mar-2021 |
jsg <jsg@openbsd.org> |
spelling
|
#
9ac6db98 |
| 23-Feb-2021 |
cheloha <cheloha@openbsd.org> |
sparc64/clock.c: use ANSI-style function definitions
While here, zap a few ARGUSED linter comments.
Compile-tested by deraadt@.
ok deraadt@
|
#
8611d3cd |
| 23-Feb-2021 |
cheloha <cheloha@openbsd.org> |
timecounting: use C99-style initialization for all timecounter structs
The timecounter struct is large and I think it may change in the future. Changing it later will be easier if we use C99-style
timecounting: use C99-style initialization for all timecounter structs
The timecounter struct is large and I think it may change in the future. Changing it later will be easier if we use C99-style initialization for all timecounter structs. It also makes reading the code a bit easier.
For reasons I cannot explain, switching to C99-style initialization sometimes changes the hash of the resulting object file, even though the resulting struct should be the same. So there is a binary change here, but only sometimes. No behavior should change in either case.
I can't compile-test this everywhere but I have been staring at the diff for days now and I'm relatively confident this will not break compilation. Fingers crossed.
ok gnezdo@
show more ...
|
#
ee48eda3 |
| 20-Oct-2020 |
cheloha <cheloha@openbsd.org> |
alpha, loongson, sh, sparc64: recompute tick, tick_nsec when hz(9) is reset
Normally we set hz(9) at compile-time in sys/conf/param.c to the value of HZ. HZ is one of the fundamental compilation op
alpha, loongson, sh, sparc64: recompute tick, tick_nsec when hz(9) is reset
Normally we set hz(9) at compile-time in sys/conf/param.c to the value of HZ. HZ is one of the fundamental compilation options(4). However, sometimes we need to reset hz(9) at runtime.
Whenever we reset hz(9) we need to recompute tick and tick_nsec. Otherwise a variety of "time stuff" in the kernel will not work correctly. For example, most timeouts will expire "too slow" or "too fast". There are a bunch of other places we use tick and tick_nsec that will exhibit similar problems.
Test-compiled by deraadt@.
show more ...
|
#
42bbbbfd |
| 31-Jul-2020 |
kettenis <kettenis@openbsd.org> |
On sun4u systems that have the STICK register, clear the NPT bit of the register such that it can be accessed from userland. With this change we can unconditionally enabled the usertc code again.
o
On sun4u systems that have the STICK register, clear the NPT bit of the register such that it can be accessed from userland. With this change we can unconditionally enabled the usertc code again.
ok naddy@
show more ...
|
#
14c0d295 |
| 24-Jul-2020 |
kettenis <kettenis@openbsd.org> |
Enable usertc if the NPT bit isn't set for %tick and %sys_tick.
ok naddy@
|
#
703c3386 |
| 19-Jul-2020 |
kettenis <kettenis@openbsd.org> |
Disable userland timecounters for now. On some (all?) sun4u machines this triggers an illegal instruction exception presumably because unpriviliged access to the cycle counters is prohibited.
|
#
de43b1a9 |
| 08-Jul-2020 |
kettenis <kettenis@openbsd.org> |
Userland timecounter implementation for sparc64.
ok deraadt@, pirofti@
|