#
333159 |
|
02-May-2018 |
kib |
MFC r332971: Ensure that cmci_monitor() is not executed in parallel.
|
#
333053 |
|
27-Apr-2018 |
kib |
MFC r332970: Use IS_BSP() macro.
MFC r332989 (by lwhsu): Add i386 IS_BSP().
|
#
331866 |
|
01-Apr-2018 |
markj |
MFC r317567 (by cem): x86 MCA: Fix a deadlock in MCA exception processing
|
#
316832 |
|
14-Apr-2017 |
avg |
MFC r314636,r314700: MCA: add AMD Error Thresholding support
|
#
314385 |
|
28-Feb-2017 |
avg |
MFC r313751: mca: fix writes to MSR_MC_CTL2 in cmci_update
|
#
314349 |
|
27-Feb-2017 |
avg |
MFC r313752,r314035: mca: use time_uptime instead of ticks for CMCI throttling
|
#
313164 |
|
03-Feb-2017 |
pfg |
MFC r312001: Remove __nonnull() attributes from x86 machine check architecture.
In this case the attributes serve little purpose as they just don't enforce run time checks, If anything the attributes would cause NULL pointer checks to be ignored but there are no such checks so the only effect is cosmetic.
Reviewed by: jhb, avg
|
#
310787 |
|
29-Dec-2016 |
markj |
MFC r309657: Require the STACK option for code that captures stacks of running threads.
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
299746 |
|
14-May-2016 |
jhb |
Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot.
This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed.
This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs.
However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu.
Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case.
As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code.
These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling).
PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
|
#
299680 |
|
13-May-2016 |
bz |
Remove the extra _RD as _RDTUN already includes it.
Submitted by: emaste MFC after: 2 weeks
|
#
299678 |
|
13-May-2016 |
bz |
We already turn the AMD erratum383 workaround on for certain VM_GUEST_VM if specific CPU features are not present. Some simulation environments, e.g. gem5, have been found to require more TLB management from the kernel in certain setups. It is currently unclear why. Turning on the workaround_erratum383 seems to help and make problems (panics) go away. Given this is a fairly uncommon environment so far, allowing the workaround to be manually enabled from loader in order to make debugging and comparing traces easier, but also to allow gem5 run FreeBSD in X86 timing mode, seems to be the least intrusive option for now until the issue if fully understood.
Sponsored by: DARPA/AFRL Reviewed by: kib, alc (earlier) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6206
|
#
296272 |
|
01-Mar-2016 |
jhb |
Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compat shim to go.
Submitted by: Howard Su <howard0su@gmail.com> Reviewed by: sephe Differential Revision: https://reviews.freebsd.org/D5131
|
#
283291 |
|
22-May-2015 |
jkim |
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks
|
#
281887 |
|
23-Apr-2015 |
jhb |
Reassign copyright statements on several files from Advanced Computing Technologies LLC to Hudson River Trading LLC.
Approved by: Hudson River Trading LLC (who owns ACT LLC) MFC after: 1 week
|
#
281751 |
|
19-Apr-2015 |
marius |
Refine the workaround for Intel HSD131 [1] added in r269052: - Use the full mask described by the erratum as with a sufficiently high number of these false-positives, the overflow bit (bit 62) additionally gets set [7]. - HSD131 has been brought into several other Haswell-derived CPUs including to the next generation, i. e. Intel Broadwell. Thus, also skip reporting of these benign errors by default on CPU models affected by HSM142, HSW131 and BDM48 [2 - 5], describing the HSD131 silicon bug for additional models. Also, Celeron 2955U with a CPU ID of 0x45 have been reported to be covered by this fault [6], with the specification update concerned with HSM142 [2] only referring to 0x3c and 0x46.
Submitted by: David Froehlich [7] MFC after: 3 days
http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf [1] http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-mobile-specification-update.pdf [2] http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/5th-gen-core-family-spec-update.pdf [3] http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/core-m-processor-family-spec-update.pdf [4] http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v3-spec-update.pdf [5] https://lists.freebsd.org/pipermail/freebsd-hackers/2015-January/046878.html [6]
|
#
269242 |
|
29-Jul-2014 |
marius |
Fix yet another comment typo in r269052.
|
#
269239 |
|
29-Jul-2014 |
marius |
Fix comment typo in r269052.
Submitted by: Daniel O'Connor
|
#
269052 |
|
24-Jul-2014 |
marius |
Intel desktop Haswell CPUs may report benign corrected parity errors (see HSD131 erratum in [1]) at a considerable rate. So filter these (default), unless logging is enabled. Unfortunately, there really is no better way to reasonably implement suppressing these errors than to just skipping them in mca_log(). Given that they are reported for bank 0, they'd need to be masked in MSR_MC0_CTL. However, P6 family processors require that register to be set to either all 0s or all 1s, disabling way more than the one error in question when using all 0s there. Alternatively, it could be masked for the corresponding CMCI, but that still wouldn't keep the periodic scanner from detecting these spurious errors. Apart from that, register contents of MSR_MC0_CTL{,2} don't seem to be publicly documented, neither in the Intel Architectures Developer's Manual nor in the Haswell datasheets.
Note that while HSD131 actually is only about C0-stepping as of revision 014 of the Intel desktop 4th generation processor family specification update, these corrected errors also have been observed with D0-stepping aka "Haswell Refresh".
1: http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf
Reviewed by: jhb MFC after: 3 days Sponsored by: Bally Wulff Games & Entertainment GmbH
|
#
267992 |
|
28-Jun-2014 |
hselasky |
Pull in r267961 and r267973 again. Fix for issues reported will follow.
|
#
267985 |
|
27-Jun-2014 |
gjb |
Revert r267961, r267973:
These changes prevent sysctl(8) from returning proper output, such as:
1) no output from sysctl(8) 2) erroneously returning ENOMEM with tools like truss(1) or uname(1) truss: can not get etype: Cannot allocate memory
|
#
267961 |
|
27-Jun-2014 |
hselasky |
Extend the meaning of the CTLFLAG_TUN flag to automatically check if there is an environment variable which shall initialize the SYSCTL during early boot. This works for all SYSCTL types both statically and dynamically created ones, except for the SYSCTL NODE type and SYSCTLs which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to be used in the case a tunable sysctl has a custom initialisation function allowing the sysctl to still be marked as a tunable. The kernel SYSCTL API is mostly the same, with a few exceptions for some special operations like iterating childrens of a static/extern SYSCTL node. This operation should probably be made into a factored out common macro, hence some device drivers use this. The reason for changing the SYSCTL API was the need for a SYSCTL parent OID pointer and not only the SYSCTL parent OID list pointer in order to quickly generate the sysctl path. The motivation behind this patch is to avoid parameter loading cludges inside the OFED driver subsystem. Instead of adding special code to the OFED driver subsystem to post-load tunables into dynamically created sysctls, we generalize this in the kernel.
Other changes: - Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask" to "hw.pcic.intr_mask". - Removed redundant TUNABLE statements throughout the kernel. - Some minor code rewrites in connection to removing not needed TUNABLE statements. - Added a missing SYSCTL_DECL(). - Wrapped two very long lines. - Avoid malloc()/free() inside sysctl string handling, in case it is called to initialize a sysctl from a tunable, hence malloc()/free() is not ready when sysctls from the sysctl dataset are registered. - Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks Sponsored by: Mellanox Technologies
|
#
263113 |
|
13-Mar-2014 |
jhb |
Correct type for malloc().
Submitted by: "Conrad Meyer" <conrad.meyer@isilon.com>
|
#
261087 |
|
23-Jan-2014 |
jhb |
Move <machine/apicvar.h> to <x86/apicvar.h>.
|
#
260457 |
|
08-Jan-2014 |
jhb |
The changes in r233781 attempted to make logging during a machine check exception more readable. In practice they prevented all logging during a machine check exception on at least some systems. Specifically, when an uncorrected ECC error is detected in a DIMM on a Nehalem/Westmere class machine, all CPUs receive a machine check exception, but only CPUs on the same package as the memory controller for the erroring DIMM log an error. The CPUs on the other package would complete the scan of their machine check banks and panic before the first set of CPUs could log an error. The end result was a clearer display during the panic (no interleaved messages), but a crashdump without any useful info about the error that occurred.
To handle this case, make all CPUs spin in the machine check handler once they have completed their scan of their machine check banks until at least one machine check error is logged. I tried using a DELAY() instead so that the CPUs would not potentially hang forever, but that was not reliable in testing.
While here, don't clear MCIP from MSR_MCG_STATUS before invoking panic. Only clear it if the machine check handler does not panic and returns to the interrupted thread.
|
#
233793 |
|
02-Apr-2012 |
jhb |
Further tweak the changes made in r233709. The kernel doesn't permit sleeping from a swi handler (even though in this case it would be ok), so switch the refill and scanning SWI handlers to being tasks on a fast taskqueue. Also, only schedule the refill task for a CMCI as an MC# can fire at any time, so it should do the minimal amount of work needed and avoid opportunities to deadlock before it panics (such as scheduling a task it won't ever need in practice). To handle the case of an MC# only finding recoverable errors (which should never happen), always try to refill the event free list when the periodic scan executes.
MFC after: 2 weeks
|
#
233781 |
|
02-Apr-2012 |
jhb |
Make machine check exception logging more readable. On newer Intel systems, an uncorrected ECC error tends to fire on all CPUs in a package simultaneously and the current printf hacks are not sufficient to make the messages legible. Instead, use the existing mca_lock spinlock to serialize calls to mca_log() and change the machine check code to panic directly when an unrecoverable error is encoutered rather than falling back to a trap_fatal() call in trap() (which adds nearly a screen-full of logging messages that aren't useful for machine checks).
MFC after: 2 weeks
|
#
233709 |
|
30-Mar-2012 |
jhb |
Attempt to make machine check handling a bit more robust: - Don't malloc() new MCA records for machine checks logged due to a CMCI or MC# exception. Instead, use a pre-allocated pool of records. When a CMCI or MC# exception fires, schedule a swi to refill the pool. The pool is sized to hold at least one record per available machine bank, and one record per CPU. This should handle the case of all CPUs triggering a single bank at once as well as the case a single CPU triggering all of its banks. The periodic scans still use malloc() since they are run from a safe context. - Since we have to create an swi to handle refills, make the periodic scan a second swi for the same thread instead of having a separate taskqueue thread for the scans.
Suggested by: mdf (avoiding malloc()) MFC after: 2 weeks
|
#
227309 |
|
07-Nov-2011 |
ed |
Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.
The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static.
|
#
218221 |
|
03-Feb-2011 |
jhb |
Use a dedicated taskqueue with a thread that runs at a software-interrupt priority for the periodic polling of the machine check registers.
|
#
214630 |
|
01-Nov-2010 |
jhb |
Move the <machine/mca.h> header to <x86/mca.h>.
|
#
210577 |
|
28-Jul-2010 |
jhb |
The corrected error count field is dependent on CMCI, not TES.
MFC after: 1 week
|
#
209212 |
|
15-Jun-2010 |
jhb |
Restore the machine check register banks on resume. For banks being monitored via CMCI, reset the interrupt threshold to 1 on resume.
Reviewed by: jkim MFC after: 2 weeks
|
#
209059 |
|
11-Jun-2010 |
jhb |
Update several places that iterate over CPUs to use CPU_FOREACH().
|
#
208921 |
|
08-Jun-2010 |
jhb |
Move the machine check support code to the x86 tree since it is identical on i386 and amd64.
Requested by: alc
|
#
208621 |
|
28-May-2010 |
jhb |
Defer initializing machine checks for the boot CPU until the local APIC is fully configured.
MFC after: 1 month
|
#
208556 |
|
25-May-2010 |
jhb |
Only enable CMCI on i386 if 'device apic' is enabled in the kernel since it requires the local APIC to work.
|
#
208507 |
|
24-May-2010 |
jhb |
Add support for corrected machine check interrupts. CMCI is a new local APIC interrupt that fires when a threshold of corrected machine check events is reached. CMCI also includes a count of events when reporting corrected errors in the bank's status register. Note that individual banks may or may not support CMCI. If they do, each bank includes its own threshold register that determines when the interrupt fires. Currently the code uses a very simple strategy where it doubles the threshold on each interrupt until it succeeds in throttling the interrupt to occur only once a minute (this interval can be tuned via sysctl). The threshold is also adjusted on each hourly poll which will lower the threshold once events stop occurring.
Tested by: Sailaja Bangaru sbappana at yahoo com MFC after: 1 month
|
#
205573 |
|
24-Mar-2010 |
alc |
Adapt r204907 and r205402, the amd64 implementation of the workaround for AMD Family 10h Erratum 383, to i386.
Enable machine check exceptions by default, just like r204913 for amd64.
Enable superpage promotion only if the processor actually supports large pages, i.e., PG_PS.
MFC after: 2 weeks
|
#
205214 |
|
16-Mar-2010 |
jhb |
- Extend the machine check record structure to include several fields useful for parsing model-specific and other fields in machine check events including the global machine check capabilities and status registers, CPU identification, and the FreeBSD CPU ID. - Report these added fields in the console log of a machine check so that a record structure can be reconstituted from the console messages. - Parse new architectural errors including memory controller errors.
MFC after: 1 week
|
#
204518 |
|
01-Mar-2010 |
jhb |
Print the contents of the miscellaneous (MISC) register to the console if it is valid along with the other register values when a machine check is encountered.
MFC after: 1 week
|
#
200064 |
|
03-Dec-2009 |
avg |
mca: small enhancements related to cpu quirks
- use utility macros for CPU family/model checking - limit Intel P6 quirk to pre-Nehalem models (taken from OpenSolaris) - add AMD GartTblWkEn quirk for families 0Fh and 10h; I haven't experienced any problems without the quirk but both Linux and OpenSolaris do this - slightly re-arrange quirk code to provide for the future generalization and separation of vendor-specific quirk functions
Reviewed by: jhb MFC after: 1 week
|
#
200033 |
|
02-Dec-2009 |
avg |
mca: improve status checking, recording and reporting
- directly print mca information in case we fail to allocate memory for a record - include bank number into mca record - print raw mca status value for extended information
Reviewed by: jhb MFC after: 10 days
|
#
192440 |
|
20-May-2009 |
jhb |
Don't bother reading the initial value of the machine check banks during startup on Pentium 4 CPUs. This wasn't safe to do on APs during AP startup, was of limited value, and won't be used for future processors.
|
#
192343 |
|
18-May-2009 |
jhb |
- Add a tunable 'hw.mca.enabled' that can be used to enable/disable the machine check code. Disable it by default for now. - When computing the mask of bits that determines a non-restartable event during a machine check exception, or-in the overflow flag rather than replacing the other flags.
PR: i386/134586 [2] Submitted by: Andi Kleen andi-fbsd firstfloor.org
|
#
192050 |
|
13-May-2009 |
jhb |
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
|