MMC数据在内存中损坏，嵌入式系统

Question

好的，这很奇怪。我们最近遇到了一种情况，看来嵌入式Linux系统中的文件已损坏。

[我们之所以发现这一点，是因为某些文件的md5sum与其应有的样子有所不同，包括一些可执行文件，这些可执行文件在运行时会进行核心转储（这是发现的最初触发器）。据推测，尽管这些可执行文件的标头是正确的，但文件中更改的内容会导致崩溃。

文件大小不变，日期也没有改变。

我之所以说“出现”是因为：

1. 更改发生时文件系统以只读方式安装；
2. 重新启动将导致文件恢复其先前状态；和
3. 页面高速缓存刷新"sync; echo 1 > /proc/sys/vm/drop_caches"也将恢复以前的状态。

这使我相信，更改的不是MMC存储本身，而是内核中的某些内存中结构。

检查我们的一个配置文件（在这里我们可以轻松看到更改的内容）显示以下行为。少量转储可能会有所帮助（<>对中包含错误的字符）：

      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F  0123456789ABCDEF
02F0  20 31 30 31<01>7d 20 73<02 00 00 00 00 00 20 00   101.} s...... .
0300  02 00 00 00 62 6f 6f 74 31 00>64 3a 20 36 39 20  ....boot1.d: 69 
0320  7d 0a 7d 20 7d 0a 0a 23<01>31 30 31<02 00 00 00  }.} }..#.101....
0340  00 00 20 00 03 00 00 00 72 70 6d 62 00>2f 2b 4d  .. .....rpmb./+M

文件的那个特定部分应该是（十六进制转储从第一行开始一直到最后一行都结束）：

 101 } station { station_id: 69 }
} }

# 1012/MTWTF../#C8102E/+M

因此，似乎文件的某些部分的文件内容传送错误。

这里有些怪异。损坏发生在文件中某些断开的位置，并遵循带有三个特定子模式的特定模式：

• 一个坏字符和三个不变的字符；
• [包含rpmb的十七个坏字符，后跟十五个好字符；
• 一个坏字符和三个不变的字符；
• [包含boot0的18个坏字符，后跟十四个好字符；
• 一个坏字符和三个不变的字符；
• [包含boot1的十七个坏字符，后跟十五个好字符。

rpmb/bootN字符串以外的所有损坏字节似乎都是低字节（大多数为零，但奇数CTRL-A，CTRL-B或CTRL-C。）是文件中某个位置的几个序列。

现在我知道rpmb，boot0和boot1都与MMC内容相关联，但是我不知道这是如何发生的。内存缓存应well远离被用户代码破坏的位置。

[在我们运行更新检查器过程的设备中似乎更为普遍。该过程（在其他地方运行）将维护SSH会话，并每15秒检查一次配置文件详细信息，以查看是否需要更新（不是必需的）。我看不到定期读取文件的进程如何导致Linux系统内存中的缓冲区损坏。

我们正在研究可能对Linux内核进行的任何可能的更改，并且我们正在多台计算机之间建立差异分析，例如较早的内核，有无更新过程等，因此我们可以缩小范围是什么原因造成的。

所以我的问题是真的：对于从这里到哪里或可能有用的其他任何调查领域，有人是否有任何建议？

Answer 1

一些想法：

[似乎是（仅）一个转移到缓存的问题：数据应在不同阶段进行检查，直到到达缓存。我猜想，这很可能是DMA传输已损坏，否则无法通过刷新缓存来解决。

您是否出于其他目的激活了某些unrelated DMA通道？您是否更改/优化了使用的DMA通道？