From 70f14f4dd86eb0aa89806b5a30f4cf072f890143 Mon Sep 17 00:00:00 2001 From: Stewart Smith Date: Fri, 15 Dec 2017 11:55:24 +1100 Subject: skiboot 5.9.6 release notes Signed-off-by: Stewart Smith (cherry picked from commit b7de946d5b30585864513cc1bfea4c686f327640) Signed-off-by: Stewart Smith --- doc/release-notes/skiboot-5.9.6.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 doc/release-notes/skiboot-5.9.6.rst (limited to 'doc') diff --git a/doc/release-notes/skiboot-5.9.6.rst b/doc/release-notes/skiboot-5.9.6.rst new file mode 100644 index 0000000..0be7c53 --- /dev/null +++ b/doc/release-notes/skiboot-5.9.6.rst @@ -0,0 +1,30 @@ +.. _skiboot-5.9.6: + +============= +skiboot-5.9.6 +============= + +skiboot 5.9.6 was released on Friday December 15th, 2017. It replaces +:ref:`skiboot-5.9.5` as the current stable release in the 5.9.x series. + +Over :ref:`skiboot-5.9.5`, we have a few bug fixes, they are: + +- sensors: occ: Skip counter type of sensors + + Don't add counter type of sensors to device-tree as they don't + fit into hwmon sensor interface. +- p9_stop_api updates to support IMC across deep stop states. +- opal/xscom: Add recovery for lost core wakeup scom failures. + + Due to a hardware issue where core responding to scom was delayed due to + thread reconfiguration, leaves the SCOM logic in a state where the + subsequent scom to that core can get errors. This is affected for Core + PC scom registers in the range of 20010A80-20010ABF + + The solution is if a xscom timeout occurs to one of Core PC scom registers + in the range of 20010A80-20010ABF, a clearing scom write is done to + 0x20010800 with data of '0x00000000' which will also get a timeout but + clears the scom logic errors. After the clearing write is done the original + scom operation can be retried. + + The scom timeout is reported as status 0x4 (Invalid address) in HMER[21-23]. -- cgit v1.1