of sensors, we need to adjust the sme_fsensor values for some devices.
Failure to do this leaves a sparesly-populated number-space and can
subsequently result in overlapping sensors number assignments. (This
only affects the compatability-mode API, but still needs to be fixed.)
Fix user-after-free bug in pmap_remove(). Page table pages are freed as soon
as the last page table entry that was actually used is cleared. So make sure
we check the page table page is still there for every page we remove.
Otherwise we will bring back the tlb entry and cache lines when we touch the
freed page, and we will create an illegal alias (non-equivalent mapping)
as soon as the page gets re-used.
are not currently set (and, in case of battery capacity sensors, if there
is no value_max). Ensure that such an event-monitor does not trigger the
delivery of any actual events.
Provide a mechanism for sensors to set their limits at time other than
system startup (for example, when a battery is inserted).
This allows us to boot a system with a battery missing, install the
battery some time later, and automatically monitor it without requiring
any user intervention to create the event-monitor. (The actual changes
for battery sensors to use this new capability will come later.)
- additional temperature and fan speed sensors work now
- limits on should work on all temperature sensors
Controlling fan behaviour doesn't work yet, the ADM1031 uses the same
register for both fans which doesn't quite fit with the way the dbcool
driver works.
they are) avoid repeated kernel_lock/unlock by using an intrq on the stack.
About 5%-10% better from run to run, on my *very* simpleminded test. Can't
possibly be worse.
the driver output path (that is, ifp->if_output()). In the case of
entry through the socket code, we are fine, because pru_usrreq takes
KERNEL_LOCK. However, there are a few other ways to cause output
which require protection:
1) direct calls to tcp_output() in tcp_input()
2) fast-forwarding code (ip_flow) -- protected elsewise
against itself by the softnet lock.
3) *Possibly* the ARP code. I have currently persuaded
myself that it is safe because of how it's called.
4) Possibly the ICMP code.
This change addresses #1 and #2.
