[ROM][testing][suez] Lineage-16.0 [05 JULY 2022]

[Klaus R]

Strange. This morning even duckduckgo won't show up vids... Yesterday it did....

 

[psi78]

Strange. This morning even duckduckgo won't show up vids... Yesterday it did....

I think it may have to do with the sometimes happening cpu overload of SurfaceFlinger. I played around with Firefox and at one point i could play the videos fine with Firefox, but everything felt kinda sluggish and at other times the video was distorted like in the Screenshot i posted.

 

[Klaus R]

I think it may have to do with the sometimes happening cpu overload of SurfaceFlinger. I played around with Firefox and at one point i could play the videos fine with Firefox, but everything felt kinda sluggish and at other times the video was distorted like in the Screenshot i posted.

Hmm, ok. If I can distribute in any way to analyze or even solve that issue.... But i'm afraid my expierience is not wide enough

 

[psi78]

Hmm, ok. If I can distribute in any way to analyze or even solve that issue.... But i'm afraid my expierience is not wide enough

Did a clean reinstall oft current suez rom 20220506, no magisk, no gapps, activated power saving, installed Android system webview manually, also duckduckgo Browser, matlog and fennec. In fennec i set the prevent tracking mode to normal (not strict) and activated Storage access for Fennec manually in APP settings. I could play videos then. Interestingly Fennec also crashed and put a crash dump into logcat file, pointing to /system/vendor/lib64/egl/libGLESv2_POWERVR_ROGUE.so

@ggow when looking at this chart

2D and Accelerator

2D and Accelerator

www.slideshare.net

possibly SurfaceFlinger itself is not the culprit but maybe SurfaceFlinger trying to access already deregistered Buffers, leading to high CPU usage because of compositing surfaces anew instead of utilizing the buffer. So possibly the gralloc, libegl, libgles, or liboverlay libraries have a malfunction.

 

[likwidchz]

Did a clean reinstall oft current suez rom 20220506, no magisk, no gapps, activated power saving, installed Android system webview manually, also duckduckgo Browser, matlog and fennec. In fennec i set the prevent tracking mode to normal (not strict) and activated Storage access for Fennec manually in APP settings. I could play videos then. Interestingly Fennec also crashed and put a crash dump into logcat file, pointing to /system/vendor/lib64/egl/libGLESv2_POWERVR_ROGUE.so

@ggow when looking at this chart

2D and Accelerator

2D and Accelerator

www.slideshare.net

possibly SurfaceFlinger itself is not the culprit but maybe SurfaceFlinger trying to access already deregistered Buffers, leading to high CPU usage because of compositing surfaces anew instead of utilizing the buffer. So possibly the gralloc, libegl, libgles, or liboverlay libraries have a malfunction.

Neat find, I'm a new person here. Been trying different versions of Lineage OS as the latest MAY release made my processing.org sketch slow slow.

lineage-16.0-20220301-UNOFFICIAL-suez.zip ~55 FPS
lineage-16.0-20220506-UNOFFICIAL-suez.zip ~22 FPS = Sad Panda.

I also found that the surface flinger app was using lots of CPU when I ran TOP. Hopefully you folks can get to the bottom of it!

**Edit, my processing.org app is drawing lots of shapes, animations on screen. lots of 2D items happening.

 

[psi78]

@ggow Just noted when looking at the malfunctioning LiveDisplay Service
/system/etc/init/lineage-livedisplay.rc

that this service tries to make changes to
/sys/devices/virtual/graphics/fb0

whereas in the current state of the rom
/sys/devices/virtual/graphics
and fb0 as framebuffer device doesn't exist,

instead there is a
/sys/devices/virtual/pvr
directory though, but don't know where a frambuffer device like fb0 is there

Why is the FrameBuffer missing on some Android devices? - Sample Code and Directory of libraries for Android Developers - AndroidHiro.com

Why is the FrameBuffer missing on some Android devices?.Im curious about the display device on Android. I know that on Linux, device devices are represented as /dev/fbX, which "fb" stands for FrameBuffer. I also heard that Android uses FrameBuffer as wellin Android it’s /dev/graphics/fbX...

www.androidhiro.com

mentions how to create a framebuffer on android but it uses the path
/dev/fb0

So for a virtual device - not sure what would be needed to enable that

Edit: this page mentions though that virtual framebuffer should be enabled only for testing purposes, wondering why LOS LiveDisplay Service needs it then
or how to check if kernel framebuffer works correctly: https://cateee.net/lkddb/web-lkddb/FB_VIRTUAL.html

Edit: ok, virtual devices are for using android emulator apparently and /dev/graphics/fb0 is created during runtime while dev is tmpfs partition

 

[Creeju]

Just installed the latest 20220506-build on my tablet, using TWRP 3.6.1-9.2.

Some notes:
Magisk install via TWRP always resulted in a bootloop. The only way I got Magisk working, is patching boot.img. It will complain about the abundant su-library, but should work fine with LineageOS-su turned off in developer settings.
NanoDroid will not work without Magisk, due to the small system partition size (in standard config with all the apps).

Thank you so much for the work and the rom! Will start testing now.

 

[psi78]

Did a clean reinstall oft current suez rom 20220506, no magisk, no gapps, activated power saving, installed Android system webview manually, also duckduckgo Browser, matlog and fennec. In fennec i set the prevent tracking mode to normal (not strict) and activated Storage access for Fennec manually in APP settings. I could play videos then. Interestingly Fennec also crashed and put a crash dump into logcat file, pointing to /system/vendor/lib64/egl/libGLESv2_POWERVR_ROGUE.so

@ggow when looking at this chart

2D and Accelerator

2D and Accelerator

www.slideshare.net

possibly SurfaceFlinger itself is not the culprit but maybe SurfaceFlinger trying to access already deregistered Buffers, leading to high CPU usage because of compositing surfaces anew instead of utilizing the buffer. So possibly the gralloc, libegl, libgles, or liboverlay libraries have a malfunction.

I get repeated errors from IMGSRV and gralloc reporting a broken pipe. See Screenshot,
so maybe it would be helpful to trace I/O for gralloc, surfaceflinger. Don't know how to do that though other than potentially using Android SDK and the Rom in Android Emulator, enable a trace and analyze it

 

[likwidchz]

I get repeated errors from IMGSRV and gralloc reporting a broken pipe. See Screenshot,
so maybe it would be helpful to trace I/O for gralloc, surfaceflinger. Don't know how to do that though other than potentially using Android SDK and the Rom in Android Emulator, enable a trace and analyze it

Can you compare one release to another? Perhaps if you did that you could compare with what changed..

Not sure if thats how you would do it, or technically how much stuff changes between one version and another... but ideas.

 

[psi78]

Can you compare one release to another? Perhaps if you did that you could compare with what changed..

Not sure if thats how you would do it, or technically how much stuff changes between one version and another... but ideas.

Those gralloc errors occured also with 20220413
Back in the times when i used 20220301 worked kinda fine in some regards, though it had massive battery performance drain sometimes, don't know if those gralloc errors occured also there, but i guess it. Some other changes of the rom probably in the meantime (blob libraries i guess), of which only ggow probably knows.

Interesting thing is though that for ROM version 20220506 CPU2 and CPU3 (which have the high cpu usage malfunction errors) dmesg shows errors like this (which i didn't see in 20220413, but may depend on the boot state - 20220413 and i think also 20220301 had no problems after cold boot, but after reboot):
[ 2251.278622] -(2)[0:swapper/2]SANITY CHECK: Unexpected variation in id_mmfr0. Boot CPU: 0x00000010101105, CPU2: 0x00000010201105
[ 2251.280158] -(3)[0:swapper/3]SANITY CHECK: Unexpected variation in id_mmfr0. Boot CPU: 0x00000010101105, CPU3: 0x00000010201105

Apparently these errors are a sign for mismatching CPU features in version 20220506 of the ROM.
See also https://patchwork.kernel.org/[email protected]/

Edit:
I tested the ROM versions 20220301 / 20220316 / 20220406 / 20220413 / 20220506 with Passmark Performance Test app from Playstore, and Power Saving mode enabled:
2D score was 9089 / x / 15786 / 16712 / 17150 respectively. (x: Passmark 2D didn't work with 20220316)
CPU Score was 912 / x / 1390 / 1398 / 1482 respectively.

So latest version of the rom had the best performance overall (in that benchmark at least).
But not when CPU2 was hogged by SurfaceFlinger in idle mode with 20220301 or 20220506 version of the rom (mostly occuring with Power Saving off in idle mode), the Passmark CPU score was like 900-1000, so worse then.
The interesting thing is (tested with current ROM 20220506):
After running the "Unreal System Benchmark" from Playstore, exiting that app, then restarting "Passmark Performance Test" the 2D score of passmark goes down to like ~6000 (!) compared to ~17000 before, and CPU2 and CPU3 are at full throttle in idle mode then, and Passmark CPU score goes down to like 600 compared to 1400 before. This didn't happen everytime though and i had the impression with Power Saving on the risk was less.

Your best bet at the current state of the rom is:
Enable Power Saving mode to minimize the risk of the CPUs getting hogged by SurfaceFlinger (for whatever reason).
And before you continue doing anything after startup, check with a program like CPU info if the CPU cores 2 and 3 are powering down normally.

Edit: Also tested 20220301 and 20220316 (see above)

 

[likwidchz]

Those gralloc errors occured also with 20220413
Back in the times when i used 20220301 worked kinda fine in some regards, though it had massive battery performance drain sometimes, don't know if those gralloc errors occured also there, but i guess it. Some other changes of the rom probably in the meantime (blob libraries i guess), of which only ggow probably knows.

Interesting thing is though that for ROM version 20220506 CPU2 and CPU3 (which have the high cpu usage malfunction errors) dmesg shows errors like this (which i didn't see in 20220413, but may depend on the boot state - 20220413 and i think also 20220301 had no problems after cold boot, but after reboot):
[ 2251.278622] -(2)[0:swapper/2]SANITY CHECK: Unexpected variation in id_mmfr0. Boot CPU: 0x00000010101105, CPU2: 0x00000010201105
[ 2251.280158] -(3)[0:swapper/3]SANITY CHECK: Unexpected variation in id_mmfr0. Boot CPU: 0x00000010101105, CPU3: 0x00000010201105

Apparently these errors are a sign for mismatching CPU features in version 20220506 of the ROM.
See also https://patchwork.kernel.org/[email protected]/

Edit:
I tested the ROM versions 20220301 / 20220316 / 20220406 / 20220413 / 20220506 with Passmark Performance Test app from Playstore, and Power Saving mode enabled:
2D score was 9089 / x / 15786 / 16712 / 17150 respectively. (x: Passmark 2D didn't work with 20220316)
CPU Score was 912 / x / 1390 / 1398 / 1482 respectively.

So latest version of the rom had the best performance overall (in that benchmark at least).
But not when CPU2 was hogged by SurfaceFlinger in idle mode with 20220301 or 20220506 version of the rom (mostly occuring with Power Saving off in idle mode), the Passmark CPU score was like 900-1000, so worse then.
The interesting thing is (tested with current ROM 20220506):
After running the "Unreal System Benchmark" from Playstore, exiting that app, then restarting "Passmark Performance Test" the 2D score of passmark goes down to like ~6000 (!) compared to ~17000 before, and CPU2 and CPU3 are at full throttle in idle mode then, and Passmark CPU score goes down to like 600 compared to 1400 before. This didn't happen everytime though and i had the impression with Power Saving on the risk was less.

Your best bet at the current state of the rom is:
Enable Power Saving mode to minimize the risk of the CPUs getting hogged by SurfaceFlinger (for whatever reason).
And before you continue doing anything after startup, check with a program like CPU info if the CPU cores 2 and 3 are powering down normally.

Edit: Also tested 20220301 and 20220316 (see above)

You are over my head man Just getting into this and understanding things. I just hope someone figures it out, which I'm sure they will at some point.

Take care,

 

[luk2009]

Hi

Is there any update planned for this rom?

my tablet work fine except for the youtube video zoom and the random netflix crack .


thanks in advance

 

[likwidchz]

Hi

Is there any update planned for this rom?

my tablet work fine except for the youtube video zoom and the random netflix crack .


thanks in advance

Have you tried older roms?

lineageos - Google Drive

drive.google.com

**Not my link.

I have some lineage 14 and 12 roms also, currently trying the 12 rom out now.
Lineage-12.1-20200505-UNOFFICIAL-suez.zip

As old as it is, it seems to work, but I'm only using it for one thing and that's a custom processing.org sketch. All other versions of lineage seem to run really mixed framerates due to that surface flinger process gobbling up a bunch of CPU.

One of the older posts mentioned that one of the cores just keep using high cpu.

I'm wondering if it can be fixed with an adb command at boot or something.

 

[ggow]

New Build is Up
Dated: 05 July 2022

- [fixed] Backlight HAL Errors
- [fixed] LiveDisplay not working

 

[Nosepull]

Thanks for updating. Is Magisk working again with this version?

 

[ggow]

Thanks for updating. Is Magisk working again with this version?

I haven't tried it, but it should work. Let me know how you get on.

 

[tuniel]

New Build is Up
Dated: 05 July 2022

- [fixed] Backlight HAL Errors
- [fixed] LiveDisplay not working

thanks for the update!
heads up: the file size is about 10MB larger than before, hence even with pico gapps there is not enough space in the system partition. i removed the stock email and calendar to make some room.
thanks

 

[Nosepull]

thanks for the update!
heads up: the file size is about 10MB larger than before, hence even with pico gapps there is not enough space in the system partition. i removed the stock email and calendar to make some room.
thanks

Which would mean that any update with GApps should fail?!

 

[tuniel]

Which would mean that any update with GApps should fail?!

That's indeed what I experienced. I wiped system, cache and davlik. Then installed rom, rebooted to recovery, installed gapps and got error 70.

 

[Nosepull]

That's indeed what I experienced. I wiped system, cache and davlik. Then installed rom, rebooted to recovery, installed gapps and got error 70.

Thanks for the warning.