kernconfig_mutex. Update module subsystem to use this mutex rather than
its own internal (non-recursive) mutex. Make module_autoload() do its
own locking to be consistent with the rest of the module_xxx() calls.
Update module(9) man page appropriately.
As discussed on tech-kern over the last few weeks.
Welcome to NetBSD 5.99.39 !
- XPSS spec says that Status{,Mask} and Control{,Mask} buffers are 8 bytes
- use ACPI_GET64 macros instead of memcpy when reading from buffers
This makes acpicpu work again on my VIA C7-M, whose firmware reports
malformed XPSS packages but has a working _PSS
invariant APIC timer or an "ARAT" ("always running APIC timer"). This means
that the APIC timer may keep ticking at the same rate also in deep C-states
with some new or forthcoming Intel CPUs.
It was observed that at least Sverre Froyen's ThinkPad T500 reports values
that do not match readings from the IA32_PERF_STATUS register. This only
applied to the P0-state. Thus, for now, skip the status check if Turbo
Boost has been detected and the requested state is P0.
This needs to be revisited once Turbo Boost actually works in NetBSD. It is
unclear whether this is a BIOS flaw or not; these values may well be what we
get from IA32_PERF_STATUS once the CPU actually uses the +133.33 MHz boost.
Intel processors. The invariance means that TSC runs at a constant rate
during all ACPI state changes. If it is variant, skew may occur and TSC is
generally unsuitable for wall clock services. This is especially relevant
with C-states; with variant TSC, the whole counter may be stopped with states
larger than C1. All x86 CPUs before circa mid-2000s can be assumed to have a
variant time stamp counter.
binaries by default with separate sections for executable, writeable
data and constants. Use the same heuristic as FreeBSD to match up the
text and data segment assumptions.
existing CPU power management implementations could peacefully coexist with
the acpicpu(4) driver. The following options can not be used with acpicpu(4):
ENHANCED_SPEEDSTEP, INTEL_ONDEMAND_CLOCKMOD, POWERNOW_K7, and POWERNOW_K8.
config_interrupts(9) to be executed. This is necessary because: (a) the
initialization routines must be run only once after interrupts are enabled
and (b) all ACPI CPUs have attached.
driver methods, call the driver's putchar() method to redraw the affected
areas.
For unaccelerated framebuffers where reads are expensive and we can't spare
any memory for a shadow framebuffer. Enabled by setting VCONS_DONT_READ in
scr_flags
still not ideal, as ACPI gives us information about "cross logical processor
dependencies". For instance, a single MSR call on one CPU may cause all other
CPUs in the same domain to follow the state shift. Thus, rather than using
xc_broadcast(9), we should xc_unicast(9) on per-domain or per-CPU-set basis.
- fix colour oddities seen occasionally on sparc64
- try to use firmware DAC wiring until we figure out what's wrong
TODO:
- find out why radeonfb gets the DAC wiring ass-backwards on my xvr-100
while Xorg's radeon driver gets it right
- find out why reverse characters aren't drawn in reverse
tested on macppc and sparc64
necessary for vget() to handle VI_INACTNOW as a special case. Remove this
check and its support in vrelel().
Getting another reference while the freelist is locked is an error. Replace
the check with a KASSERT.
advance the "first" pointer. This problem triggered only if the
bus was filled in the first round, since the first pointer is at
the end-of-bus only for the bootstrap round.
Comparable to T-states, this gives effectively a window of available
performance states for passive cooling. An example:
Init: max = 0, min = Pn.
Time j. Time j + 1.
----------- -----------
2000 MHz P0 max P0
P1 P1 max
P2 ==> P2
P3 P3 min
P4 P4
P5 min P5
500 Mhz Pn Pn
----------- -----------
Search: repeat (i = P0; i <= P5) repeat (i = P1; i <= P3)
1. Initialize P-states properly to P0. It is processor-specific
what value we might get without initialization. (Some AMD CPUs
have even specific registers for the state after cold reset.)
2. Following design notes for Windows, set the lowest-power P-state
upon suspend and restore the saved state after resume.
reviews.
In kernel, it matches the 'i386_use_pae' variable (0: kernel does not use
PAE, 1: kernel uses PAE). Will be used by i386 kvm(3) to know the functions
that should get called for VA => PA translations.
- no need to keep TX/RX mbufs during xfers in struct kue_chain
- check RX packet length more strictly in kue_rxeof()
- make some TX/RX handling in kue_send() and kue_rxeof() more readable
with proper functions
Tested on:
kue0: LINKSYS USB Network Adapter, rev 1.00/2.02, addr 5
dynamic maximum is nonexistent. Unsurprisingly, there is vagueness in the
standards; in ACPI 3.0 and 4.0 it is clearly indicated that also these methods
must be present, but the earlier standards are less stringent. Without too
much effort, at least one old P4-system was located that lacks _PPC.
Instead of specifying a range of supported sample rates based on the lowest
and highest available frequencies, only advertise rates that the codec reports
as working. Let aurateconv take care of the rest.
a CPU. This fixes some heavy-load problems with the pool code when
rump kernels essentially lied and caused the pool code not to do
a proper backdown from the fastpath when a context switch happened
when taking a lock.
on my i7, cpus 0/4, 1/5, 2/6 and 3/7 have identical information and the
processor manual says that there are only 4 actual sensors.
this still doesn't attach (yet) on that system, due to a core solo/duo
errata being wrongly applied, but i haven't figured out the right way
to do that.
When plugging a firewire webcam, sbp attaches.
sbpattach() calls sbp_alloc_target().
In sbp_alloc_target, crom_search_key() fails and sbp_alloc_target() returns NULL.
Move mutex and list initializations up in sbpattach() and in sbp_alloc_target()
so that destroyal of them through sbpdetach() does not cause
LOCKDEBUG panics when unplugging the firewire webcam.
Remarks:
1. Native instructions are supported only on Intel. Native support for
other x86 vendors will be investigated. By assumption, AMD and others
use the I/O based approach.
2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in
order to use acpicpu(4). Otherwise fatal MSR races may occur.
Unlike with P-states, no attempt is done to disable the existing
implementation.
3. There is no rationale to export controls to user land.
4. Throttling is an artefact from the past. T-states will not be used for
power management per se. For CPU frequency management, P-states are
preferred in all circumstances. No noticeable additional power savings
were observed in various experiments. When the system has been scaled
to the highest (i.e. lowest power) P-state, it is preferable to move
from C0 to deeper C-states than it is to actively throttle the CPU.
5. But T-states need to be implemented for passive cooling via acpitz(4).
As specified by ACPI and Intel documents, these can be used as the
last line of defence against critical thermal conditions. Support
for this will be added later.
(required for interaction with T-states), and (3) use aprint_debug(9)
instead of the ACPI_DEBUG_PRINT(x) macro for the dynamic frequency changes
(for the time being, people need easier way to observe the dynamic changes).
