While the pmap functions take care of properly ordering cache and TLB flushes,
not all TLB flush requests are sent to all CPUs (due to per CPU pmap tracking)
while cache flushes are always broadcast.
XXX: need to investigate pmap tracking for cache flush operation as well.
XXX should it be ETHER_MIN_LEN - ETHER_CRC_LEN ?
XXX2 we assume there are enouth space in the mbuf for the padding bytes.
But other places in the code assumes this already.
- in tlb_flush_all(), don't skip TLB entries with the high bit on,
I was confused about which MMU register it was using. it's also fine
to use the last hardware context.
- in pmap_create(), don't allocate a hardware context for the new pmap.
it's unnecessary, and when this would cause us to recycle all the contexts,
it would result in the current process's context being set to 0
(ie. the kernel's context). the current process could then return to
userspace without going through the context-switch code (and thus without
having a hardware context reallocated). this would lead to user mappings
being entered in the kernel's context later, causing all sorts of trouble.
add some assertions to catch this kind of thing.
auich_set_rate() modified audio_params::sample_rate to actual
sample rate though auich_set_params() rejected sample rates
other than some specific rates. For example, setting 8000Hz
with auich_set_params() modified sample_rate to 7998Hz in the
case of overclocked AC97 codec, and calling auich_set_params()
again returned with EINVAL because sample_rate was 7998Hz and
auich_set_params() rejected 7998Hz.
For now, auich_set_params() never modify audio_params::sample_rate.
(Thanks Alan!)
* Before attempting to use KERNOBJDIR, we now need to "make obj" in
${KERNSRCDIR}/${KERNARCHDIR}/compile, not in ${TOP}/etc as used to be
the case.
* Fix one place where getmakevar was invoked unconditionally. It needs
to be conditional on $runcmd != "echo", so that we can rely on the
existence of the new $make executable.
* Add a sanity check to getmakevar, to bomb if a similar error is
introduced in the future.
* Changed the bomb function to print to stderr instead of to stdout, and
to kill the top level shell process. Without this, an attempted bomb
from inside getmakevar did not work properly.
* Moved some duplicated code into a new safe_getmakevar function, which
calls getmakevar if that is safe, or else emits a literal '$' followed
by the variable name.
Improvements from me:
* Always 'trap "exit 1" 1 2 3 15', so the kill in bomb() doesn't cause ugly
output.
simonb