flipping frames bug and workaround - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120) +--- Forum: General Discussion on PinePhone (https://forum.pine64.org/forumdisplay.php?fid=127) +--- Thread: flipping frames bug and workaround (/showthread.php?tid=17771) Pages:
1
2
|
flipping frames bug and workaround - zetabeta - 01-01-2023 flipping frames bug and workaround for mobian phosh with kernel 6.1. https://barrelmem.s3.eu-north-1.amazonaws.com/flippingframesbug/VID_20230101_003350-mobian-powersavingbug.mp4 i have concluded at this point that this bug is in two parts, powersaving part and frequency change part. practically all gnu/linux distributions and plasma and phosh are affected. powersaving part seems to be more straightforward and more rare. this can be avoided by following. Code: # udev rule powersaving part is harder to replicate. you need some screen activity with some networking activity and possible cpu activity, it is not immediate. frequency change part can by avoided by following: Code: # udev rule however, in my situtation, frequency bug happens only in 1.2a hardware version and not in 1.2b. so i don't rule out possible hardware problem in 1.2a version or my specfic individual phone. if you tech savvy enough and you have pinephone regular. could you test frequency part of this bug and say your hardware version (1.2 1.2a 1.2b etc). you only set powersaving part, then run glxgears in user interfaces without auto suspend, sreenlocks and screen saving. then run following script in background. Code: while true generic copy paste: Code: # udev rule. this prevent flipping frames bug log file is for mobian phosh. RE: flipping frames bug and workaround - zetabeta - 01-11-2023 now i have tested two 1.2a hw phones and both have frequency part of the bug. i start to think there is something fishy going on in hardware chips in case of frequency changes of gpu. fedora f38 with "megi-kernel-pboot" 6.0.7 kernel does not crash for frequency changes, even in 1.2a. fedora does crashes for powersaving parts though (at least in the past). RE: flipping frames bug and workaround - zetabeta - 01-16-2023 i have tested (further) two pinephones of 1.2a version for frequency bug, using archlinux plasma, glxgears in u.i. and gpu frequency changing script. older pinephone crashes only if i flip from 432MHz to 312MHz. newer pinephone crashes both 423MHZ <> 312MHZ and 432MHZ <> 120MHZ. however not in 312MHZ <> 120MHZ. (powersaving bug is different and both hw versions crash, 1.2a and 1.2b. it is also more difficult to replicate) Code: [root@danctnix ~]# pacman -Si mesa some log Code: [ 222.596592] lima 1c40000.gpu: mmu page fault at 0x4d200c0 from bus id 0 of type read on ppmmu0 script for displaying info Code: echo cat /sys/class/devfreq/1c40000.gpu/trans_stat example of frequency changing script Code: echo 432000000 > /sys/class/devfreq/1c40000.gpu/min_freq RE: flipping frames bug and workaround - zetabeta - 02-12-2023 i forgot this link: https://gitlab.com/postmarketOS/pmaports/-/issues/805 how to reproduce powersaving bug: this is more difficult to replicate. what i know all pinephones are affected. default settings are applied for gpu pwersaving. some kind of visible script is run on screen, which uses gpu somewhat, but in a way that gpu goes to powersaving for awhile. on a background, maybe ssh, one runs something which consumes networking and cpu power. mobile data and ethernet is more likely to reproduce this bug, but wifi is less likely. this may take hours. Code: # udev rule. this prevents frequency part only how to reproduce frequency bug: only some pinephones are affected. fedora (dirty) kernel is/was not affected for frequency part). isome settings for gpu needs to be initiated, because powersaving should be ruled out. something needs to be done a screen, maybe glxgears. on a background like ssh, frequency change script is run. crash probably happens in minutes. Code: # udev rule. this prevents powersaving part only Code: # stupid bash script to forcibly change frequency at all time frequency bug happens only in some pinephones, so i ask, can you test frequency part in your pinephone, and also report hardware version. https://wiki.pine64.org/wiki/PinePhone#Hardware_revisions i put this thread for wider discussion about mali gpu and a driver for it. does mali chip have some deficiencies? has anyone some knowledge what's going on in lima driver? why some devices are affected and others aren't? is frequency change reliable? even related information could be helpful. RE: flipping frames bug and workaround - e1337 - 02-15-2023 I have this happen on 1.2b (Manjaro Edition 3GB), although I don't know what trigger (power saving or frequency change). It seems to happen when there's some sort of high CPU and moderate to high network use situation, e.g. it happens sometimes when I launch multiple apps at once with some already running that use the internet. Somehow, the combined activity of all the launches just makes it trip over something. Edit: actually I transferred a mainboard once but I forgot if it was for this one, so it could also be 1.2a (but not older), if someone knows how to check via software let me know RE: flipping frames bug and workaround - zetabeta - 02-16-2023 (02-15-2023, 09:54 AM)e1337 Wrote: I have this happen on 1.2b (Manjaro Edition 3GB), although I don't know what trigger (power saving or frequency change). It seems to happen when there's some sort of high CPU and moderate to high network use situation, e.g. it happens sometimes when I launch multiple apps at once with some already running that use the internet. Somehow, the combined activity of all the launches just makes it trip over something. Edit: actually I transferred a mainboard once but I forgot if it was for this one, so it could also be 1.2a (but not older), if someone knows how to check via software let me know i cannot help much for checking hw version. one could use "lshw", but this command does not show sub versions, in this case, 1.2, 1.2a or 1.2b. (lshw probably needs to be installed first.) "journalctl -r" also works, if you search correct place near boot up, but this also is inaccurate. i do not recoomend opening directly, but one number may provide clue for what version you have. number is above pogo pins. if it is just "C", i think mainboard is 1.2b. if there is a date, date probably indicates production date. picture is for 1.2a. however, i cannot accurately know what number means. just for pre-emptive warning, if you or others post pictures, pixelize imei codes and similar. RE: flipping frames bug and workaround - zetabeta - 03-01-2023 i went on bug reporting spree. https://gitlab.freedesktop.org/mesa/mesa/-/issues/8415 https://gitlab.freedesktop.org/mesa/mesa/-/issues/8410 RE: flipping frames bug and workaround - alaraajavamma - 03-02-2023 I haven't faced this problem anymore with Manjaro Phosh Beta 29. Or more precise (I think) after Manjaro updated to Mesa 22.3.5 This use to be nearly daily issue and now I have not seen it once for many many days - maybe over 20 days or something? RE: flipping frames bug and workaround - zetabeta - 03-02-2023 (03-02-2023, 09:31 AM)alaraajavamma Wrote: I haven't faced this problem anymore with Manjaro Phosh Beta 29. if you refer to this bug https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198 , i think, this is totally different issue. i encountered this bug as well, but it was already reported and fixed soon, i didn't put much attention to it. btw, i already crashed manjaro with mesa 22.3.5. RE: flipping frames bug and workaround - zetabeta - 03-21-2023 most likely these are the same bug. https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64-linux/-/issues/65 https://gitlab.freedesktop.org/mesa/mesa/-/issues/8415 |