On 1 June 2015 at 22:52, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > OK that must be the case I've seen then. Probably that happens > when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and obviously doesn't apply to device memory. Another case where the L3 error irq may be taken first is if the bus error is asynchronous, but I don't think this combo can be produced on a dm81xx or am335x, but that's mainly due to the strictly in-order Cortex-A8 making almost every abort synchronous. I'd expect async aborts are more common on an A9. > Hmm well it should be just MT_DEVICE for anything Linux ioremaps.. Yikes, so both /dev/mem and uio are behaving unlike any device driver: both use remap_pfn_range() after running the vm_page_prot though pgprot_noncached() to set the memory type to L_PTE_MT_UNCACHED, which counterintuitively turns out to mean strongly-ordered. o.O Especially uio is acting inappropriate here imho. But this is problematic... these ranges are already mapped by the kernel, and ARM explicitly forbids mapping the same physical range twice with different memory attributes (and it's not the only architecture to do so). Hmmz... Anyhow, drifting a bit off-topic here. I'm going to some more reading and thinking about this. -- 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
