On Mon, Aug 27, 2012 at 03:12:07PM -0700, Shilimkar, Santosh wrote:
> On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen <aaro.koskinen@xxxxxx> wrote:
> > Hi,
> >
> > On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
> >> > - pr_err("%s seen by %s %s at address %x\n",
> >> > + pr_err_ratelimited("%s seen by %s %s at address %x\n",
> >> > omap3_l3_code_string(code),
> >> > omap3_l3_initiator_string(initid),
> >> > multi ? "Multiple Errors" : "", address);
> >> > - WARN_ON(1);
> >> > + WARN_ON_ONCE(1);
> >> >
> >> The issue needs to be fixed instead of WARN_ON_ONCE() and then
> >> just moving ahead. Interconnect in bad states is really bad state and you
> >> won't have reliable operations post that on SOC.
> >
> > How printing megabytes of identical stack traces helps anything?
> >
> It just says repeatedly and loudly... Fix the issue :-)
>
> > This has been there always (since the L3 driver was added) on every boot
> > with N950/N9 (which BTW are HS devices, not sure if that has anything
> > to do with it). There is no apparent effect on device functionality,
> > at least nothing unusual has been observed...
> >
> I assumed this is secure device when I saw the SRAM memset is causing the
> issue.
>
> > Is there any documentation how to interpret and debug this error report?
> >
> The issue could be, there is memset tried on Secure portion of SRAM or
> CPU speculatively accessed adjacent SRAM region of public SRAM which
> is secure and hence the error.
Thanks, that makes sense.
> If you just bypass the SRAM init [1], does the issue go away ?
I tried bypassing the whole SRAM init, but the device does not seem to
boot up at all.
If I comment out the memset alone, then it boots and the issue is gone:
+#if 0
memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0,
omap_sram_size - SRAM_BOOTLOADER_SZ);
+#endif
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
