1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
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.
|