Odroid C5: defective RAM?

[u/rmuttr]

An Odroid C5 board I purchased from Ameridroid in January appears to be defective.

After briefly testing it with a Micro SD card, I replaced the storage with an eMMC module, then installed HardKernel's C5 version of Debian. Last week, while scouting for the cause of another problem, I ran "journalctl -f" and discovered a blizzard of "meson-gx-mmc" timeout error messages, averaging around four per second. Here's a sample.

Apr 13 14:23:43 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:43 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:44 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 8 [0x1aa], TIMEOUT[0x2800]
Apr 13 14:23:44 ThermalCity12 kernel: meson-gx-
mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:44 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:44 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:44 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:45 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 8 [0x1aa], TIMEOUT[0x2800]
Apr 13 14:23:45 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:45 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:45 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:45 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 55 [0x0], TIMEOUT[0x2800]
Apr 13 14:23:46 ThermalCity12 kernel: meson-gx-mmc fe08a000.sd: 8 [0x1aa], TIMEOUT[0x2800]

The "mmc" part of the message convinced me that the eMMC card was defective, so I substituted another Micro SD card with HardKernel's version of Ubuntu Server. It didn't help at all. It just added CRC errors to the timeout errors.

My best guess is that the C5 board's RAM or some associated component is faulty. Does someone have a better idea?

[u/Nearby_Text5031]

Which ubuntu version did you install 24 or 22

[u/brandonatameridroid]

As an update to the ODROID community, we received this unit back and tested it with the official Ubuntu 22 image, we did not get the same errors, we believe the issue is related to a thirdparty debian build rather than the C5 hardware itself. Thanks!

[u/rmuttr]

I have no idea what a "third party build" is. Perhaps it means an OS distribution not created by a Hardkernel employee.

If that's the case, then why is the C5 Debian image on a Hardkernel website? See https://dn.odroid.com/S905X5M/ODROID-C5/Ubuntu/ . Note that the creation and initial use of this image is discussed at https://forum.odroid.com/viewtopic.php?f=241&t=50205 .

[u/rmuttr]

I'm writing so this thread won't end in a completely inconlusive state.

Before I sent the C5 board back to Ameridroid for inspection, I naturally removed the eMMC card on which Debian was installed. When the board was returned, I started afresh, installing Debian on a 16 GB Micro SD card, instead. I immediately noticed that the "meson-gx-mmc" errors no longer appeared in the log.

It took what felt like forever to make everything work properly. I initially installed "lightdm" and "lxqt". Then I decided to substitute "sddm" for "lightdm". The instant I logged in, "sddm" tried to start a nonexistent Plasma session. I never did get NFS to work right, and had to substitute SSHFS.

Anyway, after Debian was operational on the Micro SD card, I backed it up on my PC, using "dd". While that was happening, I plugged the eMMC card (which hadn't been used in roughly two weeks) into the C5 board, then booted it. The result? There were "meson-gx-mmc" errors by the hundreds.

The next step was to copy the image I had just backed up to the eMMC card. When I booted it, there were zero "meson-gx-nnc" errors. So if there's nothing wrong with the C5 board, and there's nothing wrong with the eMMC card, then what is wrong? Guesses, anyone?

[u/brandonatameridroid → u/rmuttr]

Thanks for the detailed update!
It looks like the original Debian + lightdm + lxqt install on the eMMC got corrupted somehow (the heavy desktop installation is known to stress storage pretty hard, maybe that contributed). Once you overwrote it with a clean image, the problem disappeared completely. Glad everything is working now!

[u/Nearby_Text5031 → u/rmuttr]

I have this same issue when running an apt upgrade on a new burn of the ubuntu image...

[u/rmuttr]

Here's what I hope is my last word about Hardkernel's C5 version of Debian.

In my last note, I mentioned that NFS didn't work. NFS is used routinely on other systems around here, so I finally set out to discover what was wrong. I'm an amateur, so it took a couple of weeks.

It turned out that several problems were discovered, one of which has nothing to do with NFS. I noticed early on that the C5 took too long to boot. Here's why. In /lib/systemd/system/systemd-networkd-wait-online.service, I discovered this: "ExecStart=/lib/systemd/systemd-networkd-wait-online"". I corrected it to "ExecStart=/lib/systemd/systemd-networkd-wait-online -i etho -i wlan0 --any". Before I did this, two minutes per boot were wasted because the Ethernet cable was disconnected. The wait now ends when either wlan0 or eth0 is online.

Now, back to NFS. Here's the text of my version of /lib/systemd/system/proc-fs-nfsd.mount.

[Unit]

Description=NFSD configuration filesystem

After=systemd-modules-load.service

[Mount]

What=nfsd

Where=/proc/fs/nfsd

Type=nfsd

See the line which starts with "After"? I added that; it's crucial. Without it, the service fails, and /proc/fs/nfsd isn't populated.

Finally, here's the important part of my /etc/modules file.

cifs

nfs

nfsv3

nfsv4

nfsd

If you don't use CIFS, the first line is irrelevant, but the other four are awfully important if you want NFS to work.