I’ve recently had a corruption problem with the internal eMMC storage of my SBC (Mixtile Blade 3), which held the O/S (Ubuntu 24), application SW, and a handful of Docker containers: The Ceph cluster (which comes in a Docker container) handful lost parts of its configuration and can’t be started anymore. I’ve also encountered a handful of system freezes. After a little research, I found out that the eMMC must be corrupted:
mmc0: cqhci: timeout for tag 0, qcnt 31
To be precise, it must have been a faulty power input of the eMMC chip:
sdhci-dwcmshc fe2e0000.mmc: Looking up vmmc-supply property in node /mmc@fe2e0000 failed
Looking up vqmmc-supply property in node /mmc@fe2e0000 failed
Google’s AI suggested me to modify these entries (controlling the 1.8 V power input and signaling speed of the eMMC) in the device tree:
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
…with this piece of config:
mmc-hs200-1_8v;
no-1-8-v;
I’ve already changed the device tree as suggested, compiled it to a DTB, installed it, and rebooted the system. At last I don’t see any errors anymore, but they can reappear.
Now I’d like to know:
- Is it possible that the purportedly wrong device tree settings lead to unstable operation of the eMMC and data corruption?
- Is Google’s suggestion correct, and will it help me to stabilise my eMMC storage?
- Do I have to reinstall the complete O/S on my system, or is it sufficient the bootstrap Ceph for a second time?
Work data are been stored on an external SSD and shoud be therefore not affected BTW.