[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181205171226.GL29510@zn.tnic>
Date: Wed, 5 Dec 2018 18:12:27 +0100
From: Borislav Petkov <bp@...en8.de>
To: Tracy Smith <tlsmith3777@...il.com>
Cc: york.sun@....com, linux-edac@...r.kernel.org,
util-linux@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: edac driver injection of uncorrected errors & utils
On Wed, Dec 05, 2018 at 10:37:52AM -0600, Tracy Smith wrote:
> This was very helpful.
I'm glad.
Can you do me a favor pls and not top-post when replying on a mailing
list?
Thx.
> Tracing through the code, it doesn't do a panic
> before Linux crashes from multi-bit errors because as York has
> indicated, this type of memory controller doesn't limit the number of
> errors.
>
> I do have a general question about single bit errors. The EDAC driver
> corrects single bit errors by doing a scrub, is this correct? The
> edac code does not do periodic scrubs, but I see scrubs when a
> correctable error is found (edac_mc_scrub_block and edac_atomic_scrub
> in edac_mc.c)?
>
> This is more directed toward York for layerscape.
Yes, this is all platform-specific as you can see that some arches
implement that atomic scrubbing thing. Also, not every driver sets
mci->scrub_mode == SCRUB_SW_SRC
in order to even do the scrubbing.
HTH.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists