在 xscal 臂上看到偶尔出现的故障“未处理的故障：0x40019004 处的外部中止 (0x416) 不精确”

Question

我们有生产软件在 feild 上运行，它有 ixp23xx 网络处理器和运行 linux 2.6.24 的 XSCALE arm 内核。我们从现场看到偶尔出现问题，有时在实验室中重现，控制台打印以下故障线 “未处理的故障：0x40019004 处的外部中止 (0x416) 不精确”。 进一步挖掘，我们发现我们只有很少的页表条目，其中虚拟地址没有映射到有效的物理地址。因此，访问这些虚拟地址可能会导致错误的中止。最终的解决方案是删除错误的映射，因此下次我们应该得到精确且易于捕获的分段错误。但是删除错误的条目需要一些时间，我们必须使用调试信息创建构建，因此此选项供以后使用。

回到问题，根据 XSCALE 数据表，通过设置 Xbit = 0、C 位 = 0 和 B 位 = 0，可以通过“停止直到完成”使这个故障几乎精确（+3 instr）。但我不确定如何在 linux 中准确地做到这一点，它会有帮助吗？基本上这看起来像禁用 DCACHE。 arc/arm/mm/proc-xscale.S 下的代码都是汇编代码，我不确定如何禁用。内核配置中有一个选项，即 CONFIG_CPU_DCACHE_DISABLE ，这似乎禁用了 DCACHE 但它是否与等于 0 的 X=C=B 位相同？以下是数据表的摘录

*

不精确的数据中止可能会造成难以中止的情况 处理程序恢复。外部数据中止和数据缓存奇偶校验 错误可能会导致目标寄存器数据损坏。因为这些 错误是不精确的，可能会损坏数据 在调用 Data Abort 故障处理程序之前使用。因为这， 软件应将不精确的数据中止视为不可恢复。即使 内存访问标记为“停止直到完成”（参见第 3.2.2.4 节） 可能导致不精确的数据中止。对于这些类型的访问， 错误比一般情况不那么精确：它是 保证在指令的三个指令内提出 导致它。换句话说，如果“停止直到完成” LD 或 ST 指令触发了一个不精确的错误，那么就会看到该错误 由程序在三个指令内。如果 MMU 全部禁用 数据访问将是不可缓存和不可缓冲的。这是 与启用 MMU 时相同的行为，并且数据访问使用 X、C 和 B 都设置为 0 的描述符。X、C 和 B 位 确定处理器何时应将新数据放入 Data 缓存。缓存将数据按行放入缓存中（也称为 块）。因此，决定是否放置新数据的基础 进入缓存是一个称为“线路分配策略”的策略。如果线 分配策略是读分配，所有未命中的加载操作 缓存

*

Answer 1

StrongARM 和 XScale 是 Intel 的定制 CPU。与其他 ARM 处理器相比，它们似乎存在一些奇怪的问题。

$ 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

相关的Kconfig是CPU_ABRT_EV5T和CPU_TLB_V4WBI，这里选择abort-ev5t.S和 tlb-v4wbi.S 获取您感兴趣的内容。

功能：v5t_early_abort

 * Purpose : obtain information about current aborted instruction.
 * Note: we read user space.  This means we might cause a data
 * abort here if the I-TLB and D-TLB aren't seeing the same
 * picture.  Unfortunately, this does happen.  We live with it.

我相信大多数 CPU 没有单独的 I-TLB 和 D-TLB。该代码试图通过读取和解码出错的指令来模拟故障状态。 I-TLB（指令 MMU 页面缓存）和 D-TLB（数据 MMU 页面缓存）可能不一致，并且指令存储器的读取可能会做一些奇怪的事情。

你是与它一起生活的人吗？即，您是否知道ixp23xx XScale3 (XSC3) 是否有单独的I/D 翻译后备缓冲区 (TLB)？

另一个奇怪是IO_36。 CPU 有 36 位 地址。来源见domain.h。 域似乎成为地址的一部分。这可能会导致一些奇怪的效果，但我无法粗略地找到任何东西。

对不起，我没有回答你的问题。这将是一个很长的评论。

回到问题，根据 XSCALE 数据表，通过设置 Xbit = 0、C 位 = 0 和 B 位 = 0，可以通过“停止直到完成”使这个故障几乎精确（+3 instr）。 ...内核配置中有一个选项，即 CONFIG_CPU_DCACHE_DISABLE

CONFIG_CPU_DCACHE_DISABLE 不会解决您的问题。 I-cache 和 写缓冲 仍将处于活动状态。同样，您的系统将非常缓慢。可以改用内核命令行选项cachepolicy。它支持uncached、buffered、writethrough、writeback 和writealloc。某些值可能不适用于平台。我认为cachepolicy=uncached 可能相当于使用 CONFIG_CPU_DCACHE_DISABLE 进行编译。