[Skiboot] [PATCH 055/110] doc: misc formatting fixes
Stewart Smith
stewart at linux.ibm.com
Fri May 31 16:12:56 AEST 2019
Signed-off-by: Stewart Smith <stewart at linux.ibm.com>
---
doc/process/stable-skiboot-rules.rst | 1 +
doc/release-notes/skiboot-5.9-rc5.rst | 3 +-
doc/release-notes/skiboot-6.0.18.rst | 1 +
doc/release-notes/skiboot-6.0.20.rst | 97 +++++++--------
doc/release-notes/skiboot-6.0.rst | 1 +
doc/release-notes/skiboot-6.2.2.rst | 7 +-
doc/release-notes/skiboot-6.2.4.rst | 163 +++++++++++++-------------
7 files changed, 141 insertions(+), 132 deletions(-)
diff --git a/doc/process/stable-skiboot-rules.rst b/doc/process/stable-skiboot-rules.rst
index 570bb70ed438..38bae8f4e541 100644
--- a/doc/process/stable-skiboot-rules.rst
+++ b/doc/process/stable-skiboot-rules.rst
@@ -32,6 +32,7 @@ What patches are accepted?
HOWTO submit to stable
----------------------
Two ways:
+
1. Send patch to the skiboot-stable at lists.ozlabs.org list with
"[PATCH <stable version>]" in subject
diff --git a/doc/release-notes/skiboot-5.9-rc5.rst b/doc/release-notes/skiboot-5.9-rc5.rst
index 04c37f482407..a2beb615a4a3 100644
--- a/doc/release-notes/skiboot-5.9-rc5.rst
+++ b/doc/release-notes/skiboot-5.9-rc5.rst
@@ -68,8 +68,7 @@ Over :ref:`skiboot-5.9-rc3`, we have the following changes:
at error level indicating a problem.
- phb4: Fix GEN3 for DD2.00
- In this fix:
- 62ac7631ae phb4: Fix PCIe GEN4 on DD2.1 and above
+ In this fix: ``62ac7631ae`` "phb4: Fix PCIe GEN4 on DD2.1 and above",
We fixed DD2.1 GEN4 but broke DD2.00 as GEN3.
This fixes DD2.00 back to GEN3. This time for sure!
diff --git a/doc/release-notes/skiboot-6.0.18.rst b/doc/release-notes/skiboot-6.0.18.rst
index 5465e2e276ed..8011d46a1e70 100644
--- a/doc/release-notes/skiboot-6.0.18.rst
+++ b/doc/release-notes/skiboot-6.0.18.rst
@@ -110,6 +110,7 @@ BMC communication
bt_add_ipmi_msg_head() adds message to top of the list. If bt message list
is not empty then:
+
- if bt_idle() is true then we will endup sending message to BMC before
getting response from BMC for inflight message. Looks like on some
BMC implementation this results in message timeout.
diff --git a/doc/release-notes/skiboot-6.0.20.rst b/doc/release-notes/skiboot-6.0.20.rst
index 7a154336e60f..6542dece1ca9 100644
--- a/doc/release-notes/skiboot-6.0.20.rst
+++ b/doc/release-notes/skiboot-6.0.20.rst
@@ -18,7 +18,7 @@ Bug fixes included in this release are:
for flash even if the BMC is not current ready to service flash
requests. On the assumption that it will become ready, retry for several
minutes to cover a BMC reboot cycle and *eventually* rather than
- *immediately* crash out with:
+ *immediately* crash out with: ::
[ 269.549748] reboot: Restarting system
[ 390.297462587,5] OPAL: Reboot request...
@@ -99,19 +99,19 @@ Bug fixes included in this release are:
shows no thread error reported in TFMR register.
Without this patch the console event show TFMR with no thread error:
- (DEC parity error TFMR[59] injection)
+ (DEC parity error TFMR[59] injection) ::
- [ 53.737572] Severe Hypervisor Maintenance interrupt [Recovered]
- [ 53.737596] Error detail: Timer facility experienced an error
- [ 53.737611] HMER: 0840000000000000
- [ 53.737621] TFMR: 3212000870e04000
+ [ 53.737572] Severe Hypervisor Maintenance interrupt [Recovered]
+ [ 53.737596] Error detail: Timer facility experienced an error
+ [ 53.737611] HMER: 0840000000000000
+ [ 53.737621] TFMR: 3212000870e04000
- After this patch it shows old TFMR value on host console:
+ After this patch it shows old TFMR value on host console: ::
- [ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
- [ 2302.267305] Error detail: Timer facility experienced an error
- [ 2302.267320] HMER: 0840000000000000
- [ 2302.267330] TFMR: 3212000870e14010
+ [ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
+ [ 2302.267305] Error detail: Timer facility experienced an error
+ [ 2302.267320] HMER: 0840000000000000
+ [ 2302.267330] TFMR: 3212000870e14010
- libflash/ipmi-hiomap: Fix blocks count issue
@@ -119,11 +119,12 @@ Bug fixes included in this release are:
If data size is not block aligned then we endup sending block count
less than actual data. BMC will write partial data to flash memory.
- Sample log :
- [ 594.388458416,7] HIOMAP: Marked flash dirty at 0x42010 for 8
- [ 594.398756487,7] HIOMAP: Flushed writes
- [ 594.409596439,7] HIOMAP: Marked flash dirty at 0x42018 for 3970
- [ 594.419897507,7] HIOMAP: Flushed writes
+ Sample log ::
+
+ [ 594.388458416,7] HIOMAP: Marked flash dirty at 0x42010 for 8
+ [ 594.398756487,7] HIOMAP: Flushed writes
+ [ 594.409596439,7] HIOMAP: Marked flash dirty at 0x42018 for 3970
+ [ 594.419897507,7] HIOMAP: Flushed writes
In this case HIOMAP sent data with block count=0 and hence BMC didn't
flush data to flash.
@@ -136,37 +137,37 @@ Bug fixes included in this release are:
pnv_platform_error_reboot() path due to unrecoverable hmi event, the panic
cpu gets stuck in OPAL inside ipmi_queue_msg_sync(). At this time, rest
all other cpus are in smp_handle_nmi_ipi() waiting for panic cpu to proceed.
- But with panic cpu stuck inside OPAL, linux never recovers/reboot.
-
- p0 c1 t0
- NIA : 0x000000003001dd3c <.time_wait+0x64>
- CFAR : 0x000000003001dce4 <.time_wait+0xc>
- MSR : 0x9000000002803002
- LR : 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
-
- STACK: SP NIA
- 0x0000000031c236e0 0x0000000031c23760 (big-endian)
- 0x0000000031c23760 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
- 0x0000000031c237f0 0x00000000300aa5f8 <.hiomap_queue_msg_sync+0x7c>
- 0x0000000031c23880 0x00000000300aaadc <.hiomap_window_move+0x150>
- 0x0000000031c23950 0x00000000300ab1d8 <.ipmi_hiomap_write+0xcc>
- 0x0000000031c23a90 0x00000000300a7b18 <.blocklevel_raw_write+0xbc>
- 0x0000000031c23b30 0x00000000300a7c34 <.blocklevel_write+0xfc>
- 0x0000000031c23bf0 0x0000000030030be0 <.flash_nvram_write+0xd4>
- 0x0000000031c23c90 0x000000003002c128 <.opal_write_nvram+0xd0>
- 0x0000000031c23d20 0x00000000300051e4 <opal_entry+0x134>
- 0xc000001fea6e7870 0xc0000000000a9060 <opal_nvram_write+0x80>
- 0xc000001fea6e78c0 0xc000000000030b84 <nvram_write_os_partition+0x94>
- 0xc000001fea6e7960 0xc0000000000310b0 <nvram_pstore_write+0xb0>
- 0xc000001fea6e7990 0xc0000000004792d4 <pstore_dump+0x1d4>
- 0xc000001fea6e7ad0 0xc00000000018a570 <kmsg_dump+0x140>
- 0xc000001fea6e7b40 0xc000000000028e5c <panic_flush_kmsg_end+0x2c>
- 0xc000001fea6e7b60 0xc0000000000a7168 <pnv_platform_error_reboot+0x68>
- 0xc000001fea6e7bd0 0xc0000000000ac9b8 <hmi_event_handler+0x1d8>
- 0xc000001fea6e7c80 0xc00000000012d6c8 <process_one_work+0x1b8>
- 0xc000001fea6e7d20 0xc00000000012da28 <worker_thread+0x88>
- 0xc000001fea6e7db0 0xc0000000001366f4 <kthread+0x164>
- 0xc000001fea6e7e20 0xc00000000000b65c <ret_from_kernel_thread+0x5c>
+ But with panic cpu stuck inside OPAL, linux never recovers/reboot. ::
+
+ p0 c1 t0
+ NIA : 0x000000003001dd3c <.time_wait+0x64>
+ CFAR : 0x000000003001dce4 <.time_wait+0xc>
+ MSR : 0x9000000002803002
+ LR : 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
+
+ STACK: SP NIA
+ 0x0000000031c236e0 0x0000000031c23760 (big-endian)
+ 0x0000000031c23760 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
+ 0x0000000031c237f0 0x00000000300aa5f8 <.hiomap_queue_msg_sync+0x7c>
+ 0x0000000031c23880 0x00000000300aaadc <.hiomap_window_move+0x150>
+ 0x0000000031c23950 0x00000000300ab1d8 <.ipmi_hiomap_write+0xcc>
+ 0x0000000031c23a90 0x00000000300a7b18 <.blocklevel_raw_write+0xbc>
+ 0x0000000031c23b30 0x00000000300a7c34 <.blocklevel_write+0xfc>
+ 0x0000000031c23bf0 0x0000000030030be0 <.flash_nvram_write+0xd4>
+ 0x0000000031c23c90 0x000000003002c128 <.opal_write_nvram+0xd0>
+ 0x0000000031c23d20 0x00000000300051e4 <opal_entry+0x134>
+ 0xc000001fea6e7870 0xc0000000000a9060 <opal_nvram_write+0x80>
+ 0xc000001fea6e78c0 0xc000000000030b84 <nvram_write_os_partition+0x94>
+ 0xc000001fea6e7960 0xc0000000000310b0 <nvram_pstore_write+0xb0>
+ 0xc000001fea6e7990 0xc0000000004792d4 <pstore_dump+0x1d4>
+ 0xc000001fea6e7ad0 0xc00000000018a570 <kmsg_dump+0x140>
+ 0xc000001fea6e7b40 0xc000000000028e5c <panic_flush_kmsg_end+0x2c>
+ 0xc000001fea6e7b60 0xc0000000000a7168 <pnv_platform_error_reboot+0x68>
+ 0xc000001fea6e7bd0 0xc0000000000ac9b8 <hmi_event_handler+0x1d8>
+ 0xc000001fea6e7c80 0xc00000000012d6c8 <process_one_work+0x1b8>
+ 0xc000001fea6e7d20 0xc00000000012da28 <worker_thread+0x88>
+ 0xc000001fea6e7db0 0xc0000000001366f4 <kthread+0x164>
+ 0xc000001fea6e7e20 0xc00000000000b65c <ret_from_kernel_thread+0x5c>
This is because, there is a while loop towards the end of
ipmi_queue_msg_sync() which keeps looping until "sync_msg" does not match
@@ -174,6 +175,8 @@ Bug fixes included in this release are:
normal scenario time_wait_ms() calls run pollers so that ipmi backend gets
a chance to check ipmi response and set sync_msg to NULL.
+ .. code-block:: c
+
while (sync_msg == msg)
time_wait_ms(10);
diff --git a/doc/release-notes/skiboot-6.0.rst b/doc/release-notes/skiboot-6.0.rst
index 309734557a81..6dae77d9f603 100644
--- a/doc/release-notes/skiboot-6.0.rst
+++ b/doc/release-notes/skiboot-6.0.rst
@@ -867,6 +867,7 @@ Debugging/Testing improvements
------------------------------
Since 6.0-rc1:
+
- mambo: Enable XER CA32 and OV32 bits on P9
POWER9 adds 32 bit carry and overflow bits to the XER, but we need to
diff --git a/doc/release-notes/skiboot-6.2.2.rst b/doc/release-notes/skiboot-6.2.2.rst
index 7326ebd673c2..e34841ab76c3 100644
--- a/doc/release-notes/skiboot-6.2.2.rst
+++ b/doc/release-notes/skiboot-6.2.2.rst
@@ -1,8 +1,8 @@
.. _skiboot-6.2.2:
-==============
+=============
skiboot-6.2.2
-==============
+=============
skiboot 6.2.2 was released on Wednesday March 6th, 2019. It replaces
:ref:`skiboot-6.2.1` as the current stable release in the 6.2.x series.
@@ -27,7 +27,7 @@ powercap
limit.
ASTBMC
-=====
+======
- astbmc: Enable IPMI HIOMAP for AMI platforms
Required for Habanero, Palmetto and Romulus.
@@ -146,6 +146,7 @@ BMC communication
bt_add_ipmi_msg_head() adds message to top of the list. If bt message list
is not empty then:
+
- if bt_idle() is true then we will endup sending message to BMC before
getting response from BMC for inflight message. Looks like on some
BMC implementation this results in message timeout.
diff --git a/doc/release-notes/skiboot-6.2.4.rst b/doc/release-notes/skiboot-6.2.4.rst
index c6913fd483cd..bba9ebb5e344 100644
--- a/doc/release-notes/skiboot-6.2.4.rst
+++ b/doc/release-notes/skiboot-6.2.4.rst
@@ -1,8 +1,8 @@
.. _skiboot-6.2.4:
-==============
+=============
skiboot-6.2.4
-==============
+=============
skiboot 6.2.4 was released on Thursday May 9th, 2019. It replaces
:ref:`skiboot-6.2.3` as the current stable release in the 6.2.x series.
@@ -18,7 +18,7 @@ Bug fixes included in this release are:
for flash even if the BMC is not current ready to service flash
requests. On the assumption that it will become ready, retry for several
minutes to cover a BMC reboot cycle and *eventually* rather than
- *immediately* crash out with:
+ *immediately* crash out with: ::
[ 269.549748] reboot: Restarting system
[ 390.297462587,5] OPAL: Reboot request...
@@ -74,37 +74,37 @@ Bug fixes included in this release are:
Initialising raw flash lead to a dead assignment to rc. Check the return
code and take the failure path as necessary. Both before and after the
fix we see output along the lines of the following when flash_init()
- fails:
-
- [ 53.283182881,7] IRQ: Registering 0800..0ff7 ops @0x300d4b98 (data 0x3052b9d8)
- [ 53.283184335,7] IRQ: Registering 0ff8..0fff ops @0x300d4bc8 (data 0x3052b9d8)
- [ 53.283185513,7] PHB#0000: Initializing PHB...
- [ 53.288260827,4] FLASH: Can't load resource id:0. No system flash found
- [ 53.288354442,4] FLASH: Can't load resource id:1. No system flash found
- [ 53.342933439,3] CAPP: Error loading ucode lid. index=200ea
- [ 53.462749486,2] NVRAM: Failed to load
- [ 53.462819095,2] NVRAM: Failed to load
- [ 53.462894236,2] NVRAM: Failed to load
- [ 53.462967071,2] NVRAM: Failed to load
- [ 53.463033077,2] NVRAM: Failed to load
- [ 53.463144847,2] NVRAM: Failed to load
-
- Eventually followed by:
-
- [ 57.216942479,5] INIT: platform wait for kernel load failed
- [ 57.217051132,5] INIT: Assuming kernel at 0x20000000
- [ 57.217127508,3] INIT: ELF header not found. Assuming raw binary.
- [ 57.217249886,2] NVRAM: Failed to load
- [ 57.221294487,0] FATAL: Kernel is zeros, can't execute!
- [ 57.221397429,0] Assert fail: core/init.c:615:0
- [ 57.221471414,0] Aborting!
- CPU 0028 Backtrace:
- S: 0000000031d43c60 R: 000000003001b274 ._abort+0x4c
- S: 0000000031d43ce0 R: 000000003001b2f0 .assert_fail+0x34
- S: 0000000031d43d60 R: 0000000030014814 .load_and_boot_kernel+0xae4
- S: 0000000031d43e30 R: 0000000030015164 .main_cpu_entry+0x680
- S: 0000000031d43f00 R: 0000000030002718 boot_entry+0x1c0
- --- OPAL boot ---
+ fails: ::
+
+ [ 53.283182881,7] IRQ: Registering 0800..0ff7 ops @0x300d4b98 (data 0x3052b9d8)
+ [ 53.283184335,7] IRQ: Registering 0ff8..0fff ops @0x300d4bc8 (data 0x3052b9d8)
+ [ 53.283185513,7] PHB#0000: Initializing PHB...
+ [ 53.288260827,4] FLASH: Can't load resource id:0. No system flash found
+ [ 53.288354442,4] FLASH: Can't load resource id:1. No system flash found
+ [ 53.342933439,3] CAPP: Error loading ucode lid. index=200ea
+ [ 53.462749486,2] NVRAM: Failed to load
+ [ 53.462819095,2] NVRAM: Failed to load
+ [ 53.462894236,2] NVRAM: Failed to load
+ [ 53.462967071,2] NVRAM: Failed to load
+ [ 53.463033077,2] NVRAM: Failed to load
+ [ 53.463144847,2] NVRAM: Failed to load
+
+ Eventually followed by: ::
+
+ [ 57.216942479,5] INIT: platform wait for kernel load failed
+ [ 57.217051132,5] INIT: Assuming kernel at 0x20000000
+ [ 57.217127508,3] INIT: ELF header not found. Assuming raw binary.
+ [ 57.217249886,2] NVRAM: Failed to load
+ [ 57.221294487,0] FATAL: Kernel is zeros, can't execute!
+ [ 57.221397429,0] Assert fail: core/init.c:615:0
+ [ 57.221471414,0] Aborting!
+ CPU 0028 Backtrace:
+ S: 0000000031d43c60 R: 000000003001b274 ._abort+0x4c
+ S: 0000000031d43ce0 R: 000000003001b2f0 .assert_fail+0x34
+ S: 0000000031d43d60 R: 0000000030014814 .load_and_boot_kernel+0xae4
+ S: 0000000031d43e30 R: 0000000030015164 .main_cpu_entry+0x680
+ S: 0000000031d43f00 R: 0000000030002718 boot_entry+0x1c0
+ --- OPAL boot ---
Analysis of the execution paths suggests we'll always "safely" end this
way due the setup sequence for the blocklevel callbacks in flash_init()
@@ -143,19 +143,19 @@ Bug fixes included in this release are:
shows no thread error reported in TFMR register.
Without this patch the console event show TFMR with no thread error:
- (DEC parity error TFMR[59] injection)
+ (DEC parity error TFMR[59] injection) ::
- [ 53.737572] Severe Hypervisor Maintenance interrupt [Recovered]
- [ 53.737596] Error detail: Timer facility experienced an error
- [ 53.737611] HMER: 0840000000000000
- [ 53.737621] TFMR: 3212000870e04000
+ [ 53.737572] Severe Hypervisor Maintenance interrupt [Recovered]
+ [ 53.737596] Error detail: Timer facility experienced an error
+ [ 53.737611] HMER: 0840000000000000
+ [ 53.737621] TFMR: 3212000870e04000
- After this patch it shows old TFMR value on host console:
+ After this patch it shows old TFMR value on host console: ::
- [ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
- [ 2302.267305] Error detail: Timer facility experienced an error
- [ 2302.267320] HMER: 0840000000000000
- [ 2302.267330] TFMR: 3212000870e14010
+ [ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
+ [ 2302.267305] Error detail: Timer facility experienced an error
+ [ 2302.267320] HMER: 0840000000000000
+ [ 2302.267330] TFMR: 3212000870e14010
- libflash/ipmi-hiomap: Fix blocks count issue
@@ -163,11 +163,12 @@ Bug fixes included in this release are:
If data size is not block aligned then we endup sending block count
less than actual data. BMC will write partial data to flash memory.
- Sample log :
- [ 594.388458416,7] HIOMAP: Marked flash dirty at 0x42010 for 8
- [ 594.398756487,7] HIOMAP: Flushed writes
- [ 594.409596439,7] HIOMAP: Marked flash dirty at 0x42018 for 3970
- [ 594.419897507,7] HIOMAP: Flushed writes
+ Sample log ::
+
+ [ 594.388458416,7] HIOMAP: Marked flash dirty at 0x42010 for 8
+ [ 594.398756487,7] HIOMAP: Flushed writes
+ [ 594.409596439,7] HIOMAP: Marked flash dirty at 0x42018 for 3970
+ [ 594.419897507,7] HIOMAP: Flushed writes
In this case HIOMAP sent data with block count=0 and hence BMC didn't
flush data to flash.
@@ -180,37 +181,37 @@ Bug fixes included in this release are:
pnv_platform_error_reboot() path due to unrecoverable hmi event, the panic
cpu gets stuck in OPAL inside ipmi_queue_msg_sync(). At this time, rest
all other cpus are in smp_handle_nmi_ipi() waiting for panic cpu to proceed.
- But with panic cpu stuck inside OPAL, linux never recovers/reboot.
-
- p0 c1 t0
- NIA : 0x000000003001dd3c <.time_wait+0x64>
- CFAR : 0x000000003001dce4 <.time_wait+0xc>
- MSR : 0x9000000002803002
- LR : 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
-
- STACK: SP NIA
- 0x0000000031c236e0 0x0000000031c23760 (big-endian)
- 0x0000000031c23760 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
- 0x0000000031c237f0 0x00000000300aa5f8 <.hiomap_queue_msg_sync+0x7c>
- 0x0000000031c23880 0x00000000300aaadc <.hiomap_window_move+0x150>
- 0x0000000031c23950 0x00000000300ab1d8 <.ipmi_hiomap_write+0xcc>
- 0x0000000031c23a90 0x00000000300a7b18 <.blocklevel_raw_write+0xbc>
- 0x0000000031c23b30 0x00000000300a7c34 <.blocklevel_write+0xfc>
- 0x0000000031c23bf0 0x0000000030030be0 <.flash_nvram_write+0xd4>
- 0x0000000031c23c90 0x000000003002c128 <.opal_write_nvram+0xd0>
- 0x0000000031c23d20 0x00000000300051e4 <opal_entry+0x134>
- 0xc000001fea6e7870 0xc0000000000a9060 <opal_nvram_write+0x80>
- 0xc000001fea6e78c0 0xc000000000030b84 <nvram_write_os_partition+0x94>
- 0xc000001fea6e7960 0xc0000000000310b0 <nvram_pstore_write+0xb0>
- 0xc000001fea6e7990 0xc0000000004792d4 <pstore_dump+0x1d4>
- 0xc000001fea6e7ad0 0xc00000000018a570 <kmsg_dump+0x140>
- 0xc000001fea6e7b40 0xc000000000028e5c <panic_flush_kmsg_end+0x2c>
- 0xc000001fea6e7b60 0xc0000000000a7168 <pnv_platform_error_reboot+0x68>
- 0xc000001fea6e7bd0 0xc0000000000ac9b8 <hmi_event_handler+0x1d8>
- 0xc000001fea6e7c80 0xc00000000012d6c8 <process_one_work+0x1b8>
- 0xc000001fea6e7d20 0xc00000000012da28 <worker_thread+0x88>
- 0xc000001fea6e7db0 0xc0000000001366f4 <kthread+0x164>
- 0xc000001fea6e7e20 0xc00000000000b65c <ret_from_kernel_thread+0x5c>
+ But with panic cpu stuck inside OPAL, linux never recovers/reboot. ::
+
+ p0 c1 t0
+ NIA : 0x000000003001dd3c <.time_wait+0x64>
+ CFAR : 0x000000003001dce4 <.time_wait+0xc>
+ MSR : 0x9000000002803002
+ LR : 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
+
+ STACK: SP NIA
+ 0x0000000031c236e0 0x0000000031c23760 (big-endian)
+ 0x0000000031c23760 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec>
+ 0x0000000031c237f0 0x00000000300aa5f8 <.hiomap_queue_msg_sync+0x7c>
+ 0x0000000031c23880 0x00000000300aaadc <.hiomap_window_move+0x150>
+ 0x0000000031c23950 0x00000000300ab1d8 <.ipmi_hiomap_write+0xcc>
+ 0x0000000031c23a90 0x00000000300a7b18 <.blocklevel_raw_write+0xbc>
+ 0x0000000031c23b30 0x00000000300a7c34 <.blocklevel_write+0xfc>
+ 0x0000000031c23bf0 0x0000000030030be0 <.flash_nvram_write+0xd4>
+ 0x0000000031c23c90 0x000000003002c128 <.opal_write_nvram+0xd0>
+ 0x0000000031c23d20 0x00000000300051e4 <opal_entry+0x134>
+ 0xc000001fea6e7870 0xc0000000000a9060 <opal_nvram_write+0x80>
+ 0xc000001fea6e78c0 0xc000000000030b84 <nvram_write_os_partition+0x94>
+ 0xc000001fea6e7960 0xc0000000000310b0 <nvram_pstore_write+0xb0>
+ 0xc000001fea6e7990 0xc0000000004792d4 <pstore_dump+0x1d4>
+ 0xc000001fea6e7ad0 0xc00000000018a570 <kmsg_dump+0x140>
+ 0xc000001fea6e7b40 0xc000000000028e5c <panic_flush_kmsg_end+0x2c>
+ 0xc000001fea6e7b60 0xc0000000000a7168 <pnv_platform_error_reboot+0x68>
+ 0xc000001fea6e7bd0 0xc0000000000ac9b8 <hmi_event_handler+0x1d8>
+ 0xc000001fea6e7c80 0xc00000000012d6c8 <process_one_work+0x1b8>
+ 0xc000001fea6e7d20 0xc00000000012da28 <worker_thread+0x88>
+ 0xc000001fea6e7db0 0xc0000000001366f4 <kthread+0x164>
+ 0xc000001fea6e7e20 0xc00000000000b65c <ret_from_kernel_thread+0x5c>
This is because, there is a while loop towards the end of
ipmi_queue_msg_sync() which keeps looping until "sync_msg" does not match
@@ -218,6 +219,8 @@ Bug fixes included in this release are:
normal scenario time_wait_ms() calls run pollers so that ipmi backend gets
a chance to check ipmi response and set sync_msg to NULL.
+ .. code-block:: c
+
while (sync_msg == msg)
time_wait_ms(10);
--
2.21.0
More information about the Skiboot
mailing list