Open tomharvey opened 2 months ago
After a reboot I ended up in busy box.
After running fsck -y on the device I can exit out of busy box and all is well again... I assume, until the next time the queue gets borked
After a reboot I ended up in busy box.
After running fsck -y on the device I can exit out of busy box and all is well again... I assume, until the next time the queue gets borked
Had the same thing happen. The above fix also worked on mine
Interesting, dropping the eMMC down to HS200 is the proposed change here?
While this is not a fix, dropping https://github.com/Joshua-Riek/linux-rockchip/commit/d03a5046f13a8a5b4d7c4b02e442aa4508890413 may be a better option, but how will this affect other devices?
@Joshua-Riek
how will this affect other devices?
Should only reduce IOPS a bit but better to have a stable device
As an alternative, add these only to known affected devices?
&sdhci {
...
/delete-property/ supports-cqe;
...
};
I think I need to try a dtbo like this on Rock5B:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target = <&sdhci>;
__overlay__ {
mmc@fe2e0000 {
/* Commenting out supports-cqe */
// supports-cqe;
};
};
};
};
What happened?
I was doing some intensive disk activity on my EMMC device (no other disks are connected) when it flipped to read-only mode.
Kernel logging is attached
This seems similar to issues which resulted in a reconfiguration of the EMMC in the official kernel here https://github.com/radxa/kernel/pull/127/files and issues reported in Armbian here https://forum.armbian.com/topic/18745-emmc-errors/
Kernel version
6.1.0-1025-rockchip
SBC model
Radxa Rock 5B
What operating system are you seeing this problem on?
Ubuntu 24.04 LTS (Noble Nombat)
Relevant logs