Age | Commit message (Collapse) | Author | Files | Lines |
|
There are a number of proc_gen branches removed that are trivially
dead code and comments that refer to P7. As well as those:
- Oliver points out that add_xics_icps() must be unused on POWER8
because it asserts if number of threads > 4, so remove it.
- Change 16b7ae641 ("Remove POWER7 and POWER7+ support") removed all
references to opal_boot_trampoline, so remove that.
- It also removed the only non-trival choose_bus implementation, so
that is removed and its caller simplified.
- Remove the paca code, later CPUs use pcia.
Cc: Stewart Smith <stewart@flamingspork.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently we apply a hack to devices directly under a PHB which sets
the class code shown in the DT to that of a generic PCI-PCI bridge.
This is done to work around a bug in some IBM PHBs where the root port
had an incorrect class code. This has the side effect of forcing the
class code of any devices on a root bus to that of a PCI-PCI bridge
including NVLink and OpenCAPI devices which causes them to be mis-labed
in the Skiboot PCI Summary.
Fix this by only appling the hack to PCIe devices that are marked as
root ports and add a description string for the 0680 class code that
we use for nvlink device.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently when the Function Number bits of a BDF are needed the bit
operations to get it are free coded. There are many places where the
Function Number is used, so make a macro to use instead of free coding
it everytime.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently when the Device Number bits of a BDF are needed the bit
operations to get it are free coded. There are many places where the
Device Number is used, so make a macro to use instead of free coding it
everytime.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently when the Bus Number bits of a BDF are needed the bit
operations to get it are free coded. There are many places where the
Bus Number is used, so make a macro to use instead of free coding it
everytime.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
We'd like to be able to check when we get a freeze in the quirk handling
code. Make pci_check_clear_freeze un-static so it can be used elsewhere.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-By: Alistair Popple <alistair@popple.id.au>
|
|
Use Software Package Data Exchange (SPDX) to indicate license for each
file that is unique to skiboot.
At the same time, ensure the (C) who and years are correct.
See https://spdx.org/
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: Added a few missing files]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This feature was added a few years ago in response to a request to make
the MaxPayloadSize (MPS) field of a Virtual Function match the MPS of the
Physical Function that hosts it.
The SR-IOV specification states the the MPS field of the VF is "ResvP".
This indicates the VF will use whatever MPS is configured on the PF and
that the field should be treated as a reserved field in the config space
of the VF. In other words, a SR-IOV spec compliant VF should always return
zero in the MPS field. Adding hacks in OPAL to make it non-zero is...
misguided at best.
Additionally, there is a bug in the way pci_device structures are handled
by VFs that results in a crash on fast-reboot that occurs if VFs are
enabled and then disabled prior to rebooting. This patch fixes the bug by
removing the code entirely. This patch has no impact on SR-IOV support on
the host operating system.
Cc: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
Cc: skiboot-stable@lists.ozlabs.org
Tested-by: Santwana Samantray <santwana.samantray@in.ibm.com>
Tested-by: Satheesh Rajendran <satheera@in.ibm.com>
[oliver: added tested-bys]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
We keep the existing logic of looking to the parent for the slot-label or
slot-location-code, but we add logic to (if all that fails) we look
directly for the slot-location-code (as this should give us the correct
loc code for things directly under the PHB), and otherwise we just look
for a loc-code.
The applicable bit of PAPR here is:
R1–12.1–1. Each instance of a hardware entity (FRU) has a platform
unique location code and any node in the OF
device tree that describes a part of a hardware entity must include the
“ibm,loc-code” property with a
value that represents the location code for that hardware entity.
which we weren't really fully obeying at any recent (ever?) point in
time. Now we should do okay, at least for PCI.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
On witherspoon only the GPU slots and the three pluggable PCI slots
(SLOT0, 1, 2) have platform defined slot names. For builtin devices such
as the SATA controller or the PLX switch that fans out to the GPU slots
we have no location codes which some people consider an issue.
This patch address the problem by making the ibm,slot-location-code for
the root port device default to the ibm,io-base-location-code which is
typically the location code for the system itself.
e.g.
pciex@600c3c0100000/ibm,loc-code
"UOPWR.0000000-Node0-Proc0"
pciex@600c3c0100000/pci@0/ibm,loc-code
"UOPWR.0000000-Node0-Proc0"
pciex@600c3c0100000/pci@0/usb-xhci@0/ibm,loc-code
"UOPWR.0000000-Node0"
The PHB node, and the root complex nodes have a loc code of the
processor they are attached to, while the usb-xhci device under the
root port has a location code of the system itself.
Signed-off-by: Oliver O'Halloran <oohall@gmail.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>
|
|
We call all of these things recursively, so don't use excess stack.
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>
|
|
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>
|
|
Move the PCI{TRACE,DBG,NOTICE,ERR} logging macros from pci.c to pci.h so
they can be used in other files.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The actual entries of the PCI Summary are printed at PR_NOTICE so that
they go to the console during boot. The header however does not which
breaks my patented "grep 'PCI Summary' -A 100" technique for scraping
the summary out of a log file when that log is recorded from the SOL
console.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently pci_scan_bus() unconditionally calls pci_slot_set_power_state()
when it's finished scanning a bus. This is one of those things that
makes you go "WHAT?" when you first see it and frankly the skiboot PCI
code could do with less of that.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently we restore PCIe bus numbers right after the link is
up. Unfortunately as this point we haven't done CRS so config space
may not be accessible.
This moves the bus number restore till after CRS has happened.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The PCIe slot capability can be implemented in a root or switch
downstream port to set the maximum power a card is allowed to draw
from the system. This patch adds support for setting the power limit
when the platform has defined one.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Document the bridge class code hack and what ibm,pci-config-space-type
actually means. Also replace some of the pci_cap() calls with a variable
to make it a bit more readable.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If a link doesn't train, we can end up with error messages like this:
[ 63.027261959,3] PHB#0032[8:2]: LINK: Timeout waiting for electrical link
[ 63.027265573,3] PHB#0032:00:00.0 Error -6 resetting
The first message is useful but the second message is just debug from
the core PCI code and is confusing to print to the console.
This reduces the second print to debug level so it's not seen by the
console by default.
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>
|
|
Scan the OpenCAPI links under the NPU, and for each link, reset the card,
set up a device, train the link and register a PHB.
Implement the necessary operations for the OpenCAPI PHB type.
For bringup, test and debug purposes, we allow an NVRAM setting,
"opencapi-link-training" that can be set to either disable link training
completely or to use the prbs31 test pattern.
To disable link training:
nvram -p ibm,skiboot --update-config opencapi-link-training=none
To use prbs31:
nvram -p ibm,skiboot --update-config opencapi-link-training=prbs31
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In this patch, we added a creset to the fast reboot path:
commit a1eba9d29d17ff44fca1293b071023a9fbf4b938
Author: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
fast-reboot: creset PHBs on fast reboot
Unfortunately, this does the creset in serial rather than in
parallel.
This patch changes the creset on fast reboot to operate in
parallel. It simplifies the code by abstracting pci_init_slots() so
that it can be used on boot and fast reboot to perform all the PCI
retraining.
This improves fast reboot PCI training on a dual chip P9 from ~12
seconds down to ~2 seconds. Similar improvements for P8 are achieved
as well.
This means the time to download the BOOTKERNEL is the bottleneck for
fast reboot.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This just moves some functions around. A future patch will reuse some
of these in different locations, so the order needs to change.
No code or functional changes
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
pci_reset() currently does a platform reboot if it fails. It
should not know about fast-reboot at this level, so instead have
it return an error, and the fast reboot caller will do the
platform reboot.
The code essentially does the same thing, but flexibility is
improved. Ideally the fast reboot code should perform pci_reset
and all such fail-able operations before the CPU resets itself
and destroys its own stack. That's not the case now, but that
should be the goal.
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>
|
|
pci_set_cap needs a callback to free data and we need to call
that when we're doing __pci_reset()
We also need to free pcrf entries.
In the future, __pci_reset() and pci_remove_bus() need to come
together to be one canonical place on how to free a PCI device
rather than the two we have now. This patch *purely* focuses
on the problem of not leaking memory across fast-reboot.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We are going need pci_wait_crs() in the PHB4 code so make it global.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When a complete reset occurs, after the PHB recovers it propagates a
reset down the wire to every device. At the same time, skiboot talks to
every device in order to restore the state of devices to what they were
before the reset.
In some situations, such as devices that recovered slowly and/or were
behind a switch, skiboot attempted to access config space of the device
before the link was up and the device could respond.
Fix this by retrying CRS until the device responds correctly, and for
devices behind a switch, making sure the switch has its link up first.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Tested-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This can be checked from config space, but we will need to know this when
restoring the PCI topology, and it is not always safe to access config
space during this period.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fast-reboot has a memory leak which causes the system to crash after about
250 fast-reboots. The patch fixes the memory leak.
The cause of the leak was the pci_device's being freed, without freeing
the pci_slot within it.
Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
PCI link training is responsible for a huge chunk of the skiboot boot
time, so add the ability to trace it waiting in the main state
machine.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently during boot there a long delay while we wait for the PHBs to
be reset and train. During this time, there is no output from skiboot
and the last message doesn't give an indication of what's happening.
This boosts the PHB reset message from info to notice so users can see
what's happening during this long period of waiting.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
90% of what we print isn't useful to a normal user. This
dramatically reduces the amount of messages printed by
OPAL in normal circumstances.
We still need to add a way to bump the log level at boot
based on a BMC scratch register or some HDAT property.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The current implmentation has incorrect assumptions: there is
always a PCI slot associated with root port and PCIe switch
downstream port and all of them are capable to change its
power state by register PCICAP_EXP_SLOTCTL. Firstly, there
might not a PCI slot associated with the root port or PCIe
switch downstream port. Secondly, the power isn't controlled
by standard config register (PCICAP_EXP_SLOTCTL). There are
I2C slave devices used to control the power states on Tuleta.
In order to use the PCI slot's methods to manage the power
states, this does:
* Introduce PCI_SLOT_FLAG_ENFORCE, indicates the request operation
is enforced to be applied.
* pci_enable_bridge() is split into 3 functions: pci_bridge_power_on()
to power it on; pci_enable_bridge() as a place holder and
pci_bridge_wait_link() to wait the downstream link to come up.
* In pci_bridge_power_on(), the PCI slot's specific power management
methods are used if there is a PCI slot associated with the PCIe
switch downstream port or root port.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The device type should be fixed to downstream port when it seats
behinds behind a upstream port, which is connected to root port
directly and its VDID is 0x874810b5.
This reorders the conditions to make it a bit obvious: parent,
parent's device type, device's VDID and device type in sequence.
No logicial changes.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This uses macro as PCI config register (vendor ID) offset because
it's more indicative.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The PCI device vendor/device IDs have been cached to pd->vdid, no
need to pass them in pci_handle_quirk(). This also introduces two
macros to extract vendor/device fields and they are useful afterwards.
No logical changes introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Witherspoon systems come with a 'shared' PCI slot: physically, it
looks like a x16 slot, but it's actually two x8 slots connected to two
PHBs of two different chips. Taking advantage of it requires some
logic on the PCI adapter. Only the Mellanox CX5 adapter is known to
support it at the time of this writing.
This patch enables support for the shared slot on witherspoon if a x16
adapter is detected. Each x8 slot has a presence bit, so both bits
need to be set for the activation to take place. Slot sharing is
activated through a gpio.
Note that there's no easy way to be sure that the card is indeed a
shared-slot compatible PCI adapter and not a normal x16 card. Plugging
a normal x16 adapter on the shared slot should be avoided on
witherspoon, as the link won't train on the second slot, resulting in
a timeout and a longer boot time. Only the first slot is usable and
the x16 adapter will end up using only half the lines.
If the PCI card plugged on the physical slot is only x8 (or less),
then the presence bit of the second slot is not set, so this patch
does nothing. The x8 (or less) adapter should work like on any other
physical slot.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: re-org code, move into platform file]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Otherwise, in simulators such as Mambo, we needlessly wait 20ms, which
takes much longer than 20ms to do, because simulator.
Fixes: 41b14f9452c25f3dd74a8304763a3cc58bff019f
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
As the PHB presence logic has a debounce timer that can take
a while to settle.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
As current revisions of PHB4 don't properly handle the resulting
L1 link transition.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Move phb3_pcicfg_filter() to pci.c, rename it to pci_handle_cfg_filters()
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This avoids doing a search through the list of all devices on
every config space access to every device under a PHB.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This renames the "poll" op to "run_sm" (short for run state machine).
I think this is a better name since the function does a bunch of
things like reseting the slot. Also it avoids confusion with the
"poll_link" op which does something different (and can even be called
from run_sm).
No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If a downstream PCIe link is down we currently reserve a number of
busses for hot pluggable devices. However we do not need to do this
when we know a slot is not hotplug capable.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds another PHB callback (device_remove()), corresponding to
device_init(). With it, the PHB3 layer can receive notification
upon PCI topology changes. This functionality will be used by the
subsequent patches.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The NVMe adapter in below PCI topology is lost. The root cause is
the presence bit on its PCI slot is missed, but the PCIe link has
been up. The PCI core doesn't probe the adapter behind the slot,
leading to lost NVMe adapter in the particular case.
PHB3 root port
PLX switch 8748 (10b5:8748)
PLX swich 9733 (10b5:9733)
PMC 8546 swtich (11f8:8546)
NVMe adapter (1c58:0023)
This fixes the issue by overriding the PCI slot presence bit with
PCIe link state bit.
Reported-by: Mark E Schreiter <markes@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Mark E Schreiter <markes@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
On fast reboot, perform a creset of all PHBs. This ensures that any PHBs
that are fenced will be working after the reboot.
A later patch will disable CAPI mode during cresets - as such, PHBs in CAPI
mode will return to regular PCIe mode during a fast reboot.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|