| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
BT responses are handled using a timer doing the polling. To hope to
get an answer to an IPMI synchronous message, the timer needs to run.
This issue shows up very quickly under QEMU when loading the first
flash resource with the IPMI HIOMAP backend.
Adding a timeout would also help in reporting errors instead of
looping indefinitely waiting for a response.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
|
|
|
|
| |
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
|
|
|
|
| |
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
|
|
|
|
|
|
|
|
|
|
|
| |
When running in virtual memory mode, the radix MMU hid bit should not
be changed, so set this in the initial boot SPR setup.
As a side effect, fast reboot also has HID0:RADIX bit set by the
shared spr init, so no need for an explicit call.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do this before we fix TFAC errors. Otherwise the event at host console
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)
[ 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:
[ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
[ 2302.267305] Error detail: Timer facility experienced an error
[ 2302.267320] HMER: 0840000000000000
[ 2302.267330] TFMR: 3212000870e14010
Fixes: 674f7696f ("opal/hmi: Rework HMI handling of TFAC errors")
Cc: skiboot-stable@lists.ozlabs.org
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On OpenPower systems the ibm,slot-label property is used to identify
slots rather than the more verbose ibm,slot-location-code. The
slot-label lookup is currently broken since it assumes that the
ibm,slot-label is in the PCI device node rather than in the node of the
device that provides the slot (e.g. root port or switch downstream
port).
This patch corrects the lookup code to search the parent node (and
possibly it's grandparents), similar to how we search for
ibm,slot-location-code.
Fixes: 1c3baae4f2b3 ("hdata/iohub: Look for IOVPD on P9")
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
With opencapi, it's fairly common to trigger HMIs during AFU
development on the FPGA, by not replying in time to an NPU command,
for example. So shift the blame reported by that cow to avoid crowding
my mailbox.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were already logging some NPU registers during an HMI. This patch
cleans up a bit how it is done and separates what is global from what
is specific to nvlink or opencapi.
Since we can now receive an error interrupt when an opencapi link goes
down unexpectedly, we also dump the NPU state but we limit it to the
registers of the brick which hit the error.
The list of registers to dump was worked out with the hw team to
allow for proper debugging. For each register, we print the name as
found in the NPU workbook, the scom address and the register value.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tm-suspend-hypervisor-assist for P9 >=DD2.2
And a tm-suspend-xer-so-bug node for P9 DD2.2 only.
I also treat P9P as P9 DD2.3 and add a unit test for the cpufeatures
infrastructure.
Fixes: https://github.com/open-power/skiboot/issues/233
Suggested-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Tested-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
[stewart: drop USABLE_OS for tm-suspend-hypervisor-assist]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
| |
We call all of these things recursively, so don't use excess stack.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split the i2c_request_send() method into two methods: i2c_request_send()
which allocates and populates and i2c_request structure, and
i2c_request_sync() which take a request structure and blocks until it
completes.
This allows code that allocates a i2c_request structure elsewhere to
make use of the existing busy-wait and request retry logic. Fix the
return types to use int64_t while we're here since these are returning
OPAL_API error codes.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Use the new built-in state variable rather than a single-use completion
function. Makes things a bit cleaner.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Rename ___backtrace() to backtrace_create() and ___print_backtrace() to
backtrace_print(). Get rid of __backtrace() and __print_backtrace()
wrappers.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
We're about to get rid of __backtrace() and __print_backtrace(), convert
the stack check code to not use them.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
In ___backtrace(), store the current PIR in the metadata struct, rather
than relying on the caller to do it.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every time we take a backtrace, we have to store the number of entries, the
OPAL API token, r1 caller and PIR values. Rather than defining these and
passing them around all over the place, let's throw them in a struct.
Define a struct, struct bt_metadata, to store these details, and convert
___backtrace() and ___print_backtrace() to use it.
We change the wrapper functions __backtrace() and __print_backtrace() to
call ___backtrace()/___print_backtrace() with struct bt_metadata, but don't
change their parameter profiles for now - we'll do that later.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
| |
___backtrace() is always called with r1 = __builtin_frame_address(0), and
it's unlikely we're going to need it to do something else any time soon, so
simplify the API by removing the parameter.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On TOD failure, with TB stuck, when linux heads down to
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>
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
with "msg". It loops over time_wait_ms() until exit condition is met. In
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.
while (sync_msg == msg)
time_wait_ms(10);
But in the event when TB is in failed state time_wait_ms()->time_wait_poll()
returns immediately without calling pollers and hence we end up looping
forever. This patch fixes this hang by calling opal_run_pollers() in TB
failed state as well.
Fixes: 1764f2452 ("opal: Fix hang in time_wait* calls on HMI for TB errors.")
Cc: skiboot-stable@lists.ozlabs.org
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
| |
Fixes: 7516e382 (core/ipmi: Improve error message)
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skiboot.tcl defines PAYLOAD_ADDR as 0x20000000, which is the default in
skiboot. This is also the default in skiboot unless kernel-base-address
is set in the device tree.
If you change PAYLOAD_ADDR to something else for mambo, skiboot won't
see it because it doesn't set that DT property, so fix it so that it does.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Acked-by: Michael Neuling <mikey@neuling.org>
[stewart: fix up mambo hacks for STB]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would like to successfully boot if we have a dependency on the BMC
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:
[ 269.549748] reboot: Restarting system
[ 390.297462587,5] OPAL: Reboot request...
[ 390.297737995,5] RESET: Initiating fast reboot 1...
[ 391.074707590,5] Clearing unused memory:
[ 391.075198880,5] PCI: Clearing all devices...
[ 391.075201618,7] Clearing region 201ffe000000-201fff800000
[ 391.086235699,5] PCI: Resetting PHBs and training links...
[ 391.254089525,3] FFS: Error 17 reading flash header
[ 391.254159668,3] FLASH: Can't open ffs handle: 17
[ 392.307245135,5] PCI: Probing slots...
[ 392.363723191,5] PCI Summary:
...
[ 393.423255262,5] OCC: All Chip Rdy after 0 ms
[ 393.453092828,5] INIT: Starting kernel at 0x20000000, fdt at
0x30800a88 390645 bytes
[ 393.453202605,0] FATAL: Kernel is zeros, can't execute!
[ 393.453247064,0] Assert fail: core/init.c:593:0
[ 393.453289682,0] Aborting!
CPU 0040 Backtrace:
S: 0000000031e03ca0 R: 000000003001af60 ._abort+0x4c
S: 0000000031e03d20 R: 000000003001afdc .assert_fail+0x34
S: 0000000031e03da0 R: 00000000300146d8 .load_and_boot_kernel+0xb30
S: 0000000031e03e70 R: 0000000030026cf0 .fast_reboot_entry+0x39c
S: 0000000031e03f00 R: 0000000030002a4c fast_reset_entry+0x2c
--- OPAL boot ---
The OPAL flash API hooks directly into the blocklevel layer, so there's
no delay for e.g. the host kernel, just for asynchronously loaded
resources during boot.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Exiting early in the power off case makes sense since we can't disable
slot power (or assert PERST) for suprise hotplug slots. However, we
should not exit early in the power-on case since it's possible slot
power may have been disabled (or just not enabled at boot time).
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
Working out what was actually going on here took forever.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason we look at the power control indicator and use that to
determine if the slot is "off" rather than the power control flag that
is used to power down the slot.
While we're here change the default behaviour so that the slot is
assumed to be powered on if there's no slot capability, or if there's
no power control available.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The maximum string length for the slot label / device location code in
the PCI summary is currently 32 characters. This results in some IBM
location codes being truncated due to their length, e.g.
PHB#0001:02:11.0 [SWDN] SLOT=C11 x8
PHB#0001:13:00.0 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C
PHB#0001:13:00.1 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C
PHB#0001:13:00.2 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C
PHB#0001:13:00.3 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C
Which obscure the actual location of the card, and it looks bad. This
patch increases the maximum length of the label string to 80 characters
since that's the maximum length for a location code.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
P8 and P9 use the same IO VPD setup, so we need to load the IOHUB VPD on
P9 systems too.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart: fixup op920 hdat_to_dt dts expected result, remove incorrect
comment, skip IOVPD loading on non-FSP.]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 815417dcda2e ("init, occ: Initialise OCC earlier on BMC systems")
conditionally invoked occ_pstates_init() only on FSP based systems in
load_and_boot_kernel(). Due to this pstate table is re-parsed on FSP
system and skipped on BMC system during fast-reboot. So this patch fixes
this by invoking occ_pstates_init() on all boxes during fast-reboot.
Cc: skiboot-stable@lists.ozlabs.org
Fixes: 815417dcda2e ("init, occ: Initialise OCC earlier on BMC systems")
Reported-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Set a flag to indicate OS about TOD/TB failure as part of new
opal_handle_hmi2 handler. This flag then can be used by OS to make sure
functions depending on TB value (e.g. udelay()) are aware of TB not
ticking.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
unlock once and goto error_out.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the correct beXX_to_cpu() macros.
core/i2c.c:105:29: warning: incorrect type in assignment (different base types)
core/i2c.c:105:29: expected unsigned int [usertype] offset
core/i2c.c:105:29: got restricted beint32_t [usertype] subaddr
core/i2c.c:110:29: warning: incorrect type in assignment (different base types)
core/i2c.c:110:29: expected unsigned int [usertype] offset
core/i2c.c:110:29: got restricted beint32_t [usertype] subaddr
core/i2c.c:117:23: warning: incorrect type in assignment (different base types)
core/i2c.c:117:23: expected unsigned int [usertype] dev_addr
core/i2c.c:117:23: got restricted beint16_t [usertype] addr
core/i2c.c:118:21: warning: incorrect type in assignment (different base types)
core/i2c.c:118:21: expected unsigned int [usertype] rw_len
core/i2c.c:118:21: got restricted beint32_t [usertype] size
core/i2c.c:119:24: warning: cast from restricted beint64_t
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently OPAL doesn't know whether BMC is functioning or not. If BMC is
down (like BMC reboot), then we keep on retry sending message to BMC. So
in some corner cases we may hit hard lockup issue in kernel.
Ideally we should avoid using synchronous path as much as possible. But
for now commit 01f977c3 added option to disable message retry in synchronous.
But this fix is not required during boot. Hence lets disable IPMI message
retry during OPAL boot.
Fixes: 01f977c3 (hw/bt: Add backend interface to disable ipmi message)
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
In ipmi_queue_msg_sync() path OPAL will wait until it gets response from
BMC. If we do not get response ontime we may endup in kernel hardlockups.
Hence lets add sync messages to top of the queue. This will reduces the
chance of hardlockups.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
OMG Kees Cook was right, the code is *smaller*. We save like a dozen
instructions in the exception path!
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In-Memory Collection(IMC) counters catalog is compressed blob which is
loaded from the flash; decompression starts once the data is loaded from
nvram by the main thread. This can be optimized by using the libxz API
function which creates a job to do the decompression by not blocking the
main thread.
Refactor decompress() to use the libxz asynchronous wrapper
functions. This also cleans up the error handling path in imc_init().
CC: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a standard API for decompressing images using the existing
method found in the IMC code. This patch also standardizes error codes
and does the decompression asynchronously.
The IMC decompress() function is refactored to decompress blobs/images
as a separate CPU job. 'xz_decompress_start()' starts the decompression
in a newly created CPU job; while 'wait_xz_decompress()' waits for the
job to complete.
The IMC code will be first user for the new APIs; whose implementation
is provided as reference in the next patch.
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During boot OPAL makes IPMI_GET_BT_CAPS call to BMC to get BT interface
capabilities which includes IPMI message max resend count, message
timeout, etc,. Most of the time OPAL gets response from BMC within
specified timeout. In some corner cases (like mboxd daemon reset in BMC,
BMC reboot, etc) OPAL may not get response within timeout period. In
such scenarios, OPAL resends message until max resend count reaches.
OPAL uses synchronous IPMI message (ipmi_queue_msg_sync()) for few
operations like flash read, write, etc. Thread will wait in OPAL until
it gets response from BMC. In some corner cases like BMC reboot, thread
may wait in OPAL for long time (more than 20 seconds) and results in
kernel hardlockup.
This patch introduces new interface to disable message resend option. We
will disable message resend option for synchrous message. This will
greatly reduces kernel hardlock up issues.
This is short term fix. Long term solution is to convert all synchronous
messages to asynhrounous one.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OPAL_PCI_EEH_FREEZE_STATUS call takes a bunch of parameters, one of
them is @phb_status. It is defined as __be64* and always NULL in
the current Linux upstream but if anyone ever decides to read that status,
then the PHB3's handler will assume it is struct OpalIoPhb3ErrorData*
(which is a lot bigger than 8 bytes) and zero it causing the stack
corruption; p7ioc-phb has the same issue.
This removes @phb_status from all eeh_freeze_status() hooks and moves
the error message from PHB4 to the affected OPAL handlers.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-By: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also make it possible to use with afl-lop/afl-fuzz just to help make
*sure* we're all good.
Additionally, if we hit a entry in VERSION that is larger than our
buffer size, we skip over it gracefully rather than overwriting the
stack. This is only a problem if VERSION isn't trusted, which as of
4b8cc05a94513816d43fb8bd6178896b430af08f it is verified as part of
Secure Boot.
CC: stable # v5.9+
Fixes: 9727fe384b8685270d344201f7e051475eea3a0b
[stewart: fix up include ordering for building on centos7]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ISA specifies that MCE interrupts in power saving modes will enter
at 0x200 with powersave bits in SRR1 set. This is not currently
supported properly, the MCE will just happen like a normal interrupt,
but GPRs could be lost, which would lead to crashes (e.g., r1, r2, r13
etc).
So check the power save bits similarly to the sreset vector, and
handle this properly.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
This requires implementing the MSR[RI] bit. Then just allow all
non-fatal sreset exceptions to recover.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Detect non-powersave sresets and send them to the normal exception
handler which prints registers and stack.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide an sreset handler specifically for fast reboots, which allows
FIXUP_ENDIAN to be removed from the normal sreset handler in the next
patch.
The save_1 == 0 condition is no longer required to signal a fast
reboot.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the redzone to the interrupt stack, and code to restore
registers.
This can be used for a number of things. Initially it will be used
to recover from system reset interrupts, it could later be used to
handle recoverable machine checks, use the decrementer to implement
a watchdog, handle HMI interrupts at boot, and to implement virtual
memory.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Secondary CPUs currently run with MSR[ME]=0 during boot, whih means
if they take a machine check, the system will checkstop.
Enable ME where possible and allow them to print registers.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Improve sreset and MCE handling in fast reboot. Switch the HILE bit
off before copying OPAL's exception vectors, so NMIs can be handled
properly. Also disable MSR[ME] while the vectors are being overwritten.
Some of the remaining problem cases are documented in comments.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Take secondaries out of sleep mode as late as possible, which tends to
help with simulator boot speeds. Make give_self_os() the last step
before starting the kernel, which matches the way secondaries behave.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Save and print the MSR of the interrupt context. This can be derived
from the interrupt type, SRR1, and other system register settings. But
it can be useful to quickly verify what's happening.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
| |
The added nops now push it up in size, and -Os uninlines it for every
compilation unit that calls it more than once, so it's much better to
just uninline.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
Use the word copy, to match copy_exception_vectors.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the per-core HID register is updated concurrently by multiple
threads, updates can get lost. This has been observed during fast
reboot where the HILE bit does not get cleared on all cores, which
can cause machine check exception interrupts to crash.
Fix this by only updating HID on thread0.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|