On 1 June 2015 at 19:58, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> I think these kernels are missing the configuration for l3-noc
> driver?
Yup. Since I'm pretty sure I have all the necessary info I was hoping
look into that... somewhere in my copious spare time...
> I tried it on omap4 that has l3-noc configured, and it first produces
> "Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd7000",
(Though making a patch to fix that annoyingly wrong and useless
message is higher on my list of priorities)
> and the L3 interrupt only after that. So yeah, you're right, we can't
> use the interrupts here. I somehow remembered we'd get only the L3
> interrupt if configured.
The bus error is not influenced by L3 error reporting config afaik,
and it will always win from the irq: even though the irq is almost
certainly asserted first, it can't be taken until the load/store
instruction completes, and then the fault will take precedence.
While implementing L3 error reporting in my forth system I ran into a
tricky scenario though: it turns out that if an irq occurs while the
cpu is waiting for instruction fetch, it does allow the irq to be
taken. The interrupted fetch is abandoned and any bus error it may
have produced is ignored since exception entry/exit is an implicit
instruction sync barrier. On return it is simply refetched...
Hence, the result from attempting to execute code from an invalid address:
fetching from [invalid]
irq entry (LR=[invalid])
L3 error displayed
irq exit
fetching from [invalid]
irq entry (LR=[invalid])
L3 error displayed
irq exit
fetching from [invalid]
...
(repeat until watchdog expires)
Anyhow, so we still have the puzzling fact that apparently neither of
us was expecting device memory to use a strongly-ordered mapping,
getting a bus error on a write (outside MPUSS itself) shows that it
does.
I've tried to read arch/arm/mm/mmu.c to find out why, but so far I'm
feeling hopelessly lost there... (the multitude of ARM architecture
versions/flavors supported aren't helping.)
--
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
