search

debauchee / barrier

Open-source KVM software
Other
27.68k stars 1.52k forks source link

Flashing/Blanking on raspberrypi #867

Open joshuacox opened 4 years ago

joshuacox commented 4 years ago

Describe the bug As I move the cursor back and forth from my desktop to the pi the pi's screen will flash a blank (black) screen for a second. Eventually it will fail to recover from this and sit blankly forever. The odd thing is that if I ssh into the pi everything appears to be running normally, I can even restart gdm (systemctl restart gdm) but the screen stays blank. Eventually I will give up and reboot the pi, at this point it will eject me from the ssh session, but it will freeze for several minutes (enough that early on I would pull the power from the pi and plug it back in), but eventually it will reboot. Uncertain as to what it's doing at this point as I can't ssh in and the screen is still blank.

To Reproduce

Steps to reproduce the behavior: This one is inconsisten so replicating is not guaranteed, move your mouse back and forth between desktops, doing a circle between the desktops and just continuously jumping back and forth does not seem to trigger this, there needs to be a delay between jumps.

Expected behavior Normal no-flashes barrier usage.

Screenshots Blank screenshot.

Desktop (please complete the following information):

shymega commented 4 years ago

Can you check memory usage before the reboot? Wondering if its related to the oom killer.

joshuacox commented 4 years ago

Of note this is an rpi4 with 4GB of ram, and at time of reboot over 2GB of ram available:

quattro :: ~ % free -m                                                                                                                                                                                                                       
              total        used        free      shared  buff/cache   available
Mem:           3647         389        2199         527        1058        2689
Swap:             0           0           0

EDIT: adding in /boot/config.txt in which I changed gpu_mem to 256 in my attempts to give the video driver some more memory: 

# See /boot/overlays/README for all available options

gpu_mem=256

initramfs initramfs-linux.img followkernel

# uncomment to force a console size. By default it will be display's size minus
# overscan.
framebuffer_width=1920
framebuffer_height=1080
disable_overscan=1
dtoverlay=vc4-kms-v3d-pi4

barrier is being automatically started like so:

quattro :: ~ % cat .xprofile                                                                                                                                                                                                                 
#!/bin/sh
touch /tmp/xprofile_started
date -I > /tmp/xprofile_started
barrierc --log /tmp/barrierc.log --daemon --enable-crypto flux

Of note the log file is not ever created in /tmp, maybe this is because barrier has nothing to log? (adding the --debug flag to see if that helps)

joshuacox commented 4 years ago

@shymega after not getting any results in my logs I changed the debug level to DEBUG2

barrierc --debug DEBUG2 --log /tmp/barrierc.log --daemon --enable-crypto flux 1>/tmp/barrierc1.log 2>/tmp/barrierc2.err

Here are what those files look like after triggering a frozen blank screen state:

~ » tail -f /tmp/barrierc*
==> /tmp/barrierc1.log <==
[2020-09-07T10:44:30] DEBUG1: logging to file (/tmp/barrierc.log) enabled

==> /tmp/barrierc2.err <==

==> /tmp/barrierc.log <==
[2020-09-07T10:44:30] DEBUG1: logging to file (/tmp/barrierc.log) enabled

still plenty of RAM available (and this was taken during one of the frozen to blank screen states)

free -m
              total        used        free      shared  buff/cache   available
Mem:           3647         298        2485         399         863        2908
Swap:             0           0           0

gdm appears to be fine:

sudo systemctl status gdm                                                                                                    1 ↵
● gdm.service - GNOME Display Manager
     Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-09-07 10:44:04 CDT; 5min ago
   Main PID: 311 (gdm)
      Tasks: 3 (limit: 4915)
     CGroup: /system.slice/gdm.service
             └─311 /usr/bin/gdm

Sep 07 10:44:04 quattro systemd[1]: Starting GNOME Display Manager...
Sep 07 10:44:04 quattro systemd[1]: Started GNOME Display Manager.
Sep 07 10:44:04 quattro gdm-autologin][335]: pam_systemd_home(gdm-autologin:account): systemd-homed is not available: Unit dbus-org.freedesktop.ho>
Sep 07 10:44:04 quattro gdm-autologin][335]: pam_unix(gdm-autologin:session): session opened for user thoth(uid=1001) by (uid=0)

And restarting gdm has no effect.

Looking around in htop gnome-shell is using 10.6% of ram which seems about right, and nothing else is taking up much CPU or memory. I have also tried this with other window managers, including i3 which is quite minimal, to the same results.

tsanyqudsi commented 3 years ago

@joshuacox i don't know if you still having this problem. But I have this problem too.

I "fixed" it with overclocking my Raspberry Pi 4 8GB. You might want to read https://qengineering.eu/overclocking-the-raspberry-pi-4.html for the explanation.

I use arm_freq = 1750 and over_voltage = 2 for my Raspi but 1650 / 1700 seems tolerable.

Please keep in mind that the temperature would be increasing due to overclocking. My Raspi temp rose from37-38 C to 42-43 C on idle using Argon case.

pascal-fb-martin commented 2 years ago

I have a similar issue on Debian bookworm/sid (and AMD Ryzen 5 5600): when the cursor moves from a Windows 10 (acting as client) to a Linux screen (acting as server) then the Linux screen goes entirely black for 1-2 seconds.