On 18 February 2015 at 22:14, Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > Can you help us with above problem? How to catch external abort > on non-linefetch in kernel driver and prevent kernel panic? Actually it's a synchronous bus error that you want to catch, which however is misreported by linux as "external abort on non-linefetch" (... but a bus error on a linefetch would produce exactly the same error). Also, ARM apparently uses the term "external abort" as umbrella term for aborts triggered outside the MMU, which includes not just bus errors but also (uncorrectable) parity/ECC errors. Anyhow, the core question you mean to ask is: can the "exception" mechanism current already in place to trap MMU faults in e.g. put_user() easily be extended to allow drivers to trap synchronous bus errors? My impression is that this would in fact be quite easy and I even outlined a suggested patch, but I'm still a kernel newbie so I may be way off course. Although its main use would be for auto-probing, it's maybe worth mentioning I've met at least one peripheral which also reports bus errors when writing inappropriate/unsupported *values* to a register. (Of course when using posted writes you won't get an abort anyhow in that case, it's only reported via interconnect error logs.) On 19 February 2015 at 19:20, Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch In mainline linux the same fix-up is done at runtime rather than compile time (in exceptions_init() at the bottom of fault.c). Either way, in my post of the 11th I also mentioned that it looks wrong to me. I-cache maintenance fault is really a special case in the fault decoding logic since it means "although you got here via DAbort and the relevant address is in DFAR, the exception happened on the instruction side so you need to fetch the fault status from IFSR instead." -- 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
