[PATCH 2/2] cpc925_edac: support single-processor configurations

[Dmitry Eremin-Solenikov]

On Sun, May 22, 2011 at 12:04 AM, Segher Boessenkool
<segher at kernel.crashing.org> wrote:
>>> You should be able to see which interfaces are enabled in some CPC925
>>> register,
>>> but maybe both _are_ enabled on your system (although one is not
>>> connected),
>>> which is causing the errors?
>>
>> Hmm, I dont't think this is the case: I'm using a MapleD board with two
>> CPUs
>> connected to separate PIs. However I can slect the service processor
>> to enable only one CPU via selecting correct bootscript. In this case
>> bootscript correctly enables only APIMASK_ADI0. However as cpc925_edac
>> checks the APIEXCP itself, it sees the APIEXCP_ADI1 bit set and spills
>> regular warnings about it (see below).
>
> (no below :-) )

Sorry, here it goes:

EDAC CPC925: Processor Interface Fault
Processor Interface register dump:
EDAC CPC925: APIMASK            0xdea00000
EDAC CPC925: APIEXCP            0x20000000
EDAC DEVICE0: INTERNAL ERROR: instance 0 'block' out of range (0 >= 0)

> I think the service processor left that processor interface enabled (the
> interface itself, not the exception stuff), so the exception thing will
> signal exceptions any time the CPC925 sends snoops to that second
> processor.  This also might reduce performance.
>
> Or maybe it is normal for the exception thing to signal errors on disabled
> interfaces.

I only have U4 manual, so I can't be sure about U3H. And for U4 manual is
also unclear about ADI1 exception.

>> If you'd prefer I can add a check for APIMASK at cpc925_cpu_init() time,
>> but I think that this will be less robust.
>
> Yeah that's less robust, for sure.
>
> Just keep what you have, but add a big fat comment that you are assuming
> the processor interface id is identical to the MPIC processor id :-)

sure

> Did you test disabling physical CPU #0 as well?

No. I still don't have _that_ level of understanding of PIBS boot scripts.

-- 
With best wishes
Dmitry