coretemp.c: drop redundant condition (NFCI)

Checking for a processor model upper limit has no point inside a block
that is already limited further. Noted from code inspection by Sotiris
Lamprinidis in PR kern/58372.

While here, also update to a cached version of an URL for processor
references, as both original URLs have now been removed by Intel.

branches: 1.41.2;
coretemp.c: don't accept impossibly low TjMax values

r. 1.39 introduced a regression where instead of applying a reasonable
default maximum (as was done prior to that change), incorrect values
were accepted and applied, as failures to retrieve an expected MSR
value weren't accounted for.

Apply different logic for unexpectedly low vs. high maximums, with
distinct warnings for each. Also add another warning about a retrieval
failure right at the outset (which also just uses the default, then).

This change fundamentally doesn't address the fact that
__SHIFTOUT(msr, MSR_TEMP_TARGET_READOUT)
doesn't necessarily return a valid value. It just restores prior
behaviour, which is more reasonable than applying a zero value, which
started happening on some older hardware. (I infer this is most likely
an issue with dated generations of Intel hardware with this feature.)
The challenge is that this evidently isn't all documented properly
anywhere. Various "magic values" in this driver need further
investigation.

While here, also fix output so warnings are cleanly formatted, rather
than the slightly scrambled way they were appearing.

Tested on older Intel hardware I had on hand:
E7500 (now falls back to default 100 rather than 0)
E5540 (successfully retrieves 97, as before)
i5-3340M (successfully retrieves 105, as before)

coretemp.c: fix grammar in a warning message

(I get several of these warnings on boot on a particular machine. Now,
it also seems that the code isn't retrieving the correct value, either;
TBD.)

coretemp(4): Change limits of Tjmax.

- Change the lower limit from 70 to 60. At least, some BIOSes can change
the value down to 62.
- Change the upper limit from 110 to 120. At least, some BIOSes can change
the value up to 115.
- Print error message when rdmsr(TEMPERATURE_TARGET) failed.
- When Tjmax exceeded the limit, print warning message and use the value
as it is.

branches: 1.38.4;
KNF. No functional change.

Add special handling for model 0x0f stepping >=2 or mode 0x0e to get Tjmax.

branches: 1.36.4;
- Detect and set Atom's Tj(max) to 90 if it's not the 45nm D400/D500/N400
series (90 for Diamondville and 100 for Pineview). From FreeBSD r221509.
- Reduce diff a little against FreeBSD.

branches: 1.35.10; 1.35.16; 1.35.18;
KNF. Remove extra spaces. No functional change.

- Change the Upper limit of Tjmax from 100 to 110 because some new
CPUs have 105. This change is the same as FreeBSD.
- Print Tjmax with aprint_verbose().
- Reduce the diff against FreeBSD.

Update module dependencies for all the existing modules that depend on sysmon components.

branches: 1.32.4; 1.32.6;
Remove unused variable

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

Fix calculation of the cpu model (display model) in coretemp_tjmax().
The CPUID2MODEL() macro returns only low 4bit, so the checking against 0x17
doesn't work correctly. The correct way is to use the display model.
Remove incorrect extmodel check. Same as FreeBSD.

branches: 1.29.2; 1.29.4;
Collect rnd(9) entropy from coretemp(4), acpibat(4), aibs(4), hpacel(4),
thinkpad(4), and aps(4).

branches: 1.28.2;
Like the comment says, also MSR_IA32_EXT_CONFIG is unsafe; use rdmsr_safe().
Fixes the panic reported by njoly@.

Use rdmsr_safe() when reading IA32_TEMPERATURE_TARGET.

Inialize sensor state before registering.

branches: 1.25.2;
Dont try to read MSR_TEMPERATURE_TARGET on Core Duo Yonah

Comment out IA32_TEMPERATURE_TARGET temporarily.

Only attach on the first SMT ID (as in revision 1.16).

Fix autoconf(9) of cpufeaturebus.

Call pmf_device_deregister(9) during detach.

Add couple of additional CPU model checks for the undocumented Tj(max).

Use constants and bits(3), and fix a typo.

Add proper definitions. Remove (too) verbose comments. Remove (wrong) debug
printf. Do not mark the sensor as invalid based on whether the critical
detector output signal has (ever) been asserted without reset. Support for
trip-points will be added later.

Modularize coretemp(4). Ok jmcneill@.

branches: 1.16.2; 1.16.4;
Add definitions for Intel Digital Thermal Sensor and Power Management, at
CPUID Fn0000_0006, %eax, %ecx. Use these instead of magic numbers.

only attach on SMT ID 0 cpus.

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.

branches: 1.14.2;
Remove setting of the edata->monitor since that member no longer exists.

branches: 1.13.2;
CPU model and CPU extended model cannot simply be summed; the extended model
differentiates different CPUs within a given model type (i.e. model 0xe with
extended model 0x1 is NOT the same as a model 0xf).
Modern Xeons do not support MSR_IA32_EXT_CONFIG, so use model and extended
model correctly to avoid it

It is only by accident that these get definitions they need from
<sys/device.h>, so explicitly #include <sys/device.h>.

branches: 1.11.2; 1.11.4; 1.11.8; 1.11.12;
PR/39458: Juan RP: avoid attaching coretemp on systems that don't have it
by checking the read valid bit.

branches: 1.10.4;
Don't abuse ci_cpuid - in particular, ci_cpuid != ci_signature.

branches: 1.9.6; 1.9.8; 1.9.10; 1.9.12;
coretemp_refresh: run xc_unicast() regardless if sc->sc_ci is curcpu()
or not, this fixes a deadlock seen by Greg Oster in a Dual Quad Core
machine with 8 coretemp instances.

Pass the same size to both kmem_alloc(9) and kmem_free(9), this fixes
the kmem_poison_check in DEBUG kernels.

Start detangling lock.h from intr.h. This is likely to cause short term
breakage, but the mess of dependencies has been regularly breaking the
build recently anyhow.

machine/cpufunc.h is required now.

After comments from joerg@, backout previous and use 'cpuN'.

Change the description to 'coreN' rather than 'cpuN', which seems to
be more correct.

branches: 1.3.2; 1.3.4; 1.3.8;
Use the returned value of xc_unicast() on xc_wait(), that will wait
for completion on the CPU running the xcall thread.

Tested on a 8-way Xeon by Greg Oster.

Extend the envsys2 API (one more time, sorry) as defined in:

http://mail-index.netbsd.org/tech-kern/2007/11/09/0001.html

sysmon_envsys_create() and sysmon_envsys_destroy() were added to
create/destroy sysmon_envsys objects (and its TAILQ/LIST for sensors/events).

sysmon_envsys_sensor_attach() and sysmon_envsys_sensor_detach() were
added to attach/detach sensors to a specified sysmon_envsys device.

The events framework is now per device and configurable via the
ENVSYS_SETDICTIONARY ioctl or /etc/envsys.conf and envstat(8).

Update all users and documentation to reflect these changes.

branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8; 1.1.10;
Add coretemp(4). A new driver for Intel Core's on-die thermal sensor,
available on Intel Core or newer CPUs.

Ported from FreeBSD. Tested by rmind on i386 and joerg on amd64.

Enabled with "options INTEL_CORETEMP".