aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStewart Smith <stewart@linux.ibm.com>2019-05-31 16:13:01 +1000
committerStewart Smith <stewart@linux.ibm.com>2019-06-03 10:20:00 +1000
commit64e239b22ddae886c2c7914a747b1d521603c699 (patch)
treeba5dfc944e754b6955d0e53653b7814837fb67e6
parentb63096b65bb943a4ee440a0e505baa5cf8766239 (diff)
downloadskiboot-64e239b22ddae886c2c7914a747b1d521603c699.zip
skiboot-64e239b22ddae886c2c7914a747b1d521603c699.tar.gz
skiboot-64e239b22ddae886c2c7914a747b1d521603c699.tar.bz2
skiboot 6.0.9 release notes
Signed-off-by: Stewart Smith <stewart@linux.ibm.com> (cherry picked from commit 19484fa4338f84617ae8282f17b43d658afc3589) Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
-rw-r--r--doc/release-notes/skiboot-6.0.9.rst139
1 files changed, 139 insertions, 0 deletions
diff --git a/doc/release-notes/skiboot-6.0.9.rst b/doc/release-notes/skiboot-6.0.9.rst
new file mode 100644
index 0000000..87eb797
--- /dev/null
+++ b/doc/release-notes/skiboot-6.0.9.rst
@@ -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.