-
Notifications
You must be signed in to change notification settings - Fork 134
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
- Loading branch information
1 parent
d597d8d
commit 19484fa
Showing
1 changed file
with
139 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,139 @@ | ||
.. _skiboot-6.0.9: | ||
|
||
============= | ||
skiboot-6.0.9 | ||
============= | ||
|
||
skiboot 6.0.9 was released on Friday October 12th, 2018. It replaces | ||
:ref:`skiboot-6.0.8` as the current stable release in the 6.0.x series. | ||
|
||
It is recommended that 6.0.9 be used instead of any previous 6.0.x version | ||
due to the bug fixes it contains. | ||
|
||
The bug fixes are: | ||
|
||
- opal/hmi: Ignore debug trigger inject core FIR. | ||
|
||
Core FIR[60] is a side effect of the work around for the CI Vector Load | ||
issue in DD2.1. Usually this gets delivered as HMI with HMER[17] where | ||
Linux already ignores it. But it looks like in some cases we may happen | ||
to see CORE_FIR[60] while we are already in Malfunction Alert HMI | ||
(HMER[0]) due to other reasons e.g. CAPI recovery or NPU xstop. If that | ||
happens then just ignore it instead of crashing kernel as not recoverable. | ||
|
||
- opal/hmi: Handle early HMIs on thread0 when secondaries are still in OPAL. | ||
|
||
When primary thread receives a CORE level HMI for timer facility errors | ||
while secondaries are still in OPAL, thread 0 ends up in rendez-vous | ||
waiting for secondaries to get into hmi handling. This is because OPAL | ||
runs with MSR(EE=0) and hence HMIs are delayed on secondary threads until | ||
they are given to Linux OS. Fix this by adding a check for secondary | ||
state and force them in hmi handling by queuing job on secondary threads. | ||
|
||
I have tested this by injecting HDEC parity error very early during Linux | ||
kernel boot. Recovery works fine for non-TB errors. But if TB is bad at | ||
this very eary stage we already doomed. | ||
|
||
Without this patch we see: :: | ||
|
||
[ 285.046347408,7] OPAL: Start CPU 0x0843 (PIR 0x0843) -> 0x000000000000a83c | ||
[ 285.051160609,7] OPAL: Start CPU 0x0844 (PIR 0x0844) -> 0x000000000000a83c | ||
[ 285.055359021,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000 | ||
[ 285.055361439,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:0: TFMR(2e12002870e14000) Timer Facility Error | ||
[ 286.232183823,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc1) | ||
[ 287.409002056,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc1) | ||
[ 289.073820164,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc1) | ||
[ 290.250638683,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc2) | ||
[ 291.427456821,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc2) | ||
[ 293.092274807,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc2) | ||
[ 294.269092904,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc3) | ||
[ 295.445910944,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc3) | ||
[ 297.110728970,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc3) | ||
|
||
After this patch: :: | ||
|
||
[ 259.401719351,7] OPAL: Start CPU 0x0841 (PIR 0x0841) -> 0x000000000000a83c | ||
[ 259.406259572,7] OPAL: Start CPU 0x0842 (PIR 0x0842) -> 0x000000000000a83c | ||
[ 259.410615534,7] OPAL: Start CPU 0x0843 (PIR 0x0843) -> 0x000000000000a83c | ||
[ 259.415444519,7] OPAL: Start CPU 0x0844 (PIR 0x0844) -> 0x000000000000a83c | ||
[ 259.419641401,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000 | ||
[ 259.419644124,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:0: TFMR(2e12002870e04000) Timer Facility Error | ||
[ 259.419650678,7] HMI: Sending hmi job to thread 1 | ||
[ 259.419652744,7] HMI: Sending hmi job to thread 2 | ||
[ 259.419653051,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000 | ||
[ 259.419654725,7] HMI: Sending hmi job to thread 3 | ||
[ 259.419654916,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000 | ||
[ 259.419658025,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000 | ||
[ 259.419658406,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:2: TFMR(2e12002870e04000) Timer Facility Error | ||
[ 259.419663095,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:3: TFMR(2e12002870e04000) Timer Facility Error | ||
[ 259.419655234,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:1: TFMR(2e12002870e04000) Timer Facility Error | ||
[ 259.425109779,7] OPAL: Start CPU 0x0845 (PIR 0x0845) -> 0x000000000000a83c | ||
[ 259.429870681,7] OPAL: Start CPU 0x0846 (PIR 0x0846) -> 0x000000000000a83c | ||
[ 259.434549250,7] OPAL: Start CPU 0x0847 (PIR 0x0847) -> 0x000000000000a83c | ||
|
||
- hw/bt.c: quieten all the noisy BT/IPMI messages | ||
- npu2: Use correct kill type for TCE invalidation | ||
|
||
kill_type is enum of OPAL_PCI_TCE_KILL_PAGES, OPAL_PCI_TCE_KILL_PE, | ||
OPAL_PCI_TCE_KILL_ALL and phb4_tce_kill() gets it right but | ||
npu2_tce_kill() uses OPAL_PCI_TCE_KILL which is an OPAL API token. | ||
|
||
- hw/npu2-opencapi: Fix setting of supported OpenCAPI templates | ||
|
||
In opal_npu_tl_set(), we made a typo that means the OPAL_NPU_TL_SET call | ||
may not clear the enable bits for templates that were previously enabled | ||
but are now disabled. | ||
|
||
Fix the typo so we clear NPU2_OTL_CONFIG1_TX_TEMP2_EN as well as | ||
TEMP{1,3}_EN. | ||
|
||
- phb4: Workaround PHB errata with CFG write UR/CA errors | ||
|
||
If the PHB encounters a UR or CA status on a CFG write, it will | ||
incorrectly freeze the wrong PE. Instead of using the PE# specified | ||
in the CONFIG_ADDRESS register, it will use the PE# of whatever | ||
MMIO occurred last. | ||
|
||
Work around this disabling freeze on such errors | ||
|
||
- phb4: Handle allocation errors in phb4_eeh_dump_regs() | ||
|
||
If the zalloc fails (and it can be a rather large allocation), | ||
we will overwite memory at 0 instead of failing. | ||
|
||
- phb4: Don't try to access non-existent PEST entries | ||
|
||
In a POWER9 chip, some PHB4s have 256 PEs, some have 512. | ||
|
||
Currently, the diagnostics code retrieves 512 unconditionally, | ||
which is wrong and causes us to incorrectly report bogus values | ||
for the "high" PEs on the small PHBs. | ||
|
||
Use the actual number of implemented PEs instead | ||
|
||
- phb4: Don't probe a PHB if its garded | ||
|
||
Presently phb4_probe_stack() causes an exception while trying to probe | ||
a PHB if its garded. This causes skiboot to go into a reboot loop with | ||
following exception log: :: | ||
|
||
*********************************************** | ||
Fatal MCE at 000000003006ecd4 .probe_phb4+0x570 | ||
CFAR : 00000000300b98a0 | ||
<snip> | ||
Aborting! | ||
CPU 0018 Backtrace: | ||
S: 0000000031cc37e0 R: 000000003001a51c ._abort+0x4c | ||
S: 0000000031cc3860 R: 0000000030028170 .exception_entry+0x180 | ||
S: 0000000031cc3a40 R: 0000000000001f10 * | ||
S: 0000000031cc3c20 R: 000000003006ecb0 .probe_phb4+0x54c | ||
S: 0000000031cc3e30 R: 0000000030014ca4 .main_cpu_entry+0x5b0 | ||
S: 0000000031cc3f00 R: 0000000030002700 boot_entry+0x1b8 | ||
|
||
This is caused as phb4_probe_stack() will ignore all xscom read/write | ||
errors to enable PHB Bars and then tries to perform an mmio to read | ||
PHB Version registers that cause the fatal MCE. | ||
|
||
We fix this by ignoring the PHB probe if the first xscom_write() to | ||
populate the PHB Bar register fails, which indicates that there is | ||
something wrong with the PHB. |