linux kernel - Occasional fault seen on xscal arm "Unhandled fault: imprecise external abort (0x416) at 0x40019004" -

we have prodcution software running on feild , has ixp23xx netowrk processor xscale arm core running linux 2.6.24. have seen occasional problem feild , reproduced in lab, console prints below fault line "unhandled fault: imprecise external abort (0x416) @ 0x40019004". further digging, found have few page table entries, virtual addresses not mapped valid physical address. access virtual addresses can cause impricise aborts. final solution remove wrong mapping , next time should segmentation fault precise , easy catch. removing wrong entries take time , have create build debugging information option later time.

coming question, per xscale data sheet, fault can made precise(+3 instr) "stall untill complete" setting xbit = 0, c bit= 0 , b bit=0. not sure how in linux , going ? looks disable dcache. code under arc/arm/mm/proc-xscale.s assembly , not sure how disable. there 1 option in kernel config i.e. config_cpu_dcache_disable , seems disable dcache same x=c=b bits equal 0? below excerpt data sheet

*

imprecise data aborts may create scenarios difficult abort handler recover. both external data aborts , data cache parity errors may result in corrupted targeted register data. because these faults imprecise, possible corrupted data have been used before data abort fault handler invoked. because of this, software should treat imprecise data aborts unrecoverable.even memory accesses marked “stall until complete” (see section 3.2.2.4) can result in imprecise data aborts. these types of accesses, fault less imprecise general case: guaranteed raised within 3 instructions of instruction caused it. in other words, if “stall until complete” ld or st instruction triggers imprecise fault, fault seen program within 3 instructions. if mmu disabled data accesses non-cacheable , non-bufferable. same behavior when mmu enabled, , data access uses descriptor x, c, , b set 0. x, c, , b bits determine when processor should place new data data cache. cache places data cache in lines (also called blocks). thus, basis making decision placing new data cache called “line allocation policy”. if line allocation policy read-allocate, load operations miss cache

*

the strongarm , xscale custom cpus intel. seem have odd issues versus other arm processors.

$ git checkout v2.6.24.7  # activate time machine. $ grep -b1 -a 9 cpu_xsc3 kconfig  # xscale core version 3 config cpu_xsc3         bool         depends on arch_ixp23xx || arch_iop13xx || pxa3xx         default y         select cpu_32v5         select cpu_abrt_ev5t         select cpu_cache_vivt         select cpu_cp15_mmu         select cpu_tlb_v4wbi if mmu         select io_36 

the relevant kconfig cpu_abrt_ev5t , cpu_tlb_v4wbi, selects abort-ev5t.s , tlb-v4wbi.s gets stuff interested in.

function: v5t_early_abort

 * purpose : obtain information current aborted instruction.  * note: read user space.  means might cause data  * abort here if i-tlb , d-tlb aren't seeing same  * picture.  unfortunately, happen.  live it. 

i believe cpus don't have separate i-tlb , d-tlb. code trying emulate fault status reading , decoding instructions faulted. i-tlb (instruction mmu page cache) , d-tlb (data mmu page cache) may not agree , reading of instruction memory may odd.

are person living it? ie, know if ixp23xx xscale3 (xsc3) has separate i/d translation aside buffer (tlbs)?

the other oddity io_36. cpu has 36-bit addresses. see domain.h source. appears domain becomes part of address. maybe causing weird effect couldn't find cursory look.

sorry, haven't answered question. long comment.

coming question, per xscale data sheet, fault can made precise(+3 instr) "stall until complete" setting xbit = 0, c bit= 0 , b bit=0. ... there 1 option in kernel config i.e. config_cpu_dcache_disable

config_cpu_dcache_disable not fix issue. i-cache , write buffering still active. well, system extremely slow. kernel command line option cachepolicy can used instead. supports, uncached, buffered, writethrough, writeback, , writealloc. values might not applicable platform. think cachepolicy=uncached might equivalent compiling config_cpu_dcache_disable.