Based on the bootlog here:
Looks like your hardware doesn't use spi-qup - but rather ath79-spi.
So - my spi_qup DMA disablement hack won't do anything for you.
At a glance, the driver for ath79-spi doesn't do DMA at all - so, if it's the cause of your problems, I don't have a good understanding of why.
The forward-ported SQUASHFS patch should still apply, to help you limp along, though.
Another 15 days - so, 1 month in. No errors (not even SQUASHFS corrections, using the patch).
Disabling DMA in spi_qup may have entirely sorted my issues, on my hardware.
I won't be confident for another month...but, very promising so far!
I'm seeing this on OpenWrt SNAPSHOT r20582-548db4980f running on a gl.inet MT1300 Beryl. Anyone know if spi-mt7621 runs DMA or know if vjorlikowski patch works on this device?
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.308679] SQUASHFS error: xz decompression failed, data probably corrupt
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.315801] SQUASHFS error: Failed to read block 0x4b9d26: -5
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.321708] SQUASHFS error: Unable to read data cache entry [4b9d26]
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.328141] SQUASHFS error: Unable to read page, block 4b9d26, size 1790c
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.335135] SQUASHFS error: Unable to read data cache entry [4b9d26]
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.341656] SQUASHFS error: Unable to read page, block 4b9d26, size 1790c
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.348651] SQUASHFS error: Unable to read data cache entry [4b9d26]
Sun Sep 11 19:24:49 2022 kern.err kernel: [ 72.355192] SQUASHFS error: Unable to read page, block 4b9d26, size 1790c
So weird, when I removed luci-app-aria2 (which I had installed previously) the squashfs errors went away on boot.
Anecdotally, when I installed luci-app-transmission the squashfs error came back on boot. Both those apps were setup to access a f2fs formatted microsd. Not sure if the microsd access is causing this error. I am NOT running extroot from this microsd.
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.653116] SQUASHFS error: xz decompression failed, data probably corrupt
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.660110] SQUASHFS error: Failed to read block 0xb6c4de: -5
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.665936] SQUASHFS error: Unable to read fragment cache entry [b6c4de]
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.672794] SQUASHFS error: Unable to read page, block b6c4de, size f008
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.679590] SQUASHFS error: Unable to read fragment cache entry [b6c4de]
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.686361] SQUASHFS error: Unable to read page, block b6c4de, size f008
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.693171] SQUASHFS error: Unable to read fragment cache entry [b6c4de]
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.700169] SQUASHFS error: Unable to read page, block b6c4de, size f008
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.706982] SQUASHFS error: Unable to read fragment cache entry [b6c4de]
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.713809] SQUASHFS error: Unable to read page, block b6c4de, size f008
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.720666] SQUASHFS error: Unable to read fragment cache entry [b6c4de]
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.727436] SQUASHFS error: Unable to read page, block b6c4de, size f008
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.774345] SQUASHFS error: Unable to read fragment cache entry [b6c4de]
Sun Sep 11 21:34:11 2022 kern.err kernel: [ 48.781135] SQUASHFS error: Unable to read page, block b6c4de, size f008
I tried to apply your forward-ported SquashFS patch on 21.02.3 via but encountered multiple errors during the build process (HUNK errors) on my Ath79 WD MyNet N750. However, the NoTengo patch built successfully. Any idea what was causing the HUNK errors with your particular patch? I built against the same kernel version.
I flashed my WD N750 and the squashfs errors disappeared completely from all logs and the device ran well for 24 hours, but it fell into a boot-loop after the first reboot. I had to reflash to 19.07.10.
Later, I flashed the latest September 17 2022 SNAPSHOT but it still produces a variety of SquashFS errors upon reboot.
There is a mention on the OpenWRT Github that running device with a Exroot overlay via USB may improve or solve the problem, see here: https://github.com/openwrt/openwrt/issues/9085#issuecomment-1214137484
I can confirm that I've observed no further SquashFS errors on my WD MyNet 750 with 21.02.3 since creating an overlay via USB drive. The router has been running reliably for more than a week with the USB overlay. The moment I boot the router without the USB overlay the errors return.
Additionally, I'd highly recommend creating the overlay immediately after flashing/upgrading OpenWRT and before you reboot! Do not reboot the router until you've created the overlay configuration and copied the overlay files. If you reboot before creating the overlay, the SquashFS errors may occur and you may end up creating a compromised overlay by copying partially corrupt files.
Credit to M95D on this Github thread for the suggested "solution."
I also encountered SQUASHFS error, It caused curruption of 5 files in /rom.
[2784143.127473] SQUASHFS error: Unable to read fragment cache entry [354c6]
[2784143.132460] SQUASHFS error: Unable to read page, block 354c6, size 16e98
[2784155.611002] ash (24053): drop_caches: 3
[2784157.346471] ash (24053): drop_caches: 3
I executed “echo 3 > /proc/sys/vm/drop_caches” to clear the cache, then SQUASHFS error disappeared, but the 5 files are still not fixed.
My board disk is nand flash, squashfs in ubi volume. It running for 1 month before appeared SQUASHFS error.
The squashfs image data in nand flash is corrected, I had check it.
It's been 20 days and I can't reappear again.
Does anyone know the reason? Any suggestions.
Update:
I installed today’s SNAPSHOT (Aug 14 2023) on a WD MyNet N750 and the SquashFS errors persist.
It survived about 4 reboots in a 12 hour period before the errors appeared. Running kernel 5.15.126, default install, no overlay.
The persistence of this issue without a solution (other than a USB overlay) is a real shame.
Thanks for the update.
I have been happy using usb extroot. It's nice to have a real ext4 filesystem with the usual tools and be able to update and install whatever packages I want without having to worry about space or wear on flash memory. Performance seems fine.
Even if the corruption bug was fixed, I'd probably continue to install usb extroot going forward.
FYI, a commit to address this issue on the ipq40xx platform was submitted in September.
https://github.com/openwrt/openwrt/commit/98d325aaf8bef992cc92e94feb14fe271d370dc0
Can someone review the code and submit commits for other platforms like ath79, etc? I'd do it, but I don't have the requisite coding skills.
Additionally, a mediatek platform user reported that the committ below improved their corruption problem (unsure if it solved it, see thread.)
@NoTengoBattery
Do you have a patch that works for kernel v6.6?
Thanks.
the code in patch is buggy
call __squashfs_kill_pages() without get a bh reference is dangerous