[lkml]   [2013]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ARM: mm: Fix ECC mem policy printk
Hi Russell,

On 10/30/2013 04:01 PM, Russell King - ARM Linux wrote:
> 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.

ok. That's what I wanted to know.

>> 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 thought the situation is quite clear here. I am just saying
that there is a way to get it back and it is task for us to educate
our users/customers how to get ecc to work on zynq.

> 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:

It is not my situation and even not my two use cases.
I just want to make sure that if any "user" just use this without knowing
what it means that we will get that message back.
I am not saying it is good or bad. Just saying that there is a way how
to get it back. And the purpose of this second email was just check
that we can't detect that. That's it - nothing more nothing less.

> "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.

I agree with you and none is asking for this.

> 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.

I have no problem with that. I just wanted to check that there is no way
how we can detect that. Then your proposed fix is completely fine to me.


Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu -
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2013-10-30 16:21    [W:0.043 / U:4.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site