| History log of /src/sys/arch/x86/acpi/acpi_cpu_md.c |
| Revision | | Date | Author | Comments |
| 1.84 |
| 25-Oct-2020 |
nia | Normalize some machine dependent CPU frequenct sysctl variables.
This moves machdep.*.frequency.* to machdep.cpu.frequency.*.
This was proposed on tech-kern some time ago. The intention is to allow
third-party tools such as estd and conky to more easily and reliably
fetch or modify the current CPU frequency without iterating through
various machine-dependent variables to check their presence.
|
| 1.83 |
| 19-Mar-2020 |
ad | PR kern/55080: current does not boot
Back out previous. To be addressed differently.
|
| 1.82 |
| 14-Mar-2020 |
ad | Put ACPI idle under ACPICPU_ENABLE_C3 until the wrinkles are ironed out.
This seems well written and basically all good, but currently doesn't enter
a low power state, and imposes a big performance penalty. Proposed on
port-i386 & port-amd64.
|
| 1.81 |
| 05-Nov-2019 |
maxv | Add the __nocsan attribute on this function. Races on ci_want_resched are
accepted (part of the design).
|
| 1.80 |
| 06-Oct-2019 |
uwe | xc_barrier - convenience function to xc_broadcast() a nop.
Make the intent more clear and also avoid a bunch of (xcfunc_t)nullop
casts that gcc 8 -Wcast-function-type is not happy about.
|
| 1.79 |
| 10-Nov-2018 |
maxv | Remove unused cpu_msr.h includes.
|
| 1.78 |
| 08-Dec-2016 |
nat | branches: 1.78.14; 1.78.16;
Add a synthesized pc beeper and keyboard bell for platforms with an audio
device.
|
| 1.77 |
| 17-Apr-2014 |
christos | branches: 1.77.4; 1.77.8;
CID/1203191: Out of bounds read
|
| 1.76 |
| 27-Mar-2014 |
christos | branches: 1.76.2;
correct/add protection against snprintf overflow.
|
| 1.75 |
| 11-Dec-2013 |
msaitoh | Make new function named tsc_is_invariant() to avoid code duplication.
The behavior of acpicpu_md_flags() will change on some CPUs because
the detecting code of invariant TSC is replaced with newer code.
|
| 1.74 |
| 20-Nov-2013 |
jruoho | Allow 4-bit range for MSR_THERM_CONTROL.
|
| 1.73 |
| 15-Nov-2013 |
msaitoh | Modify some macros and add some new macros for CPU family and model
to reduce code duplication and to avoid bug.
CPUID_TO_STEPPING(cpuid) (not changed)
CPUID_TO_FAMILY(cpuid) (new)
CPUID_TO_MODEL(cpuid) (new)
Return the display family and the display model.
The macro names are the same as FreeBSD.
CPUID_TO_BASEFAMILY(cpuid) (The old name was CPUID2FAMILY)
CPUID_TO_BASEMODEL(cpuid) (The old name was CPUID2MODEL)
Only for the base field.
CPUID_TO_EXTFAMILY(cpuid) (The old name was CPUID2EXTFAMILY)
CPUID_TO_EXTMODEL(cpuid) (The old name was CPUID2EXTMODEL)
Only for the extended field.
See http://mail-index.netbsd.org/port-amd64/2013/11/12/msg001978.html
|
| 1.72 |
| 06-Dec-2012 |
jruoho | branches: 1.72.2;
Disable C1E also on K8, if present. From Imre Vadasz <imre@vdsz.com>
in PR install/47224.
|
| 1.71 |
| 11-Feb-2012 |
jruoho | branches: 1.71.2; 1.71.6; 1.71.8;
Fix missing case for AMD 0x15.
|
| 1.70 |
| 11-Feb-2012 |
jruoho | Add non-XPSS support for AMD family 15h a.k.a. "Bulldozer". Ok releng@.
|
| 1.69 |
| 15-Nov-2011 |
jruoho | branches: 1.69.4;
Add support for AMD family 12h. Also revert revision 1.67, as it implies
maintenance burden for limited value. XXX: Need to add family 15h too.
|
| 1.68 |
| 18-Oct-2011 |
jruoho | branches: 1.68.2;
Convert to use cpufreq(9).
|
| 1.67 |
| 24-Sep-2011 |
jruoho | Try to obtain reliable MHz values for AMD familiesi 10h and 11h.
|
| 1.66 |
| 24-Sep-2011 |
jruoho | Be more intelligent; read the MSR_CMPHALT with rdmsr_safe() and set the
C1E-flag based on this. Pointed out by jmcneill@.
|
| 1.65 |
| 24-Sep-2011 |
jruoho | As the detection of C1E is not entirely clear-cut, use rdmsr_safe()
when reading the AMD "interrupt pending and CMP-halt register".
|
| 1.64 |
| 13-Jul-2011 |
jruoho | Do not disable interrupts at machine-level in the MI idle-loop entry.
|
| 1.63 |
| 23-Jun-2011 |
jruoho | Fix bug pointed out by njoly@.
|
| 1.62 |
| 22-Jun-2011 |
jruoho | Get rid of RUN_ONCE(9). Should fix PR # kern/44043.
|
| 1.61 |
| 12-Jun-2011 |
jruoho | Move the evaluation of the _PDC control method out from the acpicpu(4)
driver to the main acpi(4) stack. Follow Linux and evaluate it early.
Should fix PR port-amd64/42895, possibly also PR kern/42583, and many
other comparable bugs.
A common sense explanation is that Intel supplies additional CPU tables to
OEMs. BIOS writers do not bother to modify their DSDTs, but instead load
these extra tables dynamically as secondary SSDT tables. The actual Load()
happens when the _PDC method is invoked, and thus namespace errors occur
when the CPU-specific ACPI methods are not yet present but referenced in the
AML by various drivers, including, but not limited to, acpitz(4).
|
| 1.60 |
| 06-Jun-2011 |
jruoho | When getting the frequency, use APERF/MPERF as a fallback method.
|
| 1.59 |
| 31-May-2011 |
jruoho | branches: 1.59.2;
Remove the sanity check that tested the internal consistency of the "FID/VID
algorithm" used by K8. Tested by cegger@. The check is still included in the
original powernow(4) (where possible failures have probably gone unnoticed
because the driver is less noisy).
|
| 1.58 |
| 04-Apr-2011 |
dyoung | Neither pci_dma64_available(), pci_probe_device(), pci_mapreg_map(9),
pci_find_rom(), pci_intr_map(9), pci_enumerate_bus(), nor the match
predicate passed to pciide_compat_intr_establish() should ever modify
their pci_attach_args argument, so make their pci_attach_args arguments
const and deal with the fallout throughout the kernel.
For the most part, these changes add a 'const' where there was no
'const' before, however, some drivers and MD code used to modify
pci_attach_args. Now those drivers either copy their pci_attach_args
and modify the copy, or refrain from modifying pci_attach_args:
Xen: according to Manuel Bouyer, writing to pci_attach_args in
pci_intr_map() was a leftover from Xen 2. Probably a bug. I
stopped writing it. I have not tested this change.
siside(4): sis_hostbr_match() needlessly wrote to pci_attach_args.
Probably a bug. I use a temporary variable. I have not tested this
change.
slide(4): sl82c105_chip_map() overwrote the caller's pci_attach_args.
Probably a bug. Use a local pci_attach_args. I have not tested
this change.
viaide(4): via_sata_chip_map() and via_sata_chip_map_new() overwrote the
caller's pci_attach_args. Probably a bug. Make a local copy of the
caller's pci_attach_args and modify the copy. I have not tested
this change.
While I'm here, make pci_mapreg_submap() static.
With these changes in place, I have tested the compilation of these
kernels:
alpha GENERIC
amd64 GENERIC XEN3_DOM0
arc GENERIC
atari HADES MILAN-PCIIDE
bebox GENERIC
cats GENERIC
cobalt GENERIC
evbarm-eb NSLU2
evbarm-el ADI_BRH ARMADILLO9 CP3100 GEMINI GEMINI_MASTER GEMINI_SLAVE GUMSTIX
HDL_G IMX31LITE INTEGRATOR IQ31244 IQ80310 IQ80321 IXDP425 IXM1200
KUROBOX_PRO LUBBOCK MARVELL_NAS NAPPI SHEEVAPLUG SMDK2800 TEAMASA_NPWR
TEAMASA_NPWR_FC TS7200 TWINTAIL ZAO425
evbmips-el AP30 DBAU1500 DBAU1550 MALTA MERAKI MTX-1 OMSAL400 RB153 WGT624V3
evbmips64-el XLSATX
evbppc EV64260 MPC8536DS MPC8548CDS OPENBLOCKS200 OPENBLOCKS266
OPENBLOCKS266_OPT P2020RDB PMPPC RB800 WALNUT
hp700 GENERIC
i386 ALL XEN3_DOM0 XEN3_DOMU
ibmnws GENERIC
macppc GENERIC
mvmeppc GENERIC
netwinder GENERIC
ofppc GENERIC
prep GENERIC
sandpoint GENERIC
sgimips GENERIC32_IP2x
sparc GENERIC_SUN4U KRUPS
sparc64 GENERIC
As of Sun Apr 3 15:26:26 CDT 2011, I could not compile these kernels
with or without my patches in place:
### evbmips-el GDIUM
nbmake: nbmake: don't know how to make /home/dyoung/pristine-nbsd/src/sys/arch/mips/mips/softintr.c. Stop
### evbarm-el MPCSA_GENERIC
src/sys/arch/evbarm/conf/MPCSA_GENERIC:318: ds1672rtc*: unknown device `ds1672rtc'
### ia64 GENERIC
/tmp/genassym.28085/assym.c: In function 'f111':
/tmp/genassym.28085/assym.c:67: error: invalid application of 'sizeof' to incomplete type 'struct pcb'
/tmp/genassym.28085/assym.c:76: error: dereferencing pointer to incomplete type
### sgimips GENERIC32_IP3x
crmfb.o: In function `crmfb_attach':
crmfb.c:(.text+0x2304): undefined reference to `ddc_read_edid'
crmfb.c:(.text+0x2304): relocation truncated to fit: R_MIPS_26 against `ddc_read_edid'
crmfb.c:(.text+0x234c): undefined reference to `edid_parse'
crmfb.c:(.text+0x234c): relocation truncated to fit: R_MIPS_26 against `edid_parse'
crmfb.c:(.text+0x2354): undefined reference to `edid_print'
crmfb.c:(.text+0x2354): relocation truncated to fit: R_MIPS_26 against `edid_print'
|
| 1.57 |
| 24-Mar-2011 |
jruoho | Reset APERF and MPERF only after interrupts have been enabled.
|
| 1.56 |
| 24-Mar-2011 |
jruoho | Remove the "simple CPU lock" that was unnecessary.
Thanks to rmind@ for clarifications.
|
| 1.55 |
| 05-Mar-2011 |
jruoho | branches: 1.55.2;
Add __cpu_simple_lock_t. Use it, x86_read_psl(), and x86_disable_intr() to
disable interrupts locally and protect the access to APERF and MPERF. Also
rationalize the MD initialization sequence.
|
| 1.54 |
| 05-Mar-2011 |
jruoho | If the P-state control mask is set, do a proper read-modify-write.
|
| 1.53 |
| 04-Mar-2011 |
jruoho | Rename a badly named constant. Make it correspond with <x86/specialreg.h>.
|
| 1.52 |
| 02-Mar-2011 |
jruoho | Adjust the detection of Turbo Boost to prevent a theoretical array OOB access.
|
| 1.51 |
| 02-Mar-2011 |
jruoho | Append Intel's Turbo Boost to the debug printfs if we detect it.
|
| 1.50 |
| 01-Mar-2011 |
jruoho | Remove the cross-call from the APERF/MPERF -function.
|
| 1.49 |
| 01-Mar-2011 |
jruoho | Move the xcall(9) that does the P- and T-state transformations from the MD
layer to the main code. Makes the caches coherent and provides consistent
vmstat(1) output. This is still not quite right, given that most of the
cross-calls are typically unnecessary with the dependency coordination.
|
| 1.48 |
| 27-Feb-2011 |
jruoho | Provide MD wrappers for match and attach.
|
| 1.47 |
| 27-Feb-2011 |
jruoho | Claim to support the dependency coordination during the _PDC/_OSC query.
(Although we do not actually support it.) Only after these bits are set,
many Intel-based BIOSes are willing to relinquish the necessary information.
|
| 1.46 |
| 25-Feb-2011 |
jruoho | Fix an oversight; the APERF and MPERF counters are per-CPU, so also reset
these by broadcasting to all CPUs with x86_msr_xcall(9).
|
| 1.45 |
| 25-Feb-2011 |
jruoho | Add couple of comments.
|
| 1.44 |
| 25-Feb-2011 |
jruoho | Also declare support for APERF/MPERF during the BIOS _PDC/_OSC query.
|
| 1.43 |
| 25-Feb-2011 |
jruoho | Rename couple of badly named functions for consistency. No functional change.
|
| 1.42 |
| 25-Feb-2011 |
jruoho | Add support for APERF and MPERF on AMD processors.
|
| 1.41 |
| 25-Feb-2011 |
jruoho | Add preliminary support for the IA32_APERF and IA32_MPERF frequency counters.
These are not yet used for anything and only Intel is supported at the moment.
|
| 1.40 |
| 24-Feb-2011 |
jmcneill | add support for Family 14h (AMD Fusion)
|
| 1.39 |
| 15-Feb-2011 |
jruoho | Fix and add comments.
|
| 1.38 |
| 13-Jan-2011 |
jruoho | branches: 1.38.2; 1.38.4;
Move the function that counts the CPUs from acpicpu(4) to the MD layer.
|
| 1.37 |
| 30-Dec-2010 |
jruoho | Add an additional assertion for the control MSR address.
|
| 1.36 |
| 30-Nov-2010 |
jruoho | Fix boolean brain freeze.
|
| 1.35 |
| 30-Nov-2010 |
jruoho | Add AMD C1E quirk. Tested by cegger@.
(a) This should be removed once C-states are supported.
(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.
|
| 1.34 |
| 25-Aug-2010 |
jruoho | branches: 1.34.2;
Add definitions for Intel Digital Thermal Sensor and Power Management, at
CPUID Fn0000_0006, %eax, %ecx. Use these instead of magic numbers.
|
| 1.33 |
| 24-Aug-2010 |
jruoho | As all reported P-state failures so far have centered around the status-
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.
|
| 1.32 |
| 24-Aug-2010 |
jruoho | Add native support for AMD family 0Fh processors. This is the furthest we
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.
|
| 1.31 |
| 23-Aug-2010 |
jruoho | Other entry points beyond x86_cpu_idle_halt() may use HLT as the
idle-mechanism. Send an IPI also for these in cpu_need_resched().
|
| 1.30 |
| 22-Aug-2010 |
jruoho | Still DELAY(9) a little even when we do not do the status-check.
|
| 1.29 |
| 21-Aug-2010 |
jruoho | After discussion with jakllsch@ and jmcneill@, revert the previous and only
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.
|
| 1.28 |
| 21-Aug-2010 |
jruoho | When we do the sanity check that a P- or T-state transition was successful,
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.
|
| 1.27 |
| 21-Aug-2010 |
jruoho | Use an inverse logic when filling the (X)PSS structures -- if we know
the addresses, we trust ourselves more than a random BIOS in the field.
|
| 1.26 |
| 21-Aug-2010 |
jruoho | Add a comment.
|
| 1.25 |
| 21-Aug-2010 |
jruoho | Check from CPUID 0x06 %eax (on Intel) whether we might actually have an
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.
|
| 1.24 |
| 21-Aug-2010 |
jruoho | Add a quirk for Turbo Boost.
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.
|
| 1.23 |
| 21-Aug-2010 |
jruoho | Detect Intel's Turbo Boost and presence of IA32_APERF/IA32_MPERF. The former
is required for a quirk, and the latter is needed for hardware P-state
coordination (once acpicpu(4) will support fine-grained coordination).
|
| 1.22 |
| 21-Aug-2010 |
jruoho | Detect whether TSC is invariant, which may be the case on both new AMD and
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.
|
| 1.21 |
| 21-Aug-2010 |
jruoho | Properly detect AMD hardware P-state support. Also detect "core boost" (only
present in some models of family 10h).
|
| 1.20 |
| 20-Aug-2010 |
jruoho | Check if SpeedStep is enabled. If it is disabled, try to enable it.
|
| 1.19 |
| 20-Aug-2010 |
jruoho | Revert all previous changes that were made naively believing that the
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.
|
| 1.18 |
| 19-Aug-2010 |
jruoho | Properly calculate the AMD CPU family.
|
| 1.17 |
| 19-Aug-2010 |
jruoho | Add native P-state support for AMD family 10h and 11h processors. Both are
supported irrespective of XPSS. Family 10h tested by jakllsch@.
|
| 1.16 |
| 19-Aug-2010 |
jmcneill | VIA CPUs can have EST as well, so treat them the same as Intel
|
| 1.15 |
| 18-Aug-2010 |
jruoho | Use the idea from cegger@ and fill the (X)PSS structure during initialization.
|
| 1.14 |
| 18-Aug-2010 |
jruoho | Check the status of P- and T-state transformations on all CPUs. This is
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.
|
| 1.13 |
| 18-Aug-2010 |
jruoho | Add MD support for the vendor-independent extended PSS. Some conforming AMD
systems are known to work. Alas, not all of them. We still need to deal with
the variety of different PowerNow! revisions.
|
| 1.12 |
| 14-Aug-2010 |
jruoho | branches: 1.12.2;
Move the PIIX4-quirk to the MD file and disable T-states for PIIX4.
|
| 1.11 |
| 13-Aug-2010 |
jruoho | Remove some unnecessary locking. Mainly a leftover from previous revisions
where the dynamic maximum/minimum was used also when retrieving the current
state. The state-array itself changes only in C-states.
|
| 1.10 |
| 13-Aug-2010 |
jruoho | Merge T-state a.k.a. throttling support for acpicpu(4).
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.
|
| 1.9 |
| 09-Aug-2010 |
jruoho | branches: 1.9.2;
Revert the previous changes to EST. The used hack had an obvious flaw:
the acpicpu(4) driver should attach even if the existing frequency management
code fails to attach, mainly because ACPI is the only proper way to deal
with EST on new Intel system.
Use a more drastic hack to deal with this: when acpicpu(4) attachs, it tears
down any existing sysctl(8) controls and installs identical ones in place.
Upon detachment, the initialization function of the existing EST is called.
|
| 1.8 |
| 09-Aug-2010 |
jruoho | Remove a redundant function.
|
| 1.7 |
| 09-Aug-2010 |
jruoho | When retrieving the current frequency, scan all available P-states.
Only use the dynamic maximum when setting a frequency.
|
| 1.6 |
| 09-Aug-2010 |
jruoho | Move the sysctl function pointers used by acpicpu(4) to x86/cpu.c.
Rename these so that the same pointers may be used in other parts.
|
| 1.5 |
| 08-Aug-2010 |
jruoho | Merge P-state support for acpicpu(4).
Remarks:
1. All processors (x86 or not) for which the vendor has implemented
ACPI I/O access routines are supported. Native instructions are
currently supported only for Intel's "Enhanced Speedstep". Code for
"PowerNow!" (AMD) will be merged later. Native support for VIA's
"PowerSaver" will be investigated.
2. Backwards compatibility with existing userland code is maintained.
Comparable to the case with cpu_idle(9), the ACPI CPU driver
installs alternative functions for the existing sysctl(8) controls.
The "native" behavior (if any) is restored upon detachment.
3. The dynamic nature of ACPI-provided P-states needs more investigation.
The maximum frequency induced (but not forced) by the firmware may
change dynamically. Currently, the sysctl(8) controls error out with
a value larger than the dynamic maximum. The code itself does not
however yet react to the notifications from the firmware by changing
the frequencies in-place. Presumably the system administrator should
be able to choose whether to use dynamic or static frequencies.
|
| 1.4 |
| 04-Aug-2010 |
jruoho | Run a xcall(9) to ensure that all CPUs are out from the ACPI idle-loop
before detachment.
|
| 1.3 |
| 23-Jul-2010 |
jruoho | Make sure we use MWAIT with MONITOR.
Also clarify when we have interrupts disabled.
|
| 1.2 |
| 18-Jul-2010 |
jruoho | Add missing CVS identifiers.
|
| 1.1 |
| 18-Jul-2010 |
jruoho | Merge a driver for ACPI CPUs with basic support for processor power states,
also known as C-states. The code is modular and provides an easy way to add
the remaining functionality later (namely throttling and P-states).
Remarks:
1. Commented out in the GENERICs; more testing exposure is needed.
2. The C3-state is disabled for the time being because it turns off
timers, among them the local APIC timer. This may not be universally
true on all x86 processors; define ACPICPU_ENABLE_C3 to test.
3. The algorithm used to choose a power state may need tuning. When
evaluating the appropriate state, the implementation uses the
previous sleep time as an indicator. Additional hints would include
for example the system load.
Also bus master activity is evaluated when choosing a state. The
usb(4) stack is notorious for such activity even when unused.
Typically it must be disabled in order to reach the C3-state,
but it may also prevent the use of C2.
4. While no extensive empirical measurements have been carried out, the
power savings are somewhere between 1-2 W with C1 and C2, depending
on the processor, firmware, and load. With C3 even up to 4 W can be
saved. The less something ticks, the more power is saved.
ok jmcneill@, joerg@, and discussed with various people.
|
| 1.9.2.3 |
| 09-Oct-2010 |
yamt | sync with head
|
| 1.9.2.2 |
| 11-Aug-2010 |
yamt | sync with head.
|
| 1.9.2.1 |
| 09-Aug-2010 |
yamt | file acpi_cpu_md.c was added on branch yamt-nfs-mp on 2010-08-11 22:52:54 +0000
|
| 1.12.2.3 |
| 22-Oct-2010 |
uebayasi | Sync with HEAD (-D20101022).
|
| 1.12.2.2 |
| 17-Aug-2010 |
uebayasi | Sync with HEAD.
|
| 1.12.2.1 |
| 14-Aug-2010 |
uebayasi | file acpi_cpu_md.c was added on branch uebayasi-xip on 2010-08-17 06:45:29 +0000
|
| 1.34.2.6 |
| 27-Aug-2011 |
jym | Sync with HEAD. Most notably: uvm/pmap work done by rmind@, and MP Xen
work of cherry@.
No regression observed on suspend/restore.
|
| 1.34.2.5 |
| 02-May-2011 |
jym | Sync with head.
|
| 1.34.2.4 |
| 28-Mar-2011 |
jym | Sync with HEAD. TODO before merge:
- shortcut for suspend code in sysmon, when powerd(8) is not running.
Borrow ``xs_watch'' thread context?
- bug hunting in xbd + xennet resume. Rings are currently thrashed upon
resume, so current implementation force flush them on suspend. It's not
really needed.
|
| 1.34.2.3 |
| 10-Jan-2011 |
jym | Sync with HEAD
|
| 1.34.2.2 |
| 24-Oct-2010 |
jym | Sync with HEAD
|
| 1.34.2.1 |
| 25-Aug-2010 |
jym | file acpi_cpu_md.c was added on branch jym-xensuspend on 2010-10-24 22:48:16 +0000
|
| 1.38.4.2 |
| 05-Mar-2011 |
bouyer | Sync with HEAD
|
| 1.38.4.1 |
| 17-Feb-2011 |
bouyer | Sync with HEAD
|
| 1.38.2.1 |
| 06-Jun-2011 |
jruoho | Sync with HEAD.
|
| 1.55.2.5 |
| 12-Jun-2011 |
rmind | sync with head
|
| 1.55.2.4 |
| 21-Apr-2011 |
rmind | sync with head
|
| 1.55.2.3 |
| 06-Mar-2011 |
rmind | sync with head (and fix few botches with this)
|
| 1.55.2.2 |
| 05-Mar-2011 |
rmind | sync with head
|
| 1.55.2.1 |
| 05-Mar-2011 |
rmind | file acpi_cpu_md.c was added on branch rmind-uvmplock on 2011-03-05 20:52:27 +0000
|
| 1.59.2.1 |
| 23-Jun-2011 |
cherry | Catchup with rmind-uvmplock merge.
|
| 1.68.2.3 |
| 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
|
| 1.68.2.2 |
| 16-Jan-2013 |
yamt | sync with (a bit old) head
|
| 1.68.2.1 |
| 17-Apr-2012 |
yamt | sync with head
|
| 1.69.4.1 |
| 18-Feb-2012 |
mrg | merge to -current.
|
| 1.71.8.1 |
| 13-Dec-2012 |
riz | Pull up following revision(s) (requested by jruoho in ticket #741):
sys/arch/x86/acpi/acpi_cpu_md.c: revision 1.72
Disable C1E also on K8, if present. From Imre Vadasz <imre@vdsz.com>
in PR install/47224.
|
| 1.71.6.3 |
| 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.71.6.2 |
| 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.71.6.1 |
| 25-Feb-2013 |
tls | resync with head
|
| 1.71.2.2 |
| 25-Nov-2013 |
bouyer | Pull up following revision(s) (requested by jruoho in ticket #987):
sys/arch/x86/acpi/acpi_cpu_md.c: revision 1.74
sys/dev/acpi/acpi_cpu_tstate.c: revision 1.32
As discussed with bouyer@, fix a too eager T-state validation check to
accomodate new Intel CPUs.
Allow 4-bit range for MSR_THERM_CONTROL.
|
| 1.71.2.1 |
| 13-Dec-2012 |
riz | Pull up following revision(s) (requested by jruoho in ticket #741):
sys/arch/x86/acpi/acpi_cpu_md.c: revision 1.72
Disable C1E also on K8, if present. From Imre Vadasz <imre@vdsz.com>
in PR install/47224.
|
| 1.72.2.1 |
| 18-May-2014 |
rmind | sync with head
|
| 1.76.2.1 |
| 10-Aug-2014 |
tls | Rebase.
|
| 1.77.8.1 |
| 07-Jan-2017 |
pgoyette | Sync with HEAD. (Note that most of these changes are simply $NetBSD$
tag issues.)
|
| 1.77.4.1 |
| 05-Feb-2017 |
skrll | Sync with HEAD
|
| 1.78.16.2 |
| 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.78.16.1 |
| 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.78.14.1 |
| 26-Nov-2018 |
pgoyette | Sync with HEAD, resolve a couple of conflicts
|
