From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mm: Fix ECC mem policy printk
Date: Wed, 30 Oct 2013 15:01:06 +0000 [thread overview]
Message-ID: <20131030150106.GC16735@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <52711869.60703@monstr.eu>
On Wed, Oct 30, 2013 at 03:32:09PM +0100, Michal Simek wrote:
> btw: passing ecc=on through command line will caused that "ECC enabled"
> message will be there even on systems which don't implement this bit.
> It is just side effect for both these solutions.
It is a hint, nothing more. There is no way to detect whether it's
implemented or even how it has been implemented.
> Isn't there any easy way to test if this bit is implemented or not just
> by setting it up and clear it?
So... let's summerise the message that you're giving.
"My SoC doesn't implement this bit other than to provide ECC at the L1
cache, instead implementing a separate ECC scheme for system memory.
Therefore, I want to change it to describe my implementation, because
my customers are complaining that it says ECC is disabled when that
is not the case. If it can't describe my setup, I want to remove the
whole facility."
That's a very selfish attitude. Sorry, but it would be wrong of me
to allow your situation to change what we have beyond the proposed
patch.
I've shown you the ARM architecture reference manual where this bit in
the page tables is described, both older and newer versions. What we're
doing is in the spirit of the descriptions of bit 9 in the L1 page tables.
I don't think there's any sensible short description which would
adequately describe this setting which would satisfy both your situation
and situations on other SoCs. We could make the kernel print an entire
paragraph on it, something like:
"ECC might be %sabled. The exact ECC setting depends on how your SoC
is implemented. Please refer to your SoCs technical reference manual
for a description of bit 9 in the level one page tables for further
information on how to interpret this statement."
but that would be idiotic.
Of course, we could just print nothing, but the purpose of printing this
is so that _we_ as developers looking at the kernel messages know the
status of this bit, particularly when interpreting oops dumps. Hiding
this information would make some oops dumps harder to diagnose. So...
this is a matter for user education if your users are complaining about
it.
next prev parent reply other threads:[~2013-10-30 15:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-30 12:46 [PATCH] ARM: mm: Fix ECC mem policy printk Michal Simek
2013-10-30 13:07 ` Russell King - ARM Linux
2013-10-30 14:23 ` Michal Simek
2013-10-30 14:32 ` Michal Simek
2013-10-30 15:01 ` Russell King - ARM Linux [this message]
2013-10-30 15:14 ` Michal Simek
-- strict thread matches above, loose matches on Subject: below --
2013-10-10 10:12 Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131030150106.GC16735@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).