On Fri, Dec 21, 2018 at 06:52:20PM +, James Morse wrote:
> Do we need to ghes_ack_error() too?
That's GHES v2 AFAICT.
> With the location cleared the new kernel will never find the records, and
> firmware can never re-use that location because it wasn't ack'd. The upshot is
> RAS records can'
On 21/12/2018 11:17, Rafael J. Wysocki wrote:
> On Thursday, December 20, 2018 8:24:47 PM CET Borislav Petkov wrote:
>> + James.
Thanks,
>> On Wed, Dec 19, 2018 at 11:50:52AM -0500, David Arcari wrote:
>>> From: Lenny Szubowicz
>>>
>>> In __ghes_panic() clear the block status in the APEI generic
On Thursday, December 20, 2018 8:24:47 PM CET Borislav Petkov wrote:
> + James.
>
> On Wed, Dec 19, 2018 at 11:50:52AM -0500, David Arcari wrote:
> > From: Lenny Szubowicz
> >
> > In __ghes_panic() clear the block status in the APEI generic
> > error status block for that generic hardware error
+ James.
On Wed, Dec 19, 2018 at 11:50:52AM -0500, David Arcari wrote:
> From: Lenny Szubowicz
>
> In __ghes_panic() clear the block status in the APEI generic
> error status block for that generic hardware error source before
> calling panic() to prevent a second panic() in the crash kernel
> f
On Wed, Dec 19, 2018 at 1:33 PM David Arcari wrote:
>
> From: Lenny Szubowicz
>
> In __ghes_panic() clear the block status in the APEI generic
> error status block for that generic hardware error source before
> calling panic() to prevent a second panic() in the crash kernel
> for exactly the sam
From: Lenny Szubowicz
In __ghes_panic() clear the block status in the APEI generic
error status block for that generic hardware error source before
calling panic() to prevent a second panic() in the crash kernel
for exactly the same fatal error.
Otherwise ghes_probe(), running in the crash kerne
6 matches
Mail list logo