Question

我已经为CHIP Pro SoM使用Yocto构建了Linux系统。在经过数周的现场测试后，一些系统陷入了重启循环。
经过初步调查，结果表明，在引导过程中，需要将一些数据写入UBIFS卷上的文件中。 问题：写入文件的进程根本不会返回。此外，当写入卡住后读取文件时，读取进程也会停止返回。
由于我使用看门狗监视启动过程，因此它会在一段时间后启动并重置系统。我首先不知道是什么引起了问题，但我怀疑电源中断并且UBI或UBIFS数据或NAND（东芝TC58NVG2S0HTA00）本身存在问题。

我可以将问题归结为一个LEB（请参见下文），但我不知道如何进一步调试问题。我的最终目标是找到一个无人值守的恢复解决方案或变通办法来解决该问题，以免完全卡住。

我在营救initramfs中进行了一些测试，以找出问题所在：

只要文件未写入任何内容，读取原来的文件就不会成为问题。程序或dmesg没有报告错误。
在隔离了引起首次写操作的初始过程之后，我研究了该文件：它是ext4格式的图像文件，大小为10MB，通过循环装入，该日志具有损坏的日志，并且在装入期间具有写入文件以恢复日志。这加强了我最初对功率消耗的怀疑。当安装它而没有恢复（ext4 norecovery-option）时，它立即成功。快速的dmesg输出如下：https://pastebin.com/raw/XtRDeZde

根据写入的数量，检测到不同的详细信息行为：
一种。 触摸不存在的文件时，它可以正常工作。重新启动后，它仍然存在：

$ mount | grep ubi
ubi0:root on /mnt/images type ubifs (rw,noatime,nodiratime,sync,chk_data_crc)
$ touch /mnt/images/test/touched2 
$ ll /mnt/images/test/touched2 
-rw-r--r--    1 root     root             0 Jul  9 10:21 /mnt/images/test/touched2

请参见https://pastebin.com/raw/fYMzGbLU
有关详细信息。忽略看门狗警告。它们来自在后台运行的脚本，并且由于设置了CONFIG_WATCHDOG_NOWAYOUT选项，内核发出了警告。
b。 写入至少一个字节时，没有返回：

$ mount | grep ubi
ubi0:root on /mnt/images type ubifs (rw,noatime,nodiratime,sync,chk_data_crc)
$ dd if=/dev/urandom of=/mnt/images/test/one_random bs=1 count=1 
[reboot needed]
$ ll /mnt/images/test/one_random
-rw-r--r--    1 root     root             1 Jul  9 10:26 /mnt/images/test/one_random
$ hexdump /mnt/images/test/one_random
*

https://pastebin.com/raw/4PNTkXLb
重新启动/重新启动后，将在文件末尾显示结果。存在一个零字节的文件。
C。 向文件写入1kB 时，最后的结果非常相似：

$ mount | grep ubi
ubi0:root on /mnt/images type ubifs (rw,noatime,nodiratime,sync,chk_data_crc)
$ echo 'format "UBIFS DBG" +pf' > /sys/kernel/debug/dynamic_debug/control
$ dd if=/dev/urandom of=/mnt/images/test/urandom_1k bs=1k count=1 
[reboot needed]
$ ll /mnt/images/test/urandom_1k
-rw-r--r--    1 root     root          1024 Jul  9 11:02 /mnt/images/test/urandom_1k
$ hexdump /mnt/images/test/urandom_1k
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400

https://pastebin.com/raw/jpfzHTnY
这里的文件也只包含零。 d。 但是当写入1M时，结果发现现在的区别是实际内容已写入文件。不是完整的文件，而是部分文件：

$ mount | grep ubi
ubi0:root on /mnt/images type ubifs (rw,noatime,nodiratime,sync,chk_data_crc)
$ dd if=/dev/urandom of=/mnt/images/test/urandom_1M_ bs=1M count=1  
$ ll /mnt/images/test/urandom_1M_
-rw-r--r--    1 root     root       1048576 Jul  9 11:47 /mnt/images/test/urandom_1M_
$ hexdump /mnt/images/test/urandom_1M_
0000000 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
[snip]
003cff0 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
003d000 0000 0000 0000 0000 0000 0000 0000 0000
*
0100000

https://pastebin.com/raw/D4ymKknM

仔细观察时，总是在末尾或附近出现 ubifs_wbuf_write_nolock 函数日志消息。由于触摸和部分1M写入测试实际上已进入闪存，因此我检查了报告的LEB编号：
始终在写入停止时报告LEB 538 。我认为此LEB在编写时会引起问题。例如，写1M文件时使用的LEB 849不会造成任何麻烦-我想。

在这一点上，我不知道如何进行进一步的调查或如何修复已损坏的东西。我怀疑NAND是根本原因，而解决这种情况的方法是我的最终目标。如果在其中一个系统上引起了这样的问题，那么一种自动的恢复方法将是不错的选择。或至少系统可以启动并且不会卡在写操作上。
这可能是驱动程序问题吗？
还是这是未正确处理的NAND错误？

我希望有人能指出我正确的方向，谢谢！

将文件写入UBIFS卷会导致特定LEB停顿-没有读取错误

0 个答案: