+ It is likely to lose sight of interrupt when the interrupt of irq_base
that is smaller than the same at the level is generated if PIC_MAXSOURCES
is 33 or more.
check (today it was christos@' laptop), follow Linux and disable this rather
expensive sanity-check for the time being. A hypothesis about the cause of
the failures relates to the absence of cross-CPU coordination in the current
implementation.
will go backwards; K7 will not be supported already due doubts about
availability and reliability of ACPI during that era. Some unfortunate code
duplication is present (but not overly much). Thanks to cegger@ and jakllsch@
for patiently testing this.
- Designed to be fully MP-safe and highly efficient.
- Tables/IP sets (hash or red-black tree) for high performance lookups.
- Stateful filtering and Network Address Port Translation (NAPT).
Framework for application level gateways (ALGs).
- Packet inspection engine called n-code processor - inspired by BPF -
supporting generic RISC-like and specific CISC-like instructions for
common patterns (e.g. IPv4 address matching). See npf_ncode(9) manual.
- Convenient userland utility npfctl(8) with npf.conf(8).
NOTE: This is not yet a fully capable alternative to PF or IPFilter.
Further work (support for binat/rdr, return-rst/return-icmp, common ALGs,
state saving/restoring, logging, etc) is in progress.
Thanks a lot to Matt Thomas for various useful comments and code review.
Aye by: board@
do the status-check when the comparison value reported by BIOS is not zero.
The uncertainty noted in the previous commit still applies. But if we ever
see a timeout again, it will likely be either a firmware bug or a special
case like the Intel Turbo Boost.
compare also against the control-field. There appears to be many BIOSes in
the field that report a zero value in the status-field. It is unclear whether
this should be taken as a hint that the status-check is not necessary also
during P-state transitions. If we still see timeouts (EAGAIN), this should
be reverted and the status-check should be bypassed if ps->ps_status is 0.
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.
