>-----Original Message-----
>From: Song, Barry 
>Sent: Friday, November 27, 2009 5:42 PM
>To: 'Mike Frysinger'; [email protected]
>Cc: [email protected]
>Subject: RE: [Linux-kernel-commits] [7887] 
>trunk/arch/blackfin/kernel/traps.c: bug [#5662], workaround 
>ANOMALY_05000310
>
>
>
>>-----Original Message-----
>>From: Mike Frysinger [mailto:[email protected]] 
>>Sent: Friday, November 27, 2009 5:28 PM
>>To: [email protected]
>>Cc: [email protected]
>>Subject: Re: [Linux-kernel-commits] [7887] 
>>trunk/arch/blackfin/kernel/traps.c: bug [#5662], workaround 
>>ANOMALY_05000310
>>
>>On Fri, Nov 27, 2009 at 04:18,  <[email protected]> wrote:
>>> --- trunk/arch/blackfin/kernel/traps.c      2009-11-27 
>>07:32:25 UTC (rev 7886)
>>> +++ trunk/arch/blackfin/kernel/traps.c      2009-11-27 
>>09:18:21 UTC (rev 7887)
>>> @@ -524,6 +524,12 @@
>>>                     break;
>>>             /* External Memory Addressing Error */
>>>             case (SEQSTAT_HWERRCAUSE_EXTERN_ADDR):
>>> +                   if (ANOMALY_05000310) {
>>> +                           unsigned int erraddr = fp->pc;
>>> +                           if ((erraddr >= (L1_CODE_START 
>>+ L1_CODE_LENGTH - 512)) &&
>>> +                                           (erraddr < 
>>(L1_CODE_START + L1_CODE_LENGTH)))
>>> +                                   goto traps_done;
>>> +                   }
>>
>>addresses should always be "unsigned long".  there should also be a
>Ok
>>short comment explaining things so people dont have to lookup the
>>anomaly sheet for a quick summary.  also note that while the check
>ok
>>isnt exact (since system notifications can never be exact wrt the
>>pipeline), it should be realistically close enough.
>>
>>since you've managed to reproduce the issue with L1, why not add the
>>external memory check as well ?
>We don't need to check external memory. 
>1. revsered memory behind physical memory has no valid cplb 
>entry to cover in my kernel setting, it can't trigger anomaly.

Sorry for the typo: my->our

>2. even after I give a valid cplb entry covering 0x04000000 
>forcely, the anomaly doesn't happen too. So I suspect the 
>description is not exact.
>
>>-mike
>>
>
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits

Reply via email to