44 lines
1.7 KiB
ReStructuredText
44 lines
1.7 KiB
ReStructuredText
skiboot-5.1.1
|
|
-------------
|
|
|
|
skiboot-5.1.1 was released on August 18th, 2015.
|
|
|
|
skiboot-5.1.1 is the send stable release of 5.1, it follows skiboot-5.1.0.
|
|
|
|
Skiboot 5.1.1 contains all fixes from skiboot-5.1.0 and is a minor bugfix
|
|
release.
|
|
|
|
Changes
|
|
^^^^^^^
|
|
Over skiboot-5.1.0, we have the following changes:
|
|
|
|
- Fix detection of compiler options on ancient GCC (e.g. gcc 4.4, shipped with
|
|
RHEL6)
|
|
- ensure the GNUC version defines for GCOV are coming from target CC rather
|
|
than host CC for extract-gcov
|
|
- phb3: Continue CAPP setup even if PHB is already in CAPP mode
|
|
This fixes a critical bug in CAPI support.
|
|
|
|
CAPI requires that all faults are escalated into a fence, not a
|
|
freeze. This is done by setting bits in a number of MMIO
|
|
registers. phb3_set_capi_mode() calls phb3_init_capp_errors() to do
|
|
this. However, if the PHB is already in CAPP mode - for example in the
|
|
recovery case - phb3_set_capi_mode() will bail out early, and those
|
|
registers will not be set.
|
|
|
|
This is quite easy to verify. PCI config space access errors, for
|
|
example, normally cause a freeze. On a CAPI-mode PHB, they should
|
|
cause a fence. Say we have a CAPI card on PHB 0, and we inject a
|
|
PCI config space error: ::
|
|
|
|
echo 0x8000000000000000 > /sys/kernel/debug/powerpc/PCI0000/err_injct_inboundA;
|
|
lspci;
|
|
|
|
The first time we inject this, the PHB will fence and recover, but
|
|
won't reset the registers. Therefore, the second time we inject it,
|
|
we will incorrectly freeze, not fence.
|
|
|
|
Worse, the recovery for the resultant EEH freeze event interacts
|
|
poorly with the CAPP, triggering an EEH recovery of the PHB. The
|
|
combination of the two attempted recoveries will get the PHB into
|
|
an inoperable state.
|