first component is missing. (Since the merging just OR's the maps,
this isn't that big of a deal, as it will just over-estimate the
amount of checking that needs to be done.)
module which is linked into the kernel and cannot be unloaded.
The main purpose is to get the proper constructors run and create
any /dev nodes necessary for said component. Once more of the
kernel (e.g. networking stack and device drivers) are converted to
MODULE and devfs pops up from somewhere, rump components can be
retired.
limit values from the device driver, remove the high_limit and low_limit
entries from the hw.dbcool<#>.<sensor> sysctl(8) tree. These limits are
now directly accessible via envstat(8). Simplify the remaining code
somewhat.
No objections raised on either tech-kern@ or current-users@
XXX The fan controllers's parameters (including those that are tied to
XXX temperature sensors) are still in sysctl, since there isn't any clean
XXX way to implement the fan controllers in sysmon_envsys yet. It is on
XXX my To-Do list...
for paddr_t values under i386 PAE. Use ctob() instead.
Although amd64 is not affected by this vaddr_t vs paddr_t issue (both
having the same size), for the sake of completeness, switch to
ctob() when manipulating paddr_t/psize_t entities in amd64 machdep.c.
Compile tested for i386 and amd64. No regression expected.
(instead of size_t) to avoid possible overflow when system may have more
than 4GB of memory (like PAE).
The behavior of rbus_min_start_hint() remains the same. While here, fix
printf's format strings (paddr_t => PRIxPADDR).
Use ctob() and cast physmem to psize_t to avoid losing bits above 4GB.
Comes from PAE patch from Jeremy Morse; adaptation by me.
Compile tested for GENERIC only. No regression expected.
* * *
XXX: The internal memory tracking of ACPICA, available when
ACPI_DBG_TRACK_ALLOCATIONS is defined, has been removed
from ACPI_DEBUG.
This is due to the instability of the ABI of ACPICA.
If the memory tracking is enabled, ACPICA will insert a header
to each memory allocation. As a consequence, when ACPI specific
code is loaded as a kernel module and the running kernel has
been compiled with ACPI_DEBUG, the result is an instant panic.
This happens because of unaligned memory access when the code
tries to use ACPI_FREE for a buffer obtained via ACPI_ALLOCATE,
AcpiEvaluateObject(), and related calls.
If the involved memory statistics are required, a separate constant
ACPI_DEBUG_ALLOC is available in options(4) for ACPI_DEBUG kernels.
* * *
Discussed with, and ok'ed by, jmcneill@ and pooka@.
* Semantics.
* Remove ACPI_LID_DEBUG.
* Reduce the amount of error reporting.
* As the status of the lid (open/closed) is known upon suspend, move the
state variable to the softc, and avoid one object evaluation this way.
conditionally build DEV_BSIZE adjustments for kernel. fsck_ffs shares
the same code but accesses physical blocks.
Also compute correct block numbers for each physical sector.
pooka