[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] ACPI, APEI: Add apei_exec_run_optional

>>> On 22.03.13 at 12:27, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/03/13 09:14, Jan Beulich wrote:
>>>>> On 22.03.13 at 10:07, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>> All we appear to be missing in this case is Linux commit
>>> eecf2f7124834dd1cad21807526a8ea031ba8217. I'll get that
>>> ported over...
>> ACPI, APEI: Add apei_exec_run_optional
>> Some actions in APEI ERST and EINJ tables are optional, for example,
>> ACPI_EINJ_BEGIN_OPERATION action is used to do some preparation for
>> error injection, and firmware may choose to do nothing here.  While
>> some other actions are mandatory, for example, firmware must provide
>> ACPI_EINJ_GET_ERROR_TYPE implementation.
>> Original implementation treats all actions as optional (that is, can
>> have no instructions), that may cause issue if firmware does not
>> provide some mandatory actions.  To fix this, this patch adds
>> apei_exec_run_optional, which should be used for optional actions.
>> The original apei_exec_run should be used for mandatory actions.
>> Signed-off-by: Huang Ying <ying.huang@xxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> (Via backport to 4.2)
> For what it is worth, with the spinlock fix, I disabled the "Intel only"
> restriction, and so far I have been unable to find a problematic AMD box.

So Ian, with those two fixes in, could you retry the revert of the
Intel-only enforcement in a full ad-hoc run? If successful, that
would then also give us reasonable assurance to backport all the
APEI fixes to the stable branches.

Thanks, Jan

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.