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>

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.