flipping frames bug and workaround
#11
Not sure if this helps, but I noticed that this bug happens most often when:
- PinePhone is charging, but slowly (~0.5W, I use a battery case from another smartphone)
- Terminal is open
- I am typing something

Seems to happen less if PinePhone is not charging at all, or is plugged into a decent charger (as opposed to a battery case)

This has happened on:
- Mobian+phosh - fairly often
- pmOS+phosh - occasionally, but interestingly, the terminal mode (vol- + power 3 times) worked, and I was able to restart phoc from there
- pmOS+sxmo - once
  Reply
#12
Thanks a lot for the workaround, zetabeta! The flipping frames bug was a recurring (and frustrating) issue on my OG PP. Applying the workaround above and downgrading mesa improved stability a lot. Thanks again!
  Reply
#13
(03-27-2023, 07:11 PM)Yaky Wrote: Not sure if this helps, but I noticed that this bug happens most often when:
- PinePhone is charging, but slowly (~0.5W, I use a battery case from another smartphone)
- Terminal is open
- I am typing something

Seems to happen less if PinePhone is not charging at all, or is plugged into a decent charger (as opposed to a battery case)

This has happened on:
- Mobian+phosh - fairly often
- pmOS+phosh - occasionally, but interestingly, the terminal mode (vol- + power 3 times) worked, and I was able to restart phoc from there
- pmOS+sxmo - once

you probably refer to powersaving bug, frequency is quite easy to replicate if that happens in your hardware.

i thought i start to talk about watts and amperes, because basic usb provides 0.5 amperes and 5 volts, which means 2.5 watts. but you probably see watts from power program or upower.

i tried quick test. i used basic charger, in this case 0.5A. powersaving bug seems to be equally likely. powersaving bug is annoying to replicate.

usb communication may have something to do this though.
  Reply
#14
Does megi's recent post https://xnux.eu/log/#080
have any bearing on this?
  Reply
#15
my views starts to be final at this point, unless something new comes up.

i start to recommend permanent fixes for distributions, until we know more.

basically, there is powersaving bug, which affect all pinephones, which is more difficult replicate. there is frequency change bug, which is easier to replicate, but some of the pinephones are affected. probably related to manufactiring series.

and warning, there are similar bugs, which may or may not have similar side-effects. some cases those can be circumvented by following kernel parameter. these bugs may be caused by excessive ram usage.

Code:
# kernel parameter
lima.sched_timeout_ms=3000

easy copy-paste

Code:
## file location example
## /lib/udev/rules.d/98-prevent-flipping-frames-bug.rules

## prevents powersaving of flipping frames bug
KERNEL=="1c40000.gpu", SUBSYSTEM=="platform", DRIVER=="lima", ATTR{power/autosuspend_delay_ms}="-1"
KERNEL=="1c40000.gpu", SUBSYSTEM=="platform", DRIVER=="lima", ATTR{power/control}="on"

## prevents frequency change of flipping frames bug
KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{min_freq}="432000000"
KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{max_freq}="432000000"
KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{target_freq}="432000000"

## may open new bugs, kernel parameter lima.sched_timeout_ms=3000 may be needed.
#KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{min_freq}="120000000"
#KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{max_freq}="120000000"
#KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{target_freq}="120000000"

## may open new bugs, kernel parameter lima.sched_timeout_ms=3000 may be needed.
#KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{min_freq}="312000000"
#KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{max_freq}="312000000"
#KERNEL=="1c40000.gpu", SUBSYSTEM=="devfreq", ATTR{target_freq}="312000000"


## prevents modem disapearrings and disconnections.

#ACTION!="add", GOTO="eg25_end-edit"
#SUBSYSTEM!="usb", GOTO="eg25_end-edit"
#DRIVER!="usb", GOTO="eg25_end-edit"
#ENV{DEVTYPE}!="usb_device", GOTO="eg25_end-edit"
#
## NOT Default attributes values
#ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/control}="on"
#ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/autosuspend_delay_ms}="3000"
#ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/wakeup}="enabled"
#ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/persist}="0"
#
## for pinepohne pro
##ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/persist}="0"
#
#LABEL="eg25_end-edit"

## end of modem preventions

command, which shows stuff.

Code:
# showing some parameters
echo cat /sys/class/devfreq/1c40000.gpu/trans_stat
cat /sys/class/devfreq/1c40000.gpu/trans_stat
echo cat /sys/class/devfreq/1c40000.gpu/min_freq
cat /sys/class/devfreq/1c40000.gpu/min_freq
echo cat /sys/class/devfreq/1c40000.gpu/max_freq
cat /sys/class/devfreq/1c40000.gpu/max_freq
echo cat /sys/devices/platform/soc/1c40000.gpu/power/autosuspend_delay_ms
cat /sys/devices/platform/soc/1c40000.gpu/power/autosuspend_delay_ms
echo cat /sys/devices/platform/soc/1c40000.gpu/power/control
cat /sys/devices/platform/soc/1c40000.gpu/power/control
echo cat /sys/devices/platform/soc/1c40000.gpu/power/runtime_suspended_time
cat /sys/devices/platform/soc/1c40000.gpu/power/runtime_suspended_time
echo cat /sys/module/lima/parameters/sched_timeout_ms
cat /sys/module/lima/parameters/sched_timeout_ms
  Reply
#16
new comments are going on:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8410#note_2216628
https://gitlab.com/postmarketOS/pmaports...1699204355

new comment suggest what i have been suspecting. frequency bug is a hardware issue, and some kind of design issue in hardware. still, i think it's different than powersaving issue.

there is a patch. i will start (re-)testing at some point, not immediately
  Reply
#17
Is this bug the reason why we cant have long(er) battery life or is this something different?
  Reply
#18
(12-21-2023, 08:07 AM)aular Wrote: Is this bug the reason why we cant have long(er) battery life or is this something different?

i think the answer is yes and no.

but i go with no side, because battery life was already bad before. doing those adjustments won't change that much worse. if suspend is used, i don't think it matters that much.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  poor call quality try flipping switch six D4rkh0rs3 0 1,552 05-12-2021, 12:09 PM
Last Post: D4rkh0rs3
  Importing vcf, country prefix problem workaround p1trson 3 4,996 12-02-2020, 09:29 AM
Last Post: cybercow

Forum Jump:


Users browsing this thread: 2 Guest(s)