end_request: I/O error, dev mtdblock3, sector 0

最新推荐文章于 2025-03-04 11:12:12 发布
原创 最新推荐文章于 2025-03-04 11:12:12 发布 · 3.7k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#操作系统 #linux kernel

本文介绍了解决嵌入式系统中出现的“I/O error, dev mtdblock3”问题的方法。通过调整内核命令行参数，特别是添加了文件系统类型(rootfstype)，成功解决了在启动过程中遇到的问题。

end_request: I/O error, dev mtdblock3, sector 0  

​

挂载root时候出错：
end_request: I/O error, dev mtdblock3, sector 0
Buffer I/O error on device mtdblock3, logical block 0
end_request: I/O error, dev mtdblock3, sector 0
Buffer I/O error on device mtdblock3, logical block 0
end_request: I/O error, dev mtdblock3, sector 8

 

解决：Kernel command line: 出错

 bootargs noinitrd  root=/dev/mtdblock4 rootfstype=yaffs2 init=/linuxrc console=ttySAC0,115200

少了rootfstype 

在uboot下

# setenv  bootargs noinitrd  root=/dev/mtdblock4 rootfstype=yaffs2 init=/linuxrc console=ttySAC0,115200


移植cramfs文件系统时uboot不能使能硬件ECC
fulinux的博客
04-10 3645
***************************************************************************************************************** 作        者：fulinux 版权所有：fulinux 装载声明： http://blog.youkuaiyun.com/sonbai/article/
绿米Aqara S1【妙控开关 S1E】的破解方法---续篇
LeeKwen的专栏
10-26 1万+
上接第一篇《绿米Aqara S1【妙控开关 S1E】的破解方法》。上篇主要讲述了，绿米S1E这款硬件的基本组成及TTL线的线序，并获取到了对应的串口打印信息。此篇重点讲解，如何进入其系统，并开启访问权限。
end_request: I/O error
weixin_34090562的博客
04-28 347
end_request: I/O error   在移植NAND FLASH驱动，很有可能遇到end_request: I/O error mtblock1这样的问题。如果已经能够识别NAND FLASH坏块并且已经识别MTD分区，那么很有可能是FLASH坏块驱动的ECC设置问题。   解决办法：可以将NAND ＦＬＡＳＨ　的ECC设置为NAND_ECC_NONE。...
end_request: I/O error, dev mtdblock2, sector 0 Buffer I
ucan23
11-18 4223
内核移植时遇到这个错误： end_request: I/O error, dev mtdblock2, sector 0 Buffer I/O error on device mtdblock2, logical block 0 原因分析：由于内核是通过uboot烧写到nandflash中，因此uboot产生的ecc校验码与内核的ecc校验码不同，所以需要关闭内核的ecc校验。
i o error dev oracle,Linux kernel: end_request: I/O error
weixin_32515577的博客
04-16 657
Hi,I am intermitently getting the following error in Oracle-Linux ASM database /var/log/messages. This is a 2-node RAC database. But everything is working fine.We are using:RHEL4(U4)Oracle 10gR2 with ...
end_request: I/O error, dev mtdblock4, sector 0
janlin的专栏
12-02 5081
end_request: I/O error, dev mtdblock4, sector 0<br />移植内核时出现了这种错误,这种错误通常是由校验造成的.这种情况的解决办法为：<br />禁止Flash ECC校验<br />我们的内核都是通过UBOOT写到Nand Flash的, UBOOT通过的软件ECC算法产生ECC校验码, 这与内核校验的ECC码不一样, 内核中的ECC码是由S3C2410中Nand Flash控制器产生的. 所以, 我们在这里选择禁止内核ECC校验.<br />修改drive
RHEL7.0启动时end_request I/O error及piix4_smbus错误提示处理
weixin_34161083的博客
01-14 355
　　在VMWARE虚拟机下安装RHEL7.0，启动时有以下提示。经网上搜索，答复为floppy及piix4_smbus设备加载时找不到设备所致。　　解决办法如下：floppy，在BIOS里禁用软驱，重启piix4_smbus，先检查一下是否有加载piix4，如有把i2c_piix4加入黑名单，启动时不加载此模块# lsmod | grep i2c_piix4# vi /et...
linux mtd 块设备,MTD块设备的数据读取
weixin_30225755的博客
05-11 958
二，数据读取数据读取分为同步读do_sync_read和异步读generic_file_aio_read。它们的区别是同步读，要等数据读取结束函数才返回，异步读是在函数返回时数据读取可能还没结束。同步读是通过调用异步读取函数加等待函数实现的。ssize_tgeneric_file_aio_read(structkiocb*iocb,conststructiovec*iov,unsign...
linux-2.6.30.4移植至2440开发板
ce123的技术博客
07-03 4632
linux-2.6.30.4移植至2440开发板经验谈 一、下载linux-2.6.30.4源码，并解压 ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.4.tar.gztar zxvf linux-2.6.30.4.tar.gz二、在系统中添加对ARM的支持 $vim Makefile 193#ARCH ?= $(SUBARCH)
Linux 3.3.0移植到S3C6410开发板上之一
chenlong12580的专栏
02-13 4544
这里仅仅是移植成功内核，可以挂载文件系统运行，至于驱动会陆续添加。      第一步：到内核官网上下载最新的内核，我下载的是linux-3.3-rc3.tar.bz2。      第二步：解压内核，进入arch/arm/mach-s3c64xx目录下，看到不少6410的板级文件，我们这里选择mini6410开开展工作，在目录下将mach-mini6410.c文件复制一份，命名为：mach-jf
CentOS7中开机出现end_request:I/O error,dev fd0,sector 0的解决办法
热门推荐
羊羊羊
10-29 4万+
由于没有软驱，所以直接禁止这个服务，等待进入
ORACLE RAC其中几个节点突然宕机，原因：localhost kernel: end_request: I/O error, dev sdi, sector 873749760
张陈亚的博客
05-23 2790
背景： 2019年5月22日，12点多，在另外一个厂商调用我司的应用接口时，突然报错；另外，我司的业务系统的菜单功能，点击进去也是报错。 前台报错如下： 通过分析应用日志和中间件控制台数据源，发现连接的那个节点宕机了。 第一步：srvctl status databse –d orcl 用此命令看的数据库状态； 第二步：srvctl status database –d orcl ...
SDIO出错 error -84 sending status command, retrying end_request: I/O error, dev mmcblk0, sector
Colorful_lights的博客
03-23 8779
在调试emmc的时候遇到一个问题，挂载emmc出现如下错误： ~ # mount /dev/mmcblk0 /mnt/ end_request: I/O error, dev mmcblk0, sector 2 EXT4-fs (mmcblk0): unable to read superblock mmcblk0: error -84 sending status command, re
Buffer I/O error on device mmcblk0p3, logical block .../end_request: I/O error, dev mmcblk0, sector
gooogleman#foxmail.com
03-12 1万+
root@android:/ # [   60.514520] mmcblk0: error -84 transferring data, sector 953222, nr 808, cmd response 0x900, card status 0xc00 [   60.531824] end_request: I/O error, dev mmcblk0, sector 953222 [
end_request: I/O error, dev sdi, sector 硬盘 故障
myCOMMUNICATION
08-10 2万+
利用 内核日志 帮助定位磁盘问题 ，还是很有用的一篇资料。 定位core问题时，找到好久才发现的一些资料，分享一下： Linux内核I/O系统报错日志与硬盘故障对应关系： http://ilinuxkernel.com/?p=386 其它关于硬盘IO的资料
如何解决blk_update_request: I/O error,dev fd0 ,sector 0错误
纵歌的博客
03-04 2979
如何解决blk_update_request: I/O error,dev fd0 ,sector 0错误
blk_update_request:I/O error, dev mtdblock17, sector 38856
最新发布
09-16
<think> 我们针对用户的两个报错信息进行分析和解决： 报错1: `ubi_io_read:error -110 while reading 514 bytes from PEB 158:91136, read only 0 bytes` 报错2: `blk_update_request:I/O error, dev mtdblock17, sector 38856` 根据之前引用的资料和UBI相关知识，我们进行如下分析： 1. 错误码分析： -110 对应 Linux 内核的错误码 ETIMEDOUT，表示操作超时。在NAND闪存操作中，读取超时通常意味着硬件问题，可能是由于： a) NAND闪存块（PEB 158）已经损坏或变得不稳定，导致读取响应超时。 b) 硬件连接问题（如接触不良）或电源不稳定。 c) 驱动程序的超时设置过短（但通常不是主要原因）。 2. 第二个报错 `blk_update_request:I/O error, dev mtdblock17, sector 38856` 表明在块设备mtdblock17上发生了I/O错误，具体发生在扇区38856。这个错误通常是由底层存储设备（在这里是UBI/MTD）的读取失败引起的。 3. 结合两个错误，可以推断：在尝试读取mtdblock17设备的某个扇区（38856）时，底层UBI需要读取相应的物理擦除块（PEB 158）中的某个位置（偏移91136），但是读取操作超时（-110），没有读取到任何数据（0字节）。 4. 可能的原因： - PEB 158 已经变成了坏块（bad block），或者处于不稳定状态（部分损坏）。 - 该块可能之前就存在问题，而UBI的坏块管理机制尚未将其标记为坏块（或者标记后迁移过程失败）。 5. 解决方案： 步骤1: 确认坏块 使用命令检查坏块信息： ```bash # 查看MTD设备17的坏块信息 mtdinfo /dev/mtd17 ``` 或者使用更底层的命令： ```bash # 使用nanddump读取PEB 158对应的块（注意：需要知道每个块的大小，假设为128KiB，则块号为158） nanddump -q -s $((158*128*1024)) -l 128 /dev/mtd17 -o ``` 如果该块确实损坏，读取将会失败。 步骤2: 如果确认是坏块，则让UBI重新映射该块（需要重新附着UBI设备） 注意：如果系统已经挂载了该UBI设备上的文件系统，需要先卸载。 a) 卸载文件系统（如果挂载了的话）： ```bash umount /path/to/mount/point ``` b) 解离UBI设备： ```bash ubidetach -p /dev/mtd17 ``` c) 使用UBI工具标记该块为坏块，并重新附着： 由于UBI在附着时会自动扫描坏块，所以重新附着时，如果检测到该块错误，会将其标记为坏块，并将数据迁移到其他块（如果有备份的话）。重新附着的命令： ```bash ubiattach -p /dev/mtd17 ``` 但是，如果该块上的数据是重要的元数据（例如UBI卷表），则可能会导致卷无法识别。这时可能需要使用`ubinfo`来检查卷的状态。 步骤3: 如果重新附着后问题仍然存在，或者该块上的数据已经无法恢复，那么可能需要重新格式化该分区并恢复数据。 a) 备份该MTD分区上尚未损坏的数据（如果可能）： 使用`nanddump`工具将整个分区读取出来（跳过坏块）： ```bash nanddump -n -q -o -f /path/to/backup.img /dev/mtd17 ``` 注意：跳过坏块可能会导致备份不完整，但总比没有好。 b) 强制擦除该分区并重新创建UBI： 警告：这将清除分区上的所有数据！确保备份了重要数据。 ```bash ubiformat /dev/mtd17 ``` 然后重新初始化UBI： ```bash ubiattach -p /dev/mtd17 ``` 接着创建UBI卷（需要根据之前的分区布局）： ```bash ubimkvol /dev/ubiX -m -N vol_name # 例如 ``` 最后，恢复备份的数据（如果有备份的话）。 步骤4: 如果坏块数量持续增加，可能是闪存寿命已到，需要考虑更换硬件。 6. 预防措施： - 定期检查MTD分区的坏块数量（通过`mtdinfo`）。 - 使用UBI的磨损均衡特性，确保闪存各块擦写次数均衡。 - 使用带有ECC校验的文件系统（如UBIFS）并确保ECC配置正确（参考引用[5]中关于ECC设置的问题）。 7. 关于第二个报错（blk_update_request）的处理： 这个错误是第一个错误的直接结果，因为块设备层（mtdblock）依赖于底层的MTD/UBI操作。解决了UBI层的读取超时问题，块设备层的错误自然就会消失。 8. 紧急恢复步骤（如果系统无法启动）： 如果该分区是系统关键分区（如根文件系统），则系统可能无法启动。在这种情况下，需要进入恢复模式（如通过initramfs）或使用JTAG等工具进行恢复。 9. 注意事项： - 操作MTD/UBI设备时，务必确保设备未被挂载。 - 重新格式化会清除所有数据，务必先备份。 流程图： ```mermaid graph TD A[发生错误] --> B{是否可读取其他数据？} B --> |是| C[卸载文件系统并解离UBI] B --> |否| D[尝试备份数据] C --> E[重新附着UBI] E --> F{错误是否解决？} F --> |是| G[重新挂载] F --> |否| H[使用ubiformat重新格式化] H --> I[重新创建UBI卷并恢复备份] D --> I ``` 相关问题： §§相关问题§§ 1. 如何检测NAND闪存的剩余寿命？ 2. UBI设备的重新附着操作具体会执行哪些步骤？ 3. MTD分区出现坏块后，如何安全地备份数据？ </think> ### UBI读取超时（-110）与块设备I/O错误的联合解决方案 #### 问题诊断 两个关键报错存在因果关系： 1. `ubi_io_read: error -110 while reading 514 bytes from PEB 158:91136` - **错误码 -110**：对应内核`ETIMEDOUT`（操作超时）[^1] - **根本原因**：NAND闪存物理块（PEB 158）因以下原因响应超时： * 块已完全失效（电荷无法维持） * 硬件线路老化导致信号延迟 * 闪存寿命耗尽（PEB擦写次数超过芯片规格） 2. `blk_update_request: I/O error, dev mtdblock17, sector 38856` - **直接原因**：因底层UBI读取失败导致块设备层I/O操作失败 - **关联分析**：MTDblock17对应UBI设备的逻辑块，扇区38856映射到PEB 158的偏移91136处 #### 紧急修复步骤 ```mermaid graph TD A[检测到-110超时错误] --> B{尝试读取相邻区块} B -->|成功| C[标记PEB158为坏块<br>ubiformat -e 158 /dev/mtdX] B -->|失败| D[检查供电/线路稳定性] C --> E[重建UBI卷] D -->|电压异常| F[更换电源模块] D -->|线路正常| G[硬件寿命检测] G -->|PEB损耗>80%| H[更换闪存芯片] G -->|PEB损耗<80%| I[降低时钟频率] ``` 1. **隔离坏块并重建卷**： ```bash # 卸载关联设备 umount /dev/mtdblock17 ubidetach -p /dev/mtd17 # 强制擦除坏块(PEB158) ubiformat /dev/mtd17 -e 158 -y # 重建UBI配置 ubiattach -p /dev/mtd17 ubimkvol /dev/ubi0 -s 100MiB -N recovery_vol # 恢复备份数据 ubiupdatevol /dev/ubi0_recovery_vol backup.img ``` 2. **硬件状态检测**： ```bash # 检查坏块比例 mtdinfo /dev/mtd17 | grep "Bad block count" # 评估闪存寿命（需内核支持） grep -H "wear_leveling" /sys/kernel/debug/ubi/ubi0_0/* ``` #### 根本性修复方案 1. **驱动参数优化**： ```bash # 增加NAND操作超时阈值（默认20ms→200ms） echo 200 > /sys/module/davinci_nand/parameters/timeout_ms # 禁用验证写入（针对旧内核） if grep -q CONFIG_MTD_NAND_VERIFY_WRITE=y /boot/config-$(uname -r); then echo "需重新编译内核禁用VERIFY_WRITE" fi ``` 2. **ECC配置修正**（引用[5]）： - 确认`nand_chip->ecc.bytes`设置匹配物理页大小： ```c /* 示例：2048字节页需28字节ECC */ case 2048: nand_chip->ecc.bytes = 28; // 不能是7或14 ``` 3. **预防性维护**： ```bash # 定期触发磨损均衡 crontab -e * 3 * * * ubiupdatevol /dev/ubi0_0 -t ``` #### 数据恢复要点 1. **受损扇区定位**： ```bash # 计算MTDblock17的38856扇区对应PEB位置 ubinfo /dev/ubi0 | grep "Logical eraseblock size" let LEB_SIZE=128*1024 # 示例值 let PEB_OFFSET=38856*512 - (158*$LEB_SIZE) echo "受损位置: PEB 158 偏移 $PEB_OFFSET" ``` 2. **强制数据提取**： ```bash dd if=/dev/mtd17 bs=1 skip=$((158*128*1024 + 91136)) count=514 | hexdump -C ``` > **硬件更换阈值**：当检测到`可用备用块 < 总块数×5%`或`单块重试次数 > 50次`时，必须更换闪存芯片[^3] ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值