Mounting exfat drive cause large CPU spike

[ghost]

Creating a bug report/issue

Required Information

• DietPi version |

G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=25
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | 10.0
• Kernel version | Linux DietPi 4.19.58-v7l+ #1245 SMP Fri Jul 12 17:31:45 BST 2019 armv7l GNU/Linux
• SBC device | Raspberry Pi 4 Model B
• Power supply used | Official Pi 4 AC Adapter
• SDcard used | Sandisk Extreme Class SDHC 10 32GB

Additional Information (if applicable)

• Can this issue be replicated on a fresh installation of DietPi? Yes, this IS a fresh install.

Steps to reproduce

Install exfat support with:

sudo apt-get install exfat-fuse
sudo apt-get install exfat-utils

auto mount the exfat partition at boot with:

sudo nano /etc/fstab
UUID=urUUIhere /mnt/exfat exfat defaults,auto,umask=000,users,rw 0 0

Expected behaviour

mount doesn't cause CPU usage to be stuck at 10% constant usage, but instead stays between 0.0% - 0.1% as it does on Raspbian OS.

Actual behaviour

CPU usage stuck on 10% for the process. CPU temp increased by a whopping 20%!

Extra details

No writes/reads are happening to the drive. This doesn't happen on Raspbian. This is a new install. I understand I could just not use exfat but I want to and I'm sure other people need it. Either way, the CPU usage of this process shouldn't be so high.

P.S. Damn Github causing a full reload of my post when I clicked 'no' to a pop-up prompt... and you wonder why people hate this site.

[MichaIng]

@githubsucks-usegitlab
Many thanks for your report.

I will try to replicate on Buster VM to check if it's Buster or RPi specific.

Did you compare with the current Raspbian Lite Buster version?
Same UUID entry and of course same target drive on same USB port?

---

Tested on VM with exact same fstab entry and as well some others, like defaults of DietPi-Drive_Manager. CPU usage stays at 0.0% in every case.

So no Buster-specific issue but either an RPi4-specific or Raspbian Buster-specific issue, probably driver or firmware related.

However important comparison is DietPi Buster vs Raspbian Lite Buster here. Will also run some test on RPi2 with our Buster image.

[ghost]

Thanks for testing. I'm using the 'experimental' image that you said you merged to 'stable' or w/e after it was reported that the stable did not work with the R-Pi 4 but Buster did. Not sure if you have made any changes to this image or not since then.

I've also done a

sudo apt-get upgrade

Since posting this but still get the same CPU spike issue.

I'm not sure though that testing on a vm will really make this replicateable.

[MichaIng]

@githubsucks-usegitlab

Not sure if you have made any changes to this image or not since then.

Nope, no important changes have been done since the experimental image has been created at first. apt-get upgrade is everything required to bring you onto current stage firmware-wise.

Since posting this but still get the same CPU spike issue.
I'm not sure though that testing on a vm will really make this replicateable.

Indeed this was only a test I was able to do quickly, just to assure that it is no general Debian Buster or DietPi issue.

I did not yet find time to plug my testing SDcard into RPi so far, to test on RPi2 Buster, will do soon.

[MichaIng]

@githubsucks-usegitlab
Sorry for the delay, I just tested it on my RPi2 and CPU stays low as it should:

The same when I use exactly your mount options.

But I have to mention that I just upgraded to edge firmware via rpi-update to test the initial_turbo fix.

There has been another official firmware update for RPi as well: G_AGUP && apt full-upgrade
If this does not help, then this must be RPi4 specific and should be reported to the RPi kernel devs.

[MichaIng]

I mark this issue as closed now. Two firmware updates have been release meanwhile which in question fixed the issue. Feel free to reopen if required.