This is a known class of problem on the original (A64) PinePhone, though it shows up under a few different names. What your log shows lines up with three documented things:
The generic Linux eMMC cache-flush hang. Your exact signature — mmc_flush_cache stuck in __mmc_poll_for_busy while jbd2 waits forever — is a known bug class in the Linux MMC stack: after an eMMC error, the cache-flush command hangs instead of failing fast and resetting the card. It's not PinePhone-exclusive, but it's how an eMMC misbehaving manifests.
A64 DVFS instability. The second hung worker in your log (stuck changing CPU voltage under the conservative governor) matches the known Allwinner A64 weakness where frequency/voltage transitions can destabilize the SoC — postmarketOS has tracked cpuidle/cpufreq breakage on the pine64-pinephone, including transitions that don't wait for voltage ramp-up.
DRAM clock instability, especially on the 3GB variant. Danctnix (the distro you're running, per the log) has an open issue about constant crashes and kernel panics on the 3GB PinePhone, where the community consensus workaround was a U-Boot with lower DRAM clock speed. Random lockups of exactly your flavor were among the symptoms.
megi's own PinePhone hardware-quirks page does not list eMMC instability as a universal defect — so this isn't "all PinePhones do this." It's either marginal stability (DVFS/DRAM) or your particular eMMC starting to misbehave.
What I'd recommend, in order
Check filesystem integrity now. Boot from a microSD card and run fsck.ext4 -f /dev/mmcblk2p2. A journal commit died mid-flight in your log; the journal should replay cleanly, but verify.
Check whether the eMMC itself is aging. With mmc-utils installed: mmc extcsd read /dev/mmcblk2 | grep -i -A1 LIFE — the DEVICE_LIFE_TIME_EST fields tell you if the flash is near end-of-life. If it reports type B at 90–100%, the eMMC is the problem and no software tweak will save it; back up and plan around it.
Update kernel and U-Boot to the latest danctnix packages. Megi's kernels have accumulated MMC and DVFS fixes over time, and if you have the 3GB model, make sure you're on a U-Boot build with the corrected/conservative DRAM timing.
Reduce DVFS churn as a test. Your log shows the conservative governor actively mid-transition when things wedged. Try either pinning the frequency (cpupower frequency-set -g performance, or cap max frequency to ~1.15 GHz) or switching to schedutil. If the hangs stop, you've confirmed the DVFS trigger and can keep the cap as a permanent workaround.
If it still recurs, two more options: run the system from a good microSD for a week (if hangs vanish, the eMMC is the culprit); or disable the eMMC's cache so the flush path that wedged is never taken — on recent kernels that's a card quirk, and losing the write cache on this hardware costs little.
Lanx , prefer their ecosystem. Guess I'm just used to it. But when Google pulled out of the tablet race I did pick up a Pixel tablet for cheap a few years ago and it was such a 1:1 copy of ipads I gave it away. Completely hated it.
