Problems with Zram on H2/3/5 boards - zram: Decompression failed! err=-22

[Hammy]

Armbianmonitor:

http://ix.io/2ES2

Good evening,

 

I ran into some problems with sbc-bench on a couple of Allwinner boards Orange Pi Zero, Orange Pi Zero+, Orange Pi One and Nanopi Neo 2 spcifically. The 7 Zip benchmark causes the following error:

 

./sbc-bench.sh: Zeile 611:  4206 Bus-Zugriffsfehler      "${SevenZip}" b >> ${TempLog}

 

Most likely due to a problem with the ZRam:

 

zram: Decompression failed! err=-22

 

This happens on all boards under Debian and focal with different SD cards and power supplies. The benchmark ran previously on this setups without any issues – unfortunately I don’t know when it stopped working and hence cannot narrow down the change that caused the problem.

 

The benchmark results and armbianmonitor output from the Orange Pi one as an example:

 

http://ix.io/2EPZ

http://ix.io/2ES2

 

Is this a known issue? Is there a solution?

 

Daniel

[Icenowy]

https://github.com/armbian/build/pull/2377 Tested to fix the issue.

[Hammy]

Small update:

 

going back to Armbian 20.08.17 Buster with Linux 5.4.62-sunxi64 "solves" the problem.

http://ix.io/2EYt

Can anyone confirm this behavior?

 

Daniel

[Igor]

I didn't checked yet, but I read on OpenHAb forum that their ZRAM implementation is failing. On Rpi. Which makes me believe the problem comes from the upstream.

[Icenowy]

Could you try to switch the ZRAM algorithm to zstd to try out?

 

This seems to be fixing issue when I try to port Armbian to PineCube.

[Hammy]

Thanks for the info, is there any work around?

 

Switching to zstd caused the same error and crashed the board while benchmarking. After a reboot: http://ix.io/2F3t  - Interestingly it says:

### Activated 1 lzo-rle zram swap devices with 491 MB each

 

While

root@orangepizero:~# zramctl

NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT

/dev/zram1 zstd        491,6M    4K    58B    4K       4 [SWAP]

/dev/zram0 zstd           50M  1,4M 184,1K  572K       4 /var/log

 

Daniel

[Icenowy]

@IgorSeems to be https://lore.kernel.org/linux-mm/20201105170249.387069-1-minchan@kernel.org/ .

 

By the way in mainline kernel the "fix" seems to be dropping ZSMALLOC_PGTABLE_MAPPING , see https://www.spinics.net/lists/stable/msg428110.html (it's already in linux-next).

[Hammy]

Awesome guys, when will the change be in the current build?

 

Out of curiosity: What is “ZSMALLOC_PGTABLE_MAPPING“ actually doing?