Age | Commit message (Collapse) | Author | Files | Lines |
|
[ Upstream commit c0ab7b45db3dc44daf001f61324bd1418091dede ]
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>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 968c30905d7a61d777606a5f5c7949027564efd8 ]
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>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 01f977c33d46f35ae6735c874d415a793d7bd9af ]
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>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 554062d7fe5aac2e1a65a15a0385946a1fb6f8f4 ]
Useful for debugging.
CC: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 7516e3827e5044442b9b79fa44fe118e101207c8 ]
Useful for debugging.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 3170270be92ad945600d25ced9352c39fc7f156a ]
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>
|
|
[ Upstream commit d27180b55d7740a711f2a6417eed02782a1cd536 ]
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>
|
|
[ Upstream commit 17975a6e645768c4651199055052a13858db6506 ]
Despite the major version of PVR being 1 (0x004c0100) for POWER8NVL,
these chips are functionally equalent to P8/P8E DD2 levels.
This advertises POWER8NVL as DD2. As the result, skiboot adds
ibm,powerpc-cpu-features/processor-control-facility for such CPUs and
the linux kernel can use hypervisor doorbell messages to wake secondary
threads; otherwise "KVM: CPU %d seems to be stuck" would appear because
of missing LPCR_PECEDH.
Fixes: 7f4c8e8ce0b "dt: add /cpus/ibm, powerpc-cpu-features device tree bindings"
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
[ Upstream commit 9ef153f6f013b224db8e9b78764ef6cf89c152fa ]
The loop in drop_my_locks() looks like this:
while((l = list_pop(&this_cpu()->locks_held, struct lock, list)) != NULL) {
if (warn)
prlog(PR_ERR, " %s\n", l->owner);
unlock(l);
}
Both list_pop() and unlock() call list_del(). This means that on the
last iteration of the loop, the list will be empty when we get to
unlock_check(), causing this:
LOCK ERROR: Releasing lock we don't hold depth @0x30493d20 (state: 0x0000000000000001)
[13836.000173140,0] Aborting!
CPU 0000 Backtrace:
S: 0000000031c03930 R: 000000003001d840 ._abort+0x60
S: 0000000031c039c0 R: 000000003001a0c4 .lock_error+0x64
S: 0000000031c03a50 R: 0000000030019c70 .unlock+0x54
S: 0000000031c03af0 R: 000000003001a040 .drop_my_locks+0xf4
To fix this, change list_pop() to list_top().
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If an i2c request cannot go through the first time, because the bus is
found in error and need a reset or it's locked by the OCC for example,
the underlying i2c implementation is using timers to manage the
request. However during opal init, opal pollers may not be called, it
depends in the context in which the i2c request is made. If the
pollers are not called, the timers are not checked and we can end up
with an i2c request which will not move foward and skiboot hangs.
Fix it by explicitly checking the timers if we are waiting for an i2c
request to complete and it seems to be taking a while.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Basically to shut up static analysis of using a boolean in a non-boolean
context (bitwise).
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Again, this makes things look slightly different so I don't keep seeing
the static analysis warning.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The static analysis tool is arguably wrong and should go away.
But... I'm sick of keeping coming back to it and reviewing the false
positives enough to make a slight change to where ifdefs are.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This is a dumb warning from a certain static analysis tool that a
function has no effect when the ifdef that would make it have an effect
isn't defined and we replace it with a no-op impl.
Putting the #ifdef around the call just so I don't have to discount this
damn static analysis false positive every time I go and look at the
results.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
A certain finicky static analysis tool did point out that we were
operating on a value that could be null (and since first_cpu() calls
next_cpu(NULL) to get the first one, it also gets to be complained about
as next_cpu() could act on that NULL pointer).
So, rework things to shut the static analysis tool up, when in fact this
was never a problem.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
On P8 this is called when we exit fastsleep, and we shouldn't measure
the "time" spent in the call for what (in retrospect) is an obvious
reason.
Fixes: 50ea35c2d07874755c03e6ae2bdf7a33ad2c768a
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Measure entry/exit time for OPAL calls and warn appropriately if the
calls take too long (>100ms gets us a DEBUG log, > 1000ms gets us a
warning).
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
On a plain boot, this reduces the time spent in OPAL by ~170ms on
p9dsu. This is due to hiomap (currently) using synchronous IPMI
messages.
It will also *significantly* reduce latency on runtime flash
operations, as we'll spend typically 10-20ms in OPAL rather than
100-200ms. It's not an ideal solution to that, but it's a quick
and obvious win for jitter.
Cc: stable
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Knowing the return code is at least better than not knowing the return
code.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This only bit us hard with hiomap in one scenario.
Our OPAL API has been OPAL_POLL_EVENTS may be needed to make forward
progress on ongoing operations, and the internal to skiboot API has been
that time_wait() of a suitable time will run pollers (on at least one
CPU) to help ensure forward progress can be made.
In a perfect world, interrupts are used but they may a) be disabled, or
b) the thing we're doing can't use interrupts because computers are
generally terrible.
Back in 3db397ea5892a (circa 2015), we changed skiboot so that we'd run
pollers only on the boot CPU, and not if we held any locks. This was to
reduce the chance of programming code that could deadlock, as well as to
ensure that we didn't just thrash all the cachelines for running pollers
all over a large system during boot, or hard spin on the same locks on
all secondary CPUs.
The problem arises if the OS we're booting makes an OPAL call early on,
with interrupts disabled, that requires a poller to run to make forward
progress. An example of this would be OPAL_WRITE_NVRAM early in Linux
boot (where Linux sets up the partitions it wants) - something that
occurs iff we've had to reformat NVRAM this boot (i.e. first boot or
corrupted NVRAM).
The hiomap implementation should arguably *not* rely on synchronous IPMI
messages, but this is a future improvement (as was for mbox before it).
The mbox-flash code solved this problem by spinning on check_timers().
More generically though, the approach of running the pollers when no
longer booting means we behave more in line with what the API is meant
to be, rather than have this odd case of "time_wait() for a condition
that could also be tripped by an interrupt works fine unless the OS is
up and running but hasn't set interrupts up yet".
Fixes: 529bdca0bc546a7ae3ecbd2c3134b7260072d8b0
Fixes: 3db397ea5892a8b348cf412739996731884561b3
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This reverts commit f835684365273c5ff1b7c700ddc0f9c1a859363f.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Presence detection for opencapi adapters was broken for ZZ planars v3
and below. All ZZ systems currently used in the lab have had their
planar upgraded, so we can now remove the override we had to force
presence and activate presence detection. Which should improve boot
time.
Considering the state of opal support on ZZ, this is really only for
lab usage on BML. The opencapi enablement team has okay'd the
change. In the unlikely case somebody tries opencapi on an old ZZ, the
presence detection through i2c will show that no adapter is present
and skiboot won't try to access or train the link.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Users see these when loading an OS from Petitboot:
[ 119.486794100,5] OPAL: Switch to big-endian OS
[ 120.022302604,5] OPAL: Switch to little-endian OS
Which is expected and doesn't provide any information the user can act
on. Switch them to PR_INFO so they still appear in the log, but not on
the serial console.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This was caught with unmapped memory dereference page faults.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
These were caught with unmapped memory dereference page faults.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
When stop state 5 is enabled, reading the core_fir during an HMI can
result in a xscom read error with xscom_read() returning an
OPAL_XSCOM_PARTIAL_GOOD error code and core_fir value of all FFs. At
present this return error code is not handled in decode_core_fir()
hence the invalid core_fir value is sent to the kernel where it
interprets it as a FATAL hmi causing a system check-stop.
This can be prevented by forcing the core to wake-up using before
reading the core_fir. Hence this patch wraps the call to
read_core_fir() within calls to dctl_set_special_wakeup() and
dctl_clear_special_wakeup().
Suggested-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
Acked-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Reviewed-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The Skiboot version can include a "skiboot-" prefix if built with
something like Buildroot. The property being compared against won't
include this so ignore it.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Segregate the BMC platform configuration into hardware and software
components. This allows population of platform default values for
hardware configuration that may no-longer be accessible by the host.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: fixup pci-quirk unit test]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This ensures progress when we don't have interrupts available for IPMI.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Previously in flash_register() held flash_lock across ffs_init(), which
calls through the blocklevel layer to read the flash. This is unhelpful
with the IPMI HIOMAP protocol transport as LPC interrupts have not yet
been enabled and we are relying on polling to progress. The held lock
stalls the boot as we take the nopoll path in time_wait() while
completing ipmi_queue_msg_sync() in libflash/ipmi-flash.c
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Otherwise we can get reports of core/lock.c owning the lock, which is
not helpful when tracking down ownership issues.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
bust_locks is a big hammer that guarantees a mess if it's set while
all other threads are not stopped.
I propose removing this in the lock error paths. In debugging the
previous deadlock false positive, none of the error messages printed,
and the in-memory console was totally garbled due to lack of locking.
I think it's generally better for debugging and system integrity to
keep locks held when lock errors occur. Lock busting should be used
carefully, just to allow messages to be printed out or machine to be
restarted, probably when the whole system is single-threaded.
Skiboot is slowly working toward that being feasible with co-operative
debug APIs between firmware and host, but for the time being,
difficult lock crashes are better not to corrupt everything by
busting locks.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If a lock waiter exceeds the warning timeout, it prints a message
while still registered as requesting the lock. Printing the message
can take locks, so if one is held when the owner of the original
lock tries to print a message, it will get a false positive deadlock
detection, which brings down the system.
This can easily be hit when there is a lot of HMI activity from a
KVM guest, where the timebase was not returned to host timebase
before calling the HMI handler.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently if we try to run a raw/stripped binary kernel (ie. without
the elf header) we crash with:
[ 0.008757768,5] INIT: Waiting for kernel...
[ 0.008762937,5] INIT: platform wait for kernel load failed
[ 0.008768171,5] INIT: Assuming kernel at 0x20000000
[ 0.008779241,3] INIT: ELF header not found. Assuming raw binary.
[ 0.017047348,5] INIT: Starting kernel at 0x0, fdt at 0x3044b230 14339 bytes
[ 0.017054251,0] FATAL: Kernel is zeros, can't execute!
[ 0.017059054,0] Assert fail: core/init.c:590:0
[ 0.017065371,0] Aborting!
This is because we haven't set kernel_entry correctly in this path.
This fixes it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
When primary thread receives a CORE level HMI for timer facility errors
while secondaries are still in OPAL, thread 0 ends up in rendez-vous
waiting for secondaries to get into hmi handling. This is because OPAL
runs with MSR(EE=0) and hence HMIs are delayed on secondary threads until
they are given to Linux OS. Fix this by adding a check for secondary
state and force them in hmi handling by queuing job on secondary threads.
I have tested this by injecting HDEC parity error very early during Linux
kernel boot. Recovery works fine for non-TB errors. But if TB is bad at
this very eary stage we already doomed.
Without this patch we see:
[ 285.046347408,7] OPAL: Start CPU 0x0843 (PIR 0x0843) -> 0x000000000000a83c
[ 285.051160609,7] OPAL: Start CPU 0x0844 (PIR 0x0844) -> 0x000000000000a83c
[ 285.055359021,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 285.055361439,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:0: TFMR(2e12002870e14000) Timer Facility Error
[ 286.232183823,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc1)
[ 287.409002056,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc1)
[ 289.073820164,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc1)
[ 290.250638683,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc2)
[ 291.427456821,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc2)
[ 293.092274807,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc2)
[ 294.269092904,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc3)
[ 295.445910944,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc3)
[ 297.110728970,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc3)
After this patch:
[ 259.401719351,7] OPAL: Start CPU 0x0841 (PIR 0x0841) -> 0x000000000000a83c
[ 259.406259572,7] OPAL: Start CPU 0x0842 (PIR 0x0842) -> 0x000000000000a83c
[ 259.410615534,7] OPAL: Start CPU 0x0843 (PIR 0x0843) -> 0x000000000000a83c
[ 259.415444519,7] OPAL: Start CPU 0x0844 (PIR 0x0844) -> 0x000000000000a83c
[ 259.419641401,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419644124,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:0: TFMR(2e12002870e04000) Timer Facility Error
[ 259.419650678,7] HMI: Sending hmi job to thread 1
[ 259.419652744,7] HMI: Sending hmi job to thread 2
[ 259.419653051,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419654725,7] HMI: Sending hmi job to thread 3
[ 259.419654916,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419658025,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419658406,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:2: TFMR(2e12002870e04000) Timer Facility Error
[ 259.419663095,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:3: TFMR(2e12002870e04000) Timer Facility Error
[ 259.419655234,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:1: TFMR(2e12002870e04000) Timer Facility Error
[ 259.425109779,7] OPAL: Start CPU 0x0845 (PIR 0x0845) -> 0x000000000000a83c
[ 259.429870681,7] OPAL: Start CPU 0x0846 (PIR 0x0846) -> 0x000000000000a83c
[ 259.434549250,7] OPAL: Start CPU 0x0847 (PIR 0x0847) -> 0x000000000000a83c
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This takes a checksum of skiboot memory after boot that should be
unchanged during OS operation, and verifies it before allowing a
fast reboot.
This is not read-only memory from skiboot's point of view, beause
it includes things like the opal branch table that gets populated
during boot.
This helps to improve the integrity of firmware against host and
runtime firmware memory scribble bugs.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This also tidies up linker script symbol declarations and adds
_rodata_mem symbol for the next change to use.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Mambo image payloads get overwritten by the OS and by
fast reboot memory clearing because they have no region
defined. Add them, which allows fast reboot to work.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[stewart: fix up 'make check']
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Once things start to go wrong, disable_fast_reboot can be called a
number of times, so make the first reason sticky, and also print it
to the console at disable time. This helps with making sense of
fast reboot disables.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
I missed a hunk when merging :(
Reported-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Fixes: 7c8e1c6f89f3aac77661cfcee75ab515bd053d75
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
this means that if it's permanently disabled on boot, the test suite can
pick that up and not try a fast reboot test.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We print a message when nvram_query() needs to wait for the NVRAM to
be loaded from the BMC/FSP. Currently this is printed at PR_WARNING
which is excessive since this doesn't actually indicate that anything is
wrong. There's also nothing that we can really do about loading the
NVRAM being slow, so just print this at PR_DEBUG.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Print how long we had to wait for NVRAM to become available if we needed
to wait.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|