公司有一产品在发货都用户手上半个月后无法开机,以确定是文件系统【关键文件丢失】。
导致丢失的因素未知,求指导。
设备能进入uboot,可加载kernel,可挂载文件系统,但执行 linuxrc 时提示找不到,Linux将init进程退出,系统处于假死状态。
通过uboot检查文件系统,设备只存在如下文件夹
======================
688397480206 xp
688397480206 dev
963275387150 mnt
688397480206 tmp
688397480206 sys
2887420735758 var
1513031201038 usr
963275387150 arch
963275387150 home
688397480206 proc
19311375675662 sbin
963275387150 uptarfile
=======================
正常设备应该存在如下文件夹
=======================
688397480134 xp
12095830618310 app
23056587157702 bin
688397480134 dev
6529553002694 etc
20651405471942 lib
1513031200966 mnt
688397480134 nfs
997635125446 opt
688397480134 srv
688397480134 tmp
688397480134 sys
2887420735686 var
1787909107910 usr
963275387078 arch
1238153294022 home
688397480134 proc
19311375675590 sbin
688397480134 root
48447353030 linuxrc
963275387078 uptarfile
1452901658822 .ash_history
688397480134 media
688397480134 modules
=========================
缺少系统关键文件夹
======================
app bin etc lib nfs opt srv root linuxrc .ash_history media modules
========================
系统内有日志,每次执行关键动作都会向Flash内写入一些信息。
设备生存轨迹:
==================
4月8日 一产品在公司内部经过3天高低温运行测试(-10 ~ 50摄氏度)验证通过后发货
4月11日 到用户手中,用户开机检查一次,正常
4月12日 用户开机一次,正常
半个月时间设备无开机历史
5月3日 用户反馈设备无法正常启动
=====================
设备分区
==============
mtd0: 00c00000 00020000 "reserve" uboot + 主Kernel + 备 Kernel 12M
mtd1: 00080000 00020000 "reserve" 512K预留
mtd2: 00080000 00020000 "reserve" 512K预留
mtd3: 00200000 00020000 "bmp" 2M存储logo
mtd4: 00080000 00020000 "reserve" 512K预留
mtd5: 04000000 00020000 "rootfs" 64M ubifs
mtd6: 03080000 00020000 "opt"
===================
个人可确定的是:
系统正常运行时不可能删除如下目录,最多也就是往app目录下写某配置文件
app bin etc lib nfs opt srv root linuxrc .ash_history media modules
关机半月没有使用,这段时间肯定没有进行文件系统的操作,但是不排除最后一次正常关机前没有问题,可能只是问题没有显现出来,比如某文件缓存在内存中,导致没有出错,掉电后再次上电就有问题了,又或者最后一次上电工作时启动后,系统启动相关的文件在正常启动后损坏,再次上电可能失败;
以下才是重点
以上只是一些猜测,看到你写的静置半月之后数据丢失,最先想到的就是nand flash的data retention问题,意思就是nand 放置一段时间后比特位会发生反转,反转的少了,controller内部的ECC会将数据纠正,反转的多了超过纠错能力,就没有办法正确读取数据。这个问题温度越高越明显,这个是nand特性,SLC最好,MLC次之,TLC最差,如果成本不敏感可以选择SLC。
data retention是ssd udisk测试中必须要测试的项目,写入数据,然后进行高温bake,再进行数据校验,这个也是nand管理中必须要处理的问题 ,如果能够进行debug,可以查看是否在启动失败的时候出现了nand的read ecc error,这个可能要关注一下nand 驱动层了,如果是这个问题,看看系统是否允许增加校验位数
可以尝试以下方法进行问题复现
常温工作,进行运行时的日志文件写入,运行一段时间之后进行离线高温环境静置,想尽快复现的话就提高温度,增加高温时间,然后再进行常温环境下的系统启动,如果还不能复现问题,多重复几次
基本确定一个怀疑方向,产品每次关机都属于强制断电,没有保证文件系统完整性。
公司产品的一键开关机电路参考我上一帖子的描述,
开机:长安2秒开机
关机:长安2秒关机
https://bbs.eeworld.com.cn/forum. ... 0&page=1#pid2364221
实际关机流程:
用户按下2秒后执行sync()同步文件,【屏幕熄灭提示用户放手】,若用户长时间不放手,设备将永不断电【参考链接电路】,倘若2秒后依旧有文件写入,正在重写文件表时用户放开手指,将导致文件系统不完整,下次启动现象不可知。
为什么我不用reboot:
用户按下两秒后直接reboot可保证文件系统的绝对完整,同时屏幕也会熄灭提示用户放开手指,但是倘若用户【不放手】,设备将重新进入uboot,重新开机,用户就会反应我们的设备【怎么好难关机】(公司设计长期遗留问题)
文件系统使用的是UBIFS
浮现问题:
一个进程往设备反复写2000个100K的文件;
一个进程不时的执行sync;
在执行sync未完成时,按处理器复位键;
反复10次以内,文件系统变成只读,用命令 mount -o remount,rw / 无法重新挂载。
Uboot检查无坏块,重新烧录文件系统可正常使用
文件系统时UBIFS
尝试复现:
1个检查建立2000个200K的文件;
1个检查不时的SYNC
在第二个检查SYNC没有结束时按处理器的复位按钮;
重复10次左右文件系统变成只读,即使mount -o remount,rw /也不能解决。
uboot检测不到坏块,重新烧写文件系统可恢复。
linuxrc是个文本配载文件,加输出再现错误看看是哪条引起的