Thread (7 messages) flat view 7 messages, 2 authors, 2017-09-12

Re: [PATCH v1 0/4] Revisit MCE handling for UE Errors

From: Balbir Singh <bsingharora@gmail.com>
Date: 2017-09-12 07:11:42

On Tue, Sep 12, 2017 at 3:03 PM, Nicholas Piggin [off-list ref] wrote:
Hi Balbir,

Very cool. How are you testing it? Is it failing memory pages
and poisoning them out properly?
Yep, I tested it and it seems to work correctly so far. I am testing this
on a simulator with injected MCE UE errors for both the data and
instruction side.
Looks like you have a printk in the machine_check_early path,
which you shouldn't. I guess because we don't mark that context
as an NMI. Which we could... but I think you want to put as
little as possible in that path, so avoiding the print would
be preferable. Perhaps you could mark the mce event somehow that
the failure can be reported during processing it?
Good point, I did see that printk handles stuff via printk_nmi_enter/exit,
but its best avoided. Will spin v2
Firmware logging is a good question, I could not really see
where this all gets plumbed through. If this is expected to be
a common problem for some types of attached memory, then we
really need to build up a log of these errors that can be used
to exclude the memory after a reboot too. Do we have anything
like this capability in firmware?
It's to be built, we should log these to NVRAM and revisit at every
boot to isolate these pages

Balbir Singh.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help