- Implement pmap_growkernel(), and update kernel pmap's stats with atomics.
- Then, pmap_kenter_pa() and pmap_kremove() no longer need to allocate
memory nor take pm_lock, because they only modify L3 PTEs.
- Then, pm_lock and pp_lock can be adaptive mutexes at IPL_NONE which are
cheaper than spin mutexes.
- Take the pmap's lock in pmap_extract() if not the kernel's pmap, otherwise
pmap_extract() might see inconsistent state.
all mine)
- Use tpidr_el1 to hold curlwp and not curcpu, because curlwp is accessed
much more often by MI code. It also makes curlwp preemption safe and
allows aarch64_curlwp() to be a const function (curcpu must be volatile).
- Make ASTs operate per-LWP rather than per-CPU, otherwise sometimes LWPs
can see spurious ASTs (which doesn't cause a problem, it just means some
time may be wasted).
- Use plain stores to set/clear ASTs. Make sure ASTs are always set on the
same CPU as the target LWP, and delivered via IPI if posted from a remote
CPU so that they are resolved quickly.
- Add some cache line padding to struct cpu_info, to match x86.
- Add a memory barrier in a couple of places where ci_curlwp is set. This
is needed whenever an LWP that is resuming on the CPU could hold an
adaptive mutex. The barrier needs to drain the CPU's store buffer, so
that the update to ci_curlwp becomes globally visible before the LWP can
resume and call mutex_exit(). By my reading of the ARM docs it looks like
the instruction I used will do the right thing, but I'm not 100% sure.
This change fixes a bug that extra delay() is called only once even if
atomic_cas_uint() isn't failed or delay() isn't called when atomic_cas_uint()
failed.
The reason of this bug was that I simply converted FreeBSD' atomic_cmpset_int()
to atomic_cas_uint(). The return value's semantics is different.
Catch up with previous to unbreak autoloading of verbose modules.
PR kern/55535
CVS: ----------------------------------------------------------------------
CVS: CVSROOT cvs.NetBSD.org:/cvsroot
CVS: please use "PR category/123" to have the commitmsg appended to PR 123
CVS:
CVS: Please evaluate your changes and consider the following.
CVS: Abort checkin if you answer no.
CVS: => For all changes:
CVS: Do the changed files compile?
CVS: Has the change been tested?
CVS: => If you are not completely familiar with the changed components:
CVS: Has the change been posted for review?
CVS: Have you allowed enough time for feedback?
CVS: => If the change is major:
CVS: => If the change adds files to, or removes files from $DESTDIR:
CVS: => If you are changing a library or kernel interface:
CVS: Have you successfully run "./build.sh release"?
- T_ZERODIV is integer divide by zero. Therefore, ksi_code should be
FPE_INTDIV, not FPE_FLTDIV.
- Set ksi_addr for SIGTRAP. Also, set TRAP_BRKPT or TRAP_TRACE to
ksi_code appropriately.
This fixes some tests in lib/libc/sys and lib/libc/gen.
XXX
Apply similar fixes to other m68k ports.
Otherwise, address error occurs in kernel at rte instruction when returning
to the user level.
Found by tests/lib/libc/t_ptrace_*:access_regs_set_unaligned_pc_0x[137].
- Adding -fno-asynchronous-unwind-tables and -fno-unwind-tables to COPTS
- Specify NO_KERNEL_RCSIDS to strip RCSIDS
Also adding -fno-omit-frame-pointer to COPTS for backtrace in DDB.
around for reproducible kernel freezes just after ``Starting postfix.'',
where I cannot even enter DDB nor obtain crash dump.
I still haven't figured out why. Possibly something wrong with -Os
optimization level for GCC/m68k, cf.,
http://mail-index.netbsd.org/port-sun3/2020/07/19/msg000166.html
GCC 8 miscompiles aes_ccm_tag() for m68k with optimization level -O[12],
which results in failure in aes_ccm_selftest():
| aes_ccm_selftest: tag 0: 8 bytes @ 0x4d3e38
| 03 80 5f 08 22 6f cb fe | .._."o..
| aes_ccm_selftest: verify 0 failed
| ...
| WARNING: module error: built-in module aes_ccm failed its MODULE_CMD_INIT, error 5
This is observed for amiga (A1200, 68060), mac68k (Quadra 840AV, 68040),
and luna68k (nono, 68030 emulator). However, it is not for sun3 (TME, 68020
emulator) and sun2 (TME, 68010 emulator). At the moment, it is unclear
whether this is due to differences b/w 68010-20 vs 68030-60, or something
wrong with TME.
