History log of /freebsd/sys/amd64/include/specialreg.h (Results 51 – 75 of 179)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 1ee774f6 02-Oct-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC


# 10b3b545 17-Sep-2009 Dag-Erling Smørgrav <des@FreeBSD.org>

Merge from head


# 7d4b968b 17-Sep-2009 Dag-Erling Smørgrav <des@FreeBSD.org>

Merge from head up to r188941 (last revision before the USB stack switch)


# 3bcdfb9b 10-Sep-2009 Jung-uk Kim <jkim@FreeBSD.org>

Consolidate CPUID to CPU family/model macros for amd64 and i386 to reduce
unnecessary #ifdef's for shared code between them.


# 2e370a5c 26-May-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

Merge from HEAD


# 9dc0b3d5 13-May-2009 John Baldwin <jhb@FreeBSD.org>

Implement simple machine check support for amd64 and i386.
- For CPUs that only support MCE (the machine check exception) but not MCA
(i.e. Pentium), all this does is print out the value of the mac

Implement simple machine check support for amd64 and i386.
- For CPUs that only support MCE (the machine check exception) but not MCA
(i.e. Pentium), all this does is print out the value of the machine check
registers and then panic when a machine check exception occurs.
- For CPUs that support MCA (the machine check architecture), the support is
a bit more involved.
- First, there is limited support for decoding the CPU-independent MCA
error codes in the kernel, and the kernel uses this to output a short
description of any machine check events that occur.
- When a machine check exception occurs, all of the MCx banks on the
current CPU are scanned and any events are reported to the console
before panic'ing.
- To catch events for correctable errors, a periodic timer kicks off a
task which scans the MCx banks on all CPUs. The frequency of these
checks is controlled via the "hw.mca.interval" sysctl.
- Userland can request an immediate scan of the MCx banks by writing
a non-zero value to "hw.mca.force_scan".
- If any correctable events are encountered, the appropriate details
are stored in a 'struct mca_record' (defined in <machine/mca.h>).
The "hw.mca.count" is a count of such records and each record may
be queried via the "hw.mca.records" tree by specifying the record
index (0 .. count - 1) as the next name in the MIB similar to using
PIDs with the kern.proc.* sysctls. The idea is to export machine
check events to userland for more detailed processing.
- The periodic timer and hw.mca sysctls are only present if the CPU
supports MCA.

Discussed with: emaste (briefly)
MFC after: 1 month

show more ...


# e7153b25 07-May-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

Merge from HEAD


Revision tags: release/7.2.0_cvs, release/7.2.0
# 82fcb0f1 29-Apr-2009 Jeff Roberson <jeff@FreeBSD.org>

- Add support for cpuid leaf 0xb. This allows us to determine the
topology of nehalem/corei7 based systems.
- Remove the cpu_cores/cpu_logical detection from identcpu.
- Describe the layout of

- Add support for cpuid leaf 0xb. This allows us to determine the
topology of nehalem/corei7 based systems.
- Remove the cpu_cores/cpu_logical detection from identcpu.
- Describe the layout of the system in cpu_mp_announce().

Sponsored by: Nokia

show more ...


# 92df0bda 12-Jan-2009 Jung-uk Kim <jkim@FreeBSD.org>

Add basic amd64 support for VIA Nano processors.


# 6811e5d4 05-Jan-2009 Jung-uk Kim <jkim@FreeBSD.org>

Add Centaur/IDT/VIA vendor ID for Nano family, which has long mode support.


Revision tags: release/7.1.0_cvs, release/7.1.0
# 41fe50f5 20-Dec-2008 Sam Leffler <sam@FreeBSD.org>

MFH @ 186335


# 39e52304 13-Dec-2008 Jung-uk Kim <jkim@FreeBSD.org>

Add more CPUID bits from AMD CPUID Specification Rev. 2.28.


# e57c2b13 04-Dec-2008 Dag-Erling Smørgrav <des@FreeBSD.org>

integrate from head@185615


# 5113aa0a 26-Nov-2008 Jung-uk Kim <jkim@FreeBSD.org>

Introduce cpu_vendor_id and replace a lot of strcmp(cpu_vendor, "...").

Reviewed by: jhb, peter (early amd64 version)


Revision tags: release/6.4.0_cvs, release/6.4.0
# e39dddd4 22-Oct-2008 Jung-uk Kim <jkim@FreeBSD.org>

Simplify AMD64_CPU_MODEL() and AMD64_CPU_FAMILY() macros as the base family
should be at least 0xf00 for all supported platforms.


# 87c919e8 22-Oct-2008 Jung-uk Kim <jkim@FreeBSD.org>

Set kern.timecounter.invariant_tsc to 1 for AMD CPU family 10h and higher
even if BIOS does not advertise it.


# 780f139b 21-Oct-2008 Jung-uk Kim <jkim@FreeBSD.org>

Detect Advanced Power Management Information for AMD CPUs.


# e085f869 08-Aug-2008 Stanislav Sedov <stas@FreeBSD.org>

- Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpu

- Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month

show more ...


# 391664b1 12-Mar-2008 John Baldwin <jhb@FreeBSD.org>

The variable MTRR registers actually have variable-sized PhysBase and
PhysMask fields based on the number of physical address bits supported
by the current CPU. The old code assumed 36 bits on i386

The variable MTRR registers actually have variable-sized PhysBase and
PhysMask fields based on the number of physical address bits supported
by the current CPU. The old code assumed 36 bits on i386 and 40 bits on
amd64. In truth, all Intel CPUs up until recently used 36 bits (a newer
Intel CPU uses 38 bits) and all the Opteron CPUs used 40 bits.

In at least one case (the new Intel CPU) having the size of the mask field
wrong resulted in writing questionable values into the MTRR registers on
the application processors (BSP as well if you modify the MTRRs via
memcontrol or running X, etc.). The result of the questionable physmask
was that all of memory was apparently treated as uncached rather than
write-back resulting in a very significant performance hit.

Fix this by constructing a run-time mask for the PhysBase and PhysMask
fields based on the number of physical address bits supported by the CPU.
All 64-bit capable CPUs provide a count of PA bits supported via the
0x80000008 extended CPUID feature, so use that if it is available. If that
feature is not available, then assume 36 PA bits.

While I'm here, expand the (now-unused) macros for the PhysBase and
PhysMask fields to the current largest possible value (52 PA bits).

MFC after: 1 week
PR: i386/120516
Reported by: Nokia

show more ...


# 336d8e55 11-Mar-2008 John Baldwin <jhb@FreeBSD.org>

Add constants for the various fields in MTRR registers.

MFC after: 1 week
Verified by: md5(1)


Revision tags: release/7.0.0_cvs, release/7.0.0
# 2cb23596 03-Feb-2008 David Schultz <das@FreeBSD.org>

Add a few more CPUID feature bits while here. We don't support these
features yet.


# 67f6aa5c 02-Feb-2008 David Schultz <das@FreeBSD.org>

SSE4 CPUID bits


Revision tags: release/6.3.0_cvs, release/6.3.0
# 4ad86324 08-Dec-2007 Alan Cox <alc@FreeBSD.org>

Recognize architectural support for 1GB virtual pages.

MFC after: 6 weeks


# 83d18f22 15-Aug-2007 Dag-Erling Smørgrav <des@FreeBSD.org>

Add a driver for the on-die digital thermal sensor found on Intel Core
and newer CPUs (including Core 2 and Core / Core 2 based Xeons). The
driver attaches to each cpu device and creates a sysctl no

Add a driver for the on-die digital thermal sensor found on Intel Core
and newer CPUs (including Core 2 and Core / Core 2 based Xeons). The
driver attaches to each cpu device and creates a sysctl node in that
device's sysctl context (dev.cpu.N.temperature). When invoked, the
handler binds to the appropriate CPU to ensure a correct reading.

Submitted by: Rui Paulo <rpaulo@fnop.net>
Sponsored by: Google Summer of Code 2007
Tested by: des, marcus, Constantine A. Murenin, Ian FREISLICH
Approved by: re (kensmith)
MFC after: 3 weeks

show more ...


# 753bcb5c 31-May-2007 Dag-Erling Smørgrav <des@FreeBSD.org>

Add CPUID2_PDCM

Requested by: jkim
MFC after: 3 days


12345678