diff options
| -rw-r--r-- | doc/process/stable-skiboot-rules.rst | 1 | ||||
| -rw-r--r-- | doc/release-notes/skiboot-5.9-rc5.rst | 3 | ||||
| -rw-r--r-- | doc/release-notes/skiboot-6.0.18.rst | 1 | ||||
| -rw-r--r-- | doc/release-notes/skiboot-6.0.20.rst | 97 | ||||
| -rw-r--r-- | doc/release-notes/skiboot-6.0.rst | 1 | ||||
| -rw-r--r-- | doc/release-notes/skiboot-6.2.2.rst | 7 | ||||
| -rw-r--r-- | 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 570bb70..38bae8f 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@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 04c37f4..a2beb61 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 5465e2e..8011d46 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 7a15433..6542dec 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 3097345..6dae77d 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 7326ebd..e34841a 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 c6913fd..bba9ebb 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); |