[SOLVED] X freezes on RPi4 running slackwareaarch64
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I know I said I was going to wait for the next kernel. I had some free time this weekend and did some research. I read every bit of documentation on the Raspberry Pi and was able to clarify a few things for myself about the config.txt.
Normally I can trigger a freeze by opening any video on the desktop while multitasking. In the attached screen shot you will notice my video settings, compositor is on in Xfce, and Glxgears is rendering. I had about 20 minutes of good video and then I launched Firefox. Freeze. The sound continues in the video while the screen is frozen. It must be something to do with hardware acceleration in Firefox.
I wanted to test video playback using this video in hopes that we can all test with the same media. To try to have less variables in play while testing. It is hosted on my site so feel free to download it to test and stream it to test.
Video URL: https://exitstatus.one/wp-content/up...rpi3_build.mp4
gpu_mem does not need to be set for the Pi 4. I loaded the rpivid overlay. Booted with the experimental dtb for the board. Finally, since we do not have the H265 library in Slackware (on SlackBuilds.org), I commented out hdmi_enable_4kp60. Without H265 (at least the way I understand it), the Pi is not capable of 4K.
#########################################################################
# File...: /boot/platform/hwm_bw/config.txt Purpose: Configuration file for the RPi first stage Boot Loader.
# * Handles Flattened Device Tree (and Overlays) and various
# hardware settings.
# * Chain loads the 2nd-stage U-Boot loader, which boots the
# Linux Kernel and Slackware OS.
# Date...: 22-Dec-2021
#########################################################################
# Notes
# [1] This file is not actively managed by the Slackware OS.
# It's statically created by the sdcards.build script:
# http://ftp.arm.slackware.com/slackwarearm/platform/aarch64/bootware/src/sdcards.build
# [2] The Linux Kernel and Slackware OS configuration is found within
# the Slackware OS here:
# /boot/extlinux/extlinux.conf
# [3] For detailed information about this configuration file and the possible
# configuration directives, see:-
# https://www.raspberrypi.com/documentation/computers/config_txt.html
#########################################################################
# Raspberry Pi4/400 settings:
[pi4]
# Assign 128MB of RAM to the GPU:
#gpu_mem=128
# Enable DRM VC4 V3D driver on top of the dispmanx display stack:
# https://github.com/raspberrypi/linux/issues/4392
#dtoverlay=vc4-kms-v3d-pi4
#dtoverlay=vc4-fkms-v3d
#dtoverlay=vc4-fkms-v3d-pi4,cma-512
#dtoverlay=vc4-kms-v3d,cma-384
dtoverlay=vc4-kms-v3d
dtoverlay=rpivid-v4l2
max_framebuffers=2
#hdmi_enable_4kp60=1
# Interested in overclocking options?
# See: https://www.raspberrypi.com/news/introducing-turbo-mode-up-to-50-more-performance-for-free/
#
# Experimental for RPi4 model B:
device_tree=bcm2711-rpi-4-b.dtb
# Raspberry Pi400 settings. These would override those configured
# for all RPi4 models.
#[pi400]
# Raspberry Pi3 settings:
[pi3]
device_tree=bcm2837-rpi-3-b.dtb
# Raspberry Pi3+ settings:
[pi3+]
device_tree=bcm2837-rpi-3-b-plus.dtb
# General settings for Raspberry Pi Hardware Models:
[all]
arm_64bit=1
enable_uart=1
disable_fw_kms_setup=1
upstream_kernel=1
# For the VC4 driver (according to the help text within the
# Kernel configuration!)
avoid_warnings=2
# Chain load the 2nd stage U-Boot Boot Loader.
kernel=slk_u-boot.bin
#########################################################################
# Device Tree Overlays
# See the README /boot/platform/hwm_bw/overlays/README
# (Note: this 'README' is from the RPi Bootware repository)
#########################################################################
# Real Time Clocks on the I2C bus (connected to the GPIO pins):
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
#dtoverlay=i2c-rtc,ds1307
#dtoverlay=i2c-rtc,pcf85063
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
A couple of quick comments: x264 and x265 are both available in Slackbuilds, and neither come with Slackware as standard. x265 is trivially easy to build. 4K is "usually" x265, as this helps keep the file size down, but it can equally easily be stored as x264.
Having a 4K monitor (Its shared with my main desktop which I use for video editing), if I *don't" enable 4kp60, I get complaints in dmesg about not being able to to clock the gpu fast enough - even though my monitor can only manage 30fps maximum, not 60 fps.
At the moment, I'm a bit stuck! After one crash too many, I am now unable to get into X at all, either from sddm or the command line. Something clearly got corrupted quite badly in the last crash, and I suspect the only solution is going to be yet another full install. This may take a day or two, depending on other commitments. Grrr!
BTW, I frequently have issues with Firefox playing videos on my desktops (x86_64). On my old workshop machine, for some reason playing stuff off youtube will cause the network to drop out, and I need to restart rc.inet1. On my main (editing) desktop it sometimes causes interruptions to file transfers. For all my video testing I've been using either VLC or mpv/smplayer. VLC allegedly now defaults to hardware acceleration, but this can only happen if its already available. Looking at the clunkiness of the X desktop, I'm not convinced that it is!
A couple of quick comments: x264 and x265 are both available in Slackbuilds, and neither come with Slackware as standard. x265 is trivially easy to build. 4K is "usually" x265, as this helps keep the file size down, but it can equally easily be stored as x264.
Having a 4K monitor (Its shared with my main desktop which I use for video editing), if I *don't" enable 4kp60, I get complaints in dmesg about not being able to to clock the gpu fast enough - even though my monitor can only manage 30fps maximum, not 60 fps.
My mistake! Yeah, I don't know why I missed the "SBo" tag in my x264 package. Either way, I think it is still better to leave 4k disabled. Not everyone has a 4k monitor.
Quote:
At the moment, I'm a bit stuck! After one crash too many, I am now unable to get into X at all, either from sddm or the command line. Something clearly got corrupted quite badly in the last crash, and I suspect the only solution is going to be yet another full install. This may take a day or two, depending on other commitments. Grrr!
BTW, I frequently have issues with Firefox playing videos on my desktops (x86_64). On my old workshop machine, for some reason playing stuff off youtube will cause the network to drop out, and I need to restart rc.inet1. On my main (editing) desktop it sometimes causes interruptions to file transfers. For all my video testing I've been using either VLC or mpv/smplayer. VLC allegedly now defaults to hardware acceleration, but this can only happen if its already available. Looking at the clunkiness of the X desktop, I'm not convinced that it is!
I remove the SSD and SD card from my Pi 4 and run fsck on another machine after each freeze. Then I boot it back up knowing nothing is corrupted. I may not be that well versed in video decoding (i.e. x264/x265), but I do know networking. The network issue is more than likely something else. I would open a new thread in the main Slackware forum so we can keep this one on topic.
Yes, I've been checking the sd card on my desktop too, but it hasn't fixed it. Funny thing is though, that after leaving it off overnight, today it booted into X as if nothing had ever been wrong! Of course, following the inevitable crash, it refused to start X again - UNTIL - I put the Librelec sd card in! When I swapped back again, X was working once more - for a while, anyway!
I *may* have an explanation for this behaviour. You see Slackwareaarch64 does not shutdown properly on the 400. It always ends up unresponsive, and with the graphics chip still running, but nothing else. Since reboot is part of the same command, I don't think its rebooting properly either. I think that either halting or rebooting is leaving garbage in memory, possibly the same garbage that is causing the crash in the first place. Could this be a memory leak over-writing something it shouldn't (causing the crash), and then not getting cleared away by halt or reboot? Feels plausible!
At the moment I'm back to not having X at all again, but I know that if I wait long enough - or reboot into another system - it will probably magically re-appear!
Well, I've done a bit more playing and yes, the sd card is getting corrupted by the crashes - even when I ssh in and try to shut it down remotely.
Just for a laugh, I thought I'd try starting wayland instead of X. That produced yet another instant crash.
Frankly, it looks as if there is something fundamentally wrong with the way that slackwareaarch64 is handling the graphics drivers. Fault-finding this is getting way above my pay-grade!
For the moment, I'm giving up. Slarm64 continues to perform well on the same hardware, so I'm sticking with that for the time being. I'll revisit when there is a big upgrade to the X system / graphics drivers.
OK, this is interesting. I tried installing all the latest updates, and checked the filesystems for corruption. On rebooting, I managed to get into X (briefly!) and run the kde info centre. It reported the graphics driver as "llvmpipe", before it froze solid again.
Rebooting into Slarm64, the info centre reports the graphics driver to be "V3D 4.2" - which is what I would expect!
Why is slackwareaarch64 running graphics in what appears to be a virtual environment? Is this intentional? I see lots of reports of Ubuntu users with NVidia graphics cards having similar issues, with llvmpipe suddenly taking over from the NVidia drivers without warning - to the severe detriment of performance.
I also note that when attempting to shutdown slackwareaarch64, one of the last messages I see before the system freezes is something about "exiting kvm" - which again suggests the presence of a virtual machine.
There is not anything wrong with the video stack in Slackware ARM or Aarch64. The Pinebook Pro and RockPro64 play video just fine. If there was an issue it would be present on all hardware models.
What needs to happen is for the video drivers (vc4, v3d) to be fully implemented in the Linux kernel. There are patches out there that do this but those patches are not maintained and are outdated. The kernel fails to build with those patches when the v3d driver is compiled.
Say I publish this work, after fixing up those patches, and video starts working for a time. Great! Who is going to maintain those patches in the long run, in future kernels? It makes more sense to wait until upstream has support for the Raspberry Pi sorted out. To me it doesn't make sense to get the drivers functioning if it means a new patch must be created for every kernel release/point release.
Last edited by mralk3; 05-13-2022 at 09:32 AM.
Reason: typo
I've often thought that people who buy RPis and want to run something other than their own OS, could go about press ganging the RPi company to get their hardware support upstreamed much more quickly. That'd really help not just Slackware but all of the other distributions.
OK, but why is my installation of slackwareaarch64 using this "llvmpipe" driver? Why is it not running the "V3D 4.2" driver, which is what the dbtoverlay suggests it should be running?
From what I've been able to find out from google, "llvmpipe" is a software renderer noted for its poor performance in many environments. It seems to mostly affect Ubuntu users with NVidia drivers, which it usurps, leaving them with poor graphics performance. Sound familiar?
As a matter of interest, what does
Code:
glxinfo | grep render
give on your machine? Do you see V3D or llvmpipe?
The V3D drivers do work. Unfortunately, on my system, they seem to have been taken over by llvmpipe! How do I get them back?
Some more information, hopefully trying to get to the bottom of this.
First of all the GLX renderer:
Code:
PiOS ## X is stable, 720 video plays fine, 1080 video plays but with high cpu load, 4K video (x265) does not play.
glxinfo | grep renderer
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: V3D 4.2
Slarm64: ## X is stable, 720 video plays fine, 1080 video plays but with high cpu load, 4K video (x265) does not play.
glxinfo | grep renderer
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_NV_float_buffer,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: V3D 4.2
Slackwareaarch64: ## X is unstable and crashes frequently, also takes a long time to load. 720 video just about plays with high cpu load, but nothing higher.
glxinfo | grep renderer
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_NV_float_buffer,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_OML_swap_method,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 13.0.1, 128 bits)
Unfortunately Libreelec doesn't have sufficient tools to create a similar output (no GLX tools). However, it plays 4K video with no issues at all.
Looking back into dmesg on Slackwareaarch64, I find this:
I cannot start X from sddm - it goes to a blank screen (no output) and stays there. From the command line, startx does get X up and running after a (very) long pause. The above dmesg output indicates that although the vc4 driver loads OK initially (framebuffer mode), as soon as I attempt to start X, it borks and drops back to llvmpipe.
Note in particular that rpivid_hevc module, which, I'm guessing, is why it can play back 4K - despite the command being missing from config.txt.
However, none of this helps with the basic problem, which is that the vc4 driver is borking badly.
I am going to try doing a complete, clean re-install and see if that helps. It could be that because of the crashes something has got damaged in the installation, but at the moment I see no other way forward.
UPDATE: Did a completely fresh install, everything verified, rebooted, adduser, reboot, login as user (command-line), startx - instant crash. Keyboard locked solid, no video output. Had to login via ssh to shutdown.
--
Pete
Last edited by pchristy; 05-15-2022 at 09:41 AM.
Reason: UPDATE
The upstream kernel has poor support. Kernel.org is upstream. The Raspberry Pi developers need to send their fixes up the pipeline. Slackware is not the only Linux distribution that suffers from poor video performance on the Raspberry Pi. My interest is for Slackware and not for other distributions.
Good news is that the Raspberry Pi 3 is working fine and glxinfo reports VC4 V3D 2.1 as active. Video doesn't freeze and I am able to play video with audio. I am using the default config.txt that comes with both the Pi 3 and 4 on Slackware Aarch64. This is a good sign.
My personal preferences and opinion are: I don't want to hear about how well Slarm64, Raspberry Pi OS, Libreelec, or any other Linux operating system runs. This is a Slackware forum.
I hear what you are saying, but you are missing my point. Slackwareaarch64 appears to be loading the wrong driver for some reason - at least on the Pi400 and probably the Pi4 as well. The others do not. I don't know why.
I asked a while back what was the output of "glxinfo | grep render" on your Pi4, but I have not seen a reply. If yours responds with "V3D", then it is a configuration issue on my system somewhere. If yours responds with "llvmpipe" then there must be something wrong with the way slackwareaarch is detecting the correct driver.
Yesterday, I did a completely fresh install, and booted without making any configuration changes to config.txt. As soon as I attempted to start X from the command line, the machine locked solid.
Subsequently, I edited the config.txt file thus:
Code:
# Raspberry Pi4/400 settings:
[pi4]
# Assign 128MB of RAM to the GPU:
gpu_mem=128
disable_fw_kms_setup=1
# Enable DRM VC4 V3D driver on top of the dispmanx display stack:
# https://github.com/raspberrypi/linux/issues/4392
#dtoverlay=vc4-kms-v3d-pi4
#dtoverlay=vc4-fkms-v3d
dtoverlay=vc4-kms-v3d
max_framebuffers=2
#hdmi_enable_4kp60=1
# Interested in overclocking options?
# See: https://www.raspberrypi.com/news/introducing-turbo-mode-up-to-50-more-performance-for-free/
#
# Experimental for RPi4 model B:
#device_tree=bcm2711-rpi-4-b.dtb
# Raspberry Pi400 settings. These would override those configured
# for all RPi4 models.
#[pi400]
device_tree=bcm2711-rpi-400.dtb
This enabled me to start X, and for a while it seemed like it was stable.
so the vc4 driver appears to be loading - at least partially - correctly.
However, as soon as I switched inittab to start in run level 4, I had issues. Although sddm started and logged in correctly, if I left the machine and returned (having to unlock the system) sddm took two or three seconds to respond to EACH LETTER of the password. Once logged in, I could see that all 4 cores had been running at 100% during the unlocking procedure. Then when I tried to shut it down via sddm, the whole machine locked solid and I couldn't even ssh into it. After an hour (in case it was just being very slow), I pulled the plug.
It looks as if I was correct in at least one of my assumptions, namely that all the lockups had corrupted my previous installation. This is evident as the code above is different from that which I was seeing previously. However, it still suffers from abysmal performance in X and is still unstable.
As it stands at present, slackwareaarch64 is unusable in any meaningful way on the Pi 400. I don't know why. I hear what you are saying about upstream, but I can't see how that explains the incorrect driver issue.
I have passed on as much information as I can in an attempt to diagnose the problem, as I am more than a little out of my depth here. Hopefully it will help you and Stuart to find a fix. For the moment, I have to give up as I am spending way too much time on this.
I hear what you are saying, but you are missing my point. Slackwareaarch64 appears to be loading the wrong driver for some reason - at least on the Pi400 and probably the Pi4 as well. The others do not. I don't know why.
I asked a while back what was the output of "glxinfo | grep render" on your Pi4, but I have not seen a reply. If yours responds with "V3D", then it is a configuration issue on my system somewhere. If yours responds with "llvmpipe" then there must be something wrong with the way slackwareaarch is detecting the correct driver.
Yesterday, I did a completely fresh install, and booted without making any configuration changes to config.txt. As soon as I attempted to start X from the command line, the machine locked solid.
Subsequently, I edited the config.txt file thus:
Code:
# Raspberry Pi4/400 settings:
[pi4]
# Assign 128MB of RAM to the GPU:
gpu_mem=128
disable_fw_kms_setup=1
# Enable DRM VC4 V3D driver on top of the dispmanx display stack:
# https://github.com/raspberrypi/linux/issues/4392
#dtoverlay=vc4-kms-v3d-pi4
#dtoverlay=vc4-fkms-v3d
dtoverlay=vc4-kms-v3d
max_framebuffers=2
#hdmi_enable_4kp60=1
# Interested in overclocking options?
# See: https://www.raspberrypi.com/news/introducing-turbo-mode-up-to-50-more-performance-for-free/
#
# Experimental for RPi4 model B:
#device_tree=bcm2711-rpi-4-b.dtb
# Raspberry Pi400 settings. These would override those configured
# for all RPi4 models.
#[pi400]
device_tree=bcm2711-rpi-400.dtb
This enabled me to start X, and for a while it seemed like it was stable.
so the vc4 driver appears to be loading - at least partially - correctly.
However, as soon as I switched inittab to start in run level 4, I had issues. Although sddm started and logged in correctly, if I left the machine and returned (having to unlock the system) sddm took two or three seconds to respond to EACH LETTER of the password. Once logged in, I could see that all 4 cores had been running at 100% during the unlocking procedure. Then when I tried to shut it down via sddm, the whole machine locked solid and I couldn't even ssh into it. After an hour (in case it was just being very slow), I pulled the plug.
It looks as if I was correct in at least one of my assumptions, namely that all the lockups had corrupted my previous installation. This is evident as the code above is different from that which I was seeing previously. However, it still suffers from abysmal performance in X and is still unstable.
As it stands at present, slackwareaarch64 is unusable in any meaningful way on the Pi 400. I don't know why. I hear what you are saying about upstream, but I can't see how that explains the incorrect driver issue.
I have passed on as much information as I can in an attempt to diagnose the problem, as I am more than a little out of my depth here. Hopefully it will help you and Stuart to find a fix. For the moment, I have to give up as I am spending way too much time on this.
--
Pete
I think the problem is that the mainline kernel doesn't work well or at all with the Pi 400 yet. You would probably have to switch to their kernel to get it working. By that I mean the video portion. Just a guess. I have a Pi 400 still in the box and I'm just trying to find some time to play around with it.
Last edited by stormtracknole; 05-17-2022 at 11:07 AM.
Reason: To specify what doesn't work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
