Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a workaround for a HW logic bug in Power9 where TB residue and HDEC
parity errors cleared by one thread aren't visible to other threads of same
core. The TB reside and HDEC parity error are reported through TFMR bit 45
and 26 respectively. If any of the thread from the core clears the TFMR bit
26 and 45, only thread 0 is able to see that errors are cleared but rest of
the threads 1, 2 and 3 do not see those as cleared. This causes TB error
recovery to fail for TB residue and HDEC parity errors. TFMR is per core
register and any changes made by a one thread should be visible by other
threads of the same core.
On TB residue error (TFMR bit 45), TB goes into invalid state. Hence avoid
handling/clearing TB residue error if TB is valid and running. Use TFMR bit 41
to check validity of TB state.
For HDEC parity error (TFMR bit 26), check for other errors on TFMR register
and ignore the pre-recovery for HDEC parity error. If TFMR has any other
TB error bits set alongwith HDEC parity error we can safely ignore handling
of HDEC parity error. Also, while clearing HDEC parity error bit from TFMR,
allow only thread 0 to clear it.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
On TB/HDEC errors, all 4 threads on the affected receives HMI. On power9,
every thread on the core has its own copy of TB/HDEC and hence every thread
has to clear the dirty data from its own TB/HDEC register before we clear tb
errors through TFMR[24]. The HMI recovery would fail even if one thread
do not cleanup the respective TB/HDEC register.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Freeze events such as MMIO loads can cause the PHB to lose it's
limited powerbus credits. If all credits are used and a further MMIO
will cause a checkstop.
To work around this, we escalate the troublesome freeze events to a
fence. The fence will cause a full PHB reset which resets the powerbus
credits and avoids the checkstop.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We are going to reuse this so move it earlier. No functional change
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
New inits based on next PHB4 workbook. Increases some timeouts to
avoid some spurious error conditions.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Linux EEH flow is somewhat broken. It saves the PCIe config space of
the PHB on boot, which it then uses to restore on EEH recovery. It
does this to restore MMIO bars and some other pieces.
Unfortunately this save is done before any drivers are bound to
devices under the PHB. A number of other things are configured in the
PHB after drivers start, hence some configuration space settings
aren't saved correctly. These include bus master and MMIO bits in the
command register.
Linux tried to hack around this in this linux commit
bf898ec5cb powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges
This sets the bus master bit but ignores the MMIO bit.
Hence we lose MMIO after a full PHB reset. This causes the next MMIO
access to the device to fail and for us to perform a PE freeze
recovery, which still doesn't set the MMIO bit and hence we still
fail.
This works around this by forcing MMIO on during
phb4_root_port_init().
With this we can recovery from a PHB fence event on POWER9.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Use phb4_ioda_sel() in phb4_read_phb_status() rather than re-implementing it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Log root complex accesses and print BFDN on device access
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is old unused code from phb3 so just remove it.
No functional change
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If we hit this message we'll retry and fix the problem. If we run out
of retries and can't fix the problem, we'll still print a log message
at error level indicating a problem.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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!
Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In this change:
eef0e197ab PHB4: Default to PCIe GEN3 on POWER9 DD2.00
We clamped DD2.00 parts to GEN3 but unfortunately this change also
applies to DD2.1 and above.
This fixes this to only apply to DD2.00.
This also cleans up the documentation and printing.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
'special_wakeup_count' is incremented on successfully asserting
special wakeup. So we will never clear the special wakeup if we
check 'special_wakeup_count' to be zero. Fix this issue by checking
the 'special_wakeup_count' to 1 in dctl_clear_special_wakeup().
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Some instances have been observed where the special wakeup assert
times out. The current timeout is too short for deeper sleep states.
Hostboot uses 100ms, so match that.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Use dt_find_by_name_addr() instead of dt_find_by_name(). That way we
can avoid unnecessary memory allocation/cleanup.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we traverse SLCA structure to create various FRU nodes under /vpd
node. We assumed that children are always contiguous. It happened to be
contiguous in P8 and worked fine, but failed in P9 system. So it ended up
populating duplicate node under wrong parent. Also failed to populate some
of the nodes.
Unfortunately there is no way to reach all the children of a given parent
from parent node :-( Hence we have to rework vpd creation logic.
This patch goes through all the SLCA entries serially and creates vpd node.
Assumptions:
- SLCA index is always serial (0..n)
- When we traverse serially parent entry comes before child
- Redundant resources are always consecutive
- Populate node if SLCA has 'installed' and 'VPD collected' bit set
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reverts commit 9817c9e29b6fe00daa3a0e4420e69a97c90eb373 which seems to
break setting the PCI dev flag and the link number in the PCIe vendor
specific config space. This leads to the device driver attempting to
re-init the DL when it shouldn't which can cause HMI's.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently IMC catalog carry multiple dtbs in the pnor
partition, one for each power9 major versions. And system
pvr value (pvr_type and pvr_major version) is used as
sub-id to load the right dtb from the partition. Since
minor version of pvr is not used, mask it out.
Reported-by: Shriya <shriyak@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a new CPU reinit flag, "TM Suspend Disabled", which requests that
CPUs be configured so that TM (Transactional Memory) suspend mode is
disabled.
Currently this always fails, because skiboot has no way to query the
state. A future hostboot change will add a mechanism for skiboot to
determine the status and return an appropriate error code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This updates the list of known i2c devices - as of HDAT spec v10.5e - so
that they can be properly identified during the hdat parsing.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Reviewed-by: Oliver O'Halloran <oohal@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
An i2c device is unknown if either the i2c device list is outdated or
the device is marked as unknown (0xFF) in the hdat.
This log both cases.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds __packed to the host_i2c_hdr structure since it defines an
offset that refers to the beginning of the structure.
Fixes: 41dc3eb4495c451a405974570f604622a3f829ef
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If any of the core fails to sync its TB during chipTOD initialization,
all the threads of that core are disabled. But this does not make
linux kernel to ignore the core/cpus. It crashes while bringing them up
with below backtrace:
[ 38.883898] kexec_core: Starting new kernel
cpu 0x0: Vector: 300 (Data Access) at [c0000003f277b730]
pc: c0000000001b9890: internal_create_group+0x30/0x304
lr: c0000000001b9880: internal_create_group+0x20/0x304
sp: c0000003f277b9b0
msr: 900000000280b033
dar: 40
dsisr: 40000000
current = 0xc0000003f9f41000
paca = 0xc00000000fe00000 softe: 0 irq_happened: 0x01
pid = 2572, comm = kexec
Linux version 4.13.2-openpower1 (jenkins@p89) (gcc version 6.4.0 (Buildroot 2017.08-00006-g319c6e1)) #1 SMP Wed Sep 20 05:42:11 UTC 2017
enter ? for help
[c0000003f277b9b0] c0000000008a8780 (unreliable)
[c0000003f277ba50] c00000000041c3ac topology_add_dev+0x2c/0x40
[c0000003f277ba70] c00000000006b078 cpuhp_invoke_callback+0x88/0x170
[c0000003f277bac0] c00000000006b22c cpuhp_up_callbacks+0x54/0xb8
[c0000003f277bb10] c00000000006bc68 cpu_up+0x11c/0x168
[c0000003f277bbc0] c00000000002f0e0 default_machine_kexec+0x1fc/0x274
[c0000003f277bc50] c00000000002e2d8 machine_kexec+0x50/0x58
[c0000003f277bc70] c0000000000de4e8 kernel_kexec+0x98/0xb4
[c0000003f277bce0] c00000000008b0f0 SyS_reboot+0x1c8/0x1f4
[c0000003f277be30] c00000000000b118 system_call+0x58/0x6c
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recently we added `ecid`, `wafer-id` and `wafer-location` properties
under xscom node. Lets document these properties. Also update VPD
documentation.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
IMC nest counters has both in-band (ucode access) and out of
band access to it. Since not all nest counter configurations
are supported by ucode, out of band tools are used to characterize
other configuration.
So it is prefer to pause the nest microcode at boot to aid the
nest out of band tools. If the ucode not paused and OS does not
have IMC driver support, then out to band tools will race with
ucode and end up getting undesirable values. Patch to check and
pause the ucode at boot.
OPAL provides APIs to control IMC counters. OPAL_IMC_COUNTERS_INIT
is used to initialize these counters at boot. OPAL_IMC_COUNTERS_START
and OPAL_IMC_COUNTERS_STOP API calls should be used to start and pause
these IMC engines. `doc/opal-api/opal-imc-counters.rst` details the
OPAL APIs and their usage.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
disable_unavailable_units() loops through nest_pmus array
to filter out the unsupported nest units from the imc
catalog dtb. Current code use a static macro ('MAX_NEST_UNITS')
for array limit, instead use ARRAY_SIZE. This will avoid updates
to static macro when updating the nest_pmus array.
Fixes: 712837cedca06 ('skiboot/imc: Update the nest_pmus array with occ/gpe microcode uav updates')
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The check to ensure the buddy allocation idx is aligned to its
allocation order was not taking into account the allocation split.
This would result in opal_xive_free_vp_block failures despite
giving the same value as returned by opal_xive_alloc_vp_block.
E.g., starting then stopping 4 KVM guests gives the following pattern
in the host:
opal_xive_alloc_vp_block(5)=0x45000020
opal_xive_alloc_vp_block(5)=0x45000040
opal_xive_alloc_vp_block(5)=0x45000060
opal_xive_alloc_vp_block(5)=0x45000080
opal_xive_free_vp_block(0x45000020)=-1
opal_xive_free_vp_block(0x45000040)=0
opal_xive_free_vp_block(0x45000060)=-1
opal_xive_free_vp_block(0x45000080)=0
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Reported-by: Robert Lippert <rlippert@google.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When debugging a system where Linux was taking soft lockup errors, I
noticed two CPUs were stuck in OPAL:
CPU0
lock
p8_i2c_recover
opal_handle_interrupt
CPU1
sync_timer
cancel_timer
p9_i2c_bus_owner_change
occ_p9_interrupt
xive_source_interrupt
opal_handle_interrupt
p8_i2c_recover() is a timer, and is stuck trying to take master->lock.
p9_i2c_bus_owner_change() has taken master->lock, but then is stuck waiting
for all timers to complete. We deadlock.
Fix this by using cancel_timer_async(), as suggested by Oliver.
Fixes: 201fd50f208d ("hw/p8-i2c: Fix OCC locking")
Suggested-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
(cherry picked from commit 43290f90e46d632ed5a314292c317e6f813c3b74)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Commit c8a7535f (FSP/CONSOLE: Workaround for unresponsive ipmi daemon) added
error logging when buffer is full. In some corner cases kernel may call this
function multiple time and we may endup logging error again and again.
This patch fixes it by generating error log only once. I think this is enough
to indicate something went wrong.
Also with previous patch, once console buffer is full, OPAL is returning error
to payload from fsp_console_write_buffer_space(). So payload will never call
fsp_console_write(). Hence move error logging logic to right place.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Kernel calls fsp_console_write_buffer_space() to check console buffer space
availability. If there is enough buffer space to write data, then kernel will
call fsp_console_write() to write actual data.
In some extreme corner cases (like one explained in commit c8a7535f)
console becomes full and this function returns 0 to kernel (or space available
in console buffer < next incoming data size). Kernel will continue retrying
until it gets enough space. So we will start seeing RCU stalls.
This patch keeps track of previous available space. If previous space is same
as current means not enough space in console buffer to write incoming data.
It may be due to very high console write operation and slow response from FSP
-OR- FSP has stopped processing data (ex: because of ipmi daemon died). At this
point we will start timer with timeout of SER_BUFFER_OUT_TIMEOUT (10 secs).
If situation is not improved within 10 seconds means something went bad. Lets
return OPAL_RESOURCE so that kernel can drop console write and continue.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
CC: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart: reset timeout in fsp_console_write() path]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we are not closing SOL and FW console sessions during R/R. Host will
continue to write to SOL buffer during FSP R/R. If there is heavy console write
operation happening during FSP R/R (like running `top` command inside console),
then at some point console buffer becomes full. fsp_console_write_buffer_space()
returns 0 (or less than required space to write data) to host. While one thread
is busy writing to console, if some other threads tries to write data to console
we may see RCU stalls (like below) in kernel.
kernel call trace:
------------------
[ 2082.828363] INFO: rcu_sched detected stalls on CPUs/tasks: { 32} (detected by 16, t=6002 jiffies, g=23154, c=23153, q=254769)
[ 2082.828365] Task dump for CPU 32:
[ 2082.828368] kworker/32:3 R running task 0 4637 2 0x00000884
[ 2082.828375] Workqueue: events dump_work_fn
[ 2082.828376] Call Trace:
[ 2082.828382] [c000000f1633fa00] [c00000000013b6b0] console_unlock+0x570/0x600 (unreliable)
[ 2082.828384] [c000000f1633fae0] [c00000000013ba34] vprintk_emit+0x2f4/0x5c0
[ 2082.828389] [c000000f1633fb60] [c00000000099e644] printk+0x84/0x98
[ 2082.828391] [c000000f1633fb90] [c0000000000851a8] dump_work_fn+0x238/0x250
[ 2082.828394] [c000000f1633fc60] [c0000000000ecb98] process_one_work+0x198/0x4b0
[ 2082.828396] [c000000f1633fcf0] [c0000000000ed3dc] worker_thread+0x18c/0x5a0
[ 2082.828399] [c000000f1633fd80] [c0000000000f4650] kthread+0x110/0x130
[ 2082.828403] [c000000f1633fe30] [c000000000009674] ret_from_kernel_thread+0x5c/0x68
Hence lets close SOL (and FW console) during FSP R/R.
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently OPAL sends associate/unassociate MBOX command for all
FSP serial console (like below OPAL message). We have to check
console is available or not before sending this message.
OPAL log:
-------
[ 5013.227994012,7] FSP: Reassociating HVSI console 1
[ 5013.227997540,7] FSP: Reassociating HVSI console 2
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Commit 42d5d047 fixed scenario where DPO has been initiated, but FSP went
into reset before the CEC power down came in. But this is generic issue
that can happen in normal shutdown path as well.
Hence disable PSI link as soon as we detect FSP impending R/R.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
CC: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
See 696d378d7b7295366e115e89a785640bf72a5043 for all the details.
Suggested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We had a race condition between FSP Reset/Reload and powering down
the system from the host:
Roughly:
FSP Host
--- ----
Power on
Power on
(inject EPOW)
(trigger FSP R/R)
Processes EPOW event, starts shutting down
calls OPAL_CEC_POWER_DOWN
(is still in R/R)
gets OPAL_INTERNAL_ERROR, spins in opal_poll_events
(FSP comes back)
spinning in opal_poll_events
(thinks host is running)
The call to OPAL_CEC_POWER_DOWN is only made once as the reset/reload
error path for fsp_sync_msg() is to return -1, which means we give
the OS OPAL_INTERNAL_ERROR, which is fine, except that our own API
docs give us the opportunity to return OPAL_BUSY when trying again
later may be successful, and we're ambiguous as to if you should retry
on OPAL_INTERNAL_ERROR.
For reference, the linux code looks like this:
>static void __noreturn pnv_power_off(void)
>{
> long rc = OPAL_BUSY;
>
> pnv_prepare_going_down();
>
> while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
> rc = opal_cec_power_down(0);
> if (rc == OPAL_BUSY_EVENT)
> opal_poll_events(NULL);
> else
> mdelay(10);
> }
> for (;;)
> opal_poll_events(NULL);
>}
Which means that *practically* our only option is to return OPAL_BUSY
or OPAL_BUSY_EVENT.
We choose OPAL_BUSY_EVENT for FSP systems as we do want to ensure we're
running pollers to communicate with the FSP and do the final bits of
Reset/Reload handling before we power off the system.
Additionally, we really should update our documentation to point all
of these return codes and what action an OS should take.
CC: stable
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Update pa_features_p9[] to disable TM (Transactional Memory). On DD 2.1
TM is not usable by Linux without other workarounds, so skiboot must
disable it.
The presence of TM is communicated by setting bit 7 of byte 22 in the
pa-features array. As no other bits are set in that byte, we currently
have a value of 0x80. To disable TM we set bit 7 to 0, leaving a value
of 0x0.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
..else we endup getting below calltrace in older system.
[ 169.179598388,3] HDIF: child array idx out of range!
CPU 085c Backtrace:
S: 0000000033d739b0 R: 00000000300136e8 .backtrace+0x40
S: 0000000033d73a50 R: 00000000300a1510 .HDIF_child_arr+0x34
S: 0000000033d73ac0 R: 00000000300a47a8 .io_parse+0x708
S: 0000000033d73c80 R: 000000003009f4ec .parse_hdat+0x177c
S: 0000000033d73e30 R: 0000000030014750 .main_cpu_entry+0x148
S: 0000000033d73f00 R: 0000000030002690 boot_entry+0x198
Fixes: ad484081 (hdata: Parse IOSLOT information)
CC: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
FSP sends MBOX command (cmd : 0xEB, subcmd : 0x05, mod : 0x00) to get vNVRAM
statistics. OPAL doesn't maintain any such statistics. Hence return
FSP_STATUS_INVALID_SUBCMD.
Sample OPAL log:
[16944.384670488,3] FSP: Unhandled message eb0500
[16944.474110465,3] FSP: Unhandled message eb0500
[16945.111280784,3] FSP: Unhandled message eb0500
[16945.293393485,3] FSP: Unhandled message eb0500
With this patch, I don't think FSP will ever call "free vNVRAM" MBOX command.
But to be safer side lets return FSP_STATUS_INVALID_SUBCMD for this MBOX
command as well.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
xscom_read/write operations returns CHIPLET_OFFLINE when chiplet is offline.
Some multicast xscom_read/write requests from HBRT results in xscom operation
on offline chiplet(s) and printing below warnings in OPAL console.
[ 135.036327572,3] XSCOM: Read failed, ret = -14
[ 135.092689829,3] XSCOM: Read failed, ret = -14
This results in unnecessary bugs. Hence remove error message for multicast
SCOM operations.
Suggested-by: Daniel M Crowell <dcrowell@us.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|