X freezes on RPi4 running slackwareaarch64
 

Hi i have a "Raspberry Pi 4 Model B Rev 1.4" with 8G of Memory, and on X it freezes regularly, running slackwareaarch64-current. I also have a "Raspberry Pi 4 Model B" with 4G running headless current. The headless one runs as server for my local network and never failed.
So it seems to be an X or better video related bug, especially because if i stay in Runlevel3 the "not headless" one doesn't freeze either.

I tried all sort of tips from this forum, like blacklisting specific modules and changing GPU memory size.
Also i tried tips found via google, nothing seems to work really. After some minutes if i play videos, or about 30m if I'm idle in X. I run herbstluftwm on the pi but the same happens on XFCE.
Also i reinstalled a couple of times to get sure i didn't mess something up myself.

My question is now am i the only one who has these issues, or are they to be expected as we are on current and rpi4 video support is WIP.
Also I'm open to tips what i can try to get over this Problems, if some of you guys got it working, or if i should wait for a fixes from Stuart.

Thanks in advance to you guys. And special thanks to Stuart and his Helpers for slackwareaarch64 is awesome at least on a headless pi:).

I'm running the Raspberry Pi 400 and Slackware aarch64, and the Xorg-related system hangs up a lot.

But the Xorg isn't the only one. Building the kernel:
and it builds OK, but then it freezes instead of returning to the command prompt. And that was with no Xorg.

This in contrast to stock Raspberry Pi OS, in ARMv7, doing just fine with widely-varying CPU load. But with ARMv8 (aarch64) and Slackware ARM, it's new and "experiMENTAL". :D

Another Pi400 user here, and I can confirm the frequent hangs - sometimes within seconds of X starting.

For me, it seemed to start going pear-shaped around the time of the 27 / 28 April updates. At first I thought I had messed up the updates (I just leave it to Slackpkg), so a few days ago I grasped the nettle and did a full re-install. No improvement.

X has been clunky from day one, but I had managed to get it usable - if slow - with some fine tweaks, but now it is just totally unstable.

On the same theme, video is almost totally unusable. The Pi-4(00) spec claims 4K playback. Mine struggles with 720p, and freezes altogether at 1080 under slackwareaarch64.

Does anyone else have any problems shutting down? However I call shutdown (sddm, halt, shutdown -h now) it usually goes through the motions, gets to the "system halted" stage (unresponsive) but still powered! (Ancillary lights are on, graphics still outputting, etc). At this point I have to pull the power, which can't be doing the storage any good.

On the upside, wifi works out of the box - something I always struggled with on Slarm64. But Slarm64 can playback 1080 videos - albeit with a high cpu load - and even kde plasma runs smoothly.

I know Stuart doesn't have access to a lot of hardware. I am almost tempted to offer a whip-round and buy him a Pi-400, but there seems to be a world shortage of Pis at the moment! :(

Shame, as I desperately need a replacement NAS, and a headless Pi4 would be perfect...!

--
Pete

Short version. Yes. It is all a work in progress and that is why Aarch64 is listed as actively developed in the Slacwkareaarch64-current branch.
...
Long version:

We rely on bug fixes applied to the mainline kernel. The video troubles do improve and or digress with each firmware update. If you guys have any specific fixes that apply to the kernel or the raspberry pi firmware, or anything else (mesa), please share your suggestions. Share what steps you took to diagnose and test.

Stuart has a Raspberry Pi 4B with 8GB of RAM. I have the 4B with 4GB of RAM. Additionally, I have a Raspberry Pi 3B (not the 3b+). Neither of us have a Pi-400 or any other Raspberry Pi model to utilize. I guess my point is that this is a community effort and adding more contributors to the Slackware ARM ports would greatly improve the outcome.

More hands and hardware to type and test. :)

The last update to the Raspberry Pi firmware package was:
We pull it from https://github.com/raspberrypi/firmware/tags. You can see by the issue tracker that there are issues with the Raspberry Pi firmware, with and without the upstream kernel (kernel.org). Specifically related to video. The issue is not unique to us or specific to Slackware. Anyway, Slackware has avoided a large majority of the issues with the Raspberry Pi 3 and 4.

Thanks for your reply mralk3 and the others too i have no problem with slackwareaarch64 beeing WIP as it is mentioned clearly. I just wanted to know if i am the only one.
I can't really contribute something i fear, i am a 10+ year slackware user, but the accent is on user im no programmer. but if i find something on google or alike i sure share it with you guys.
Xorg.log didn't show anything about errors, dmesg complained about an audio codec.
If you ask how i got these sshing in was still possible, which got me to the conclusion it is an X/video driver problem.

I want to state again thank you guys for your work.

Thanks for letting me know. You report is consistent with other bug reports and what I found just a few minutes ago.

Could you share the output of this command?

And the output of "lsmod" as root.

Just to second what sunzu has said, thanks for your efforts! I know that video acceleration seems to be a big issue with the Pis, and is really of secondary importance to getting X stable. However, in my (limited) experience, the two tend to go hand in hand, and if X runs smoothly, you have a fighting chance of getting decent video playback. At the moment X does NOT run smoothly and constantly crashes!

Here is the output of dmesg, as requested, from my Pi 400:
The output of lsmod is quite long, so I'm attaching it instead.

Dmesg also spits out a lot of complaints about hdmi_soc errors, but these seem to be audio related. Its a bit odd as the audio seems to work fine!

As I said earlier, it seems to be something that changed around the 27/28 April updates that kicked off my stability issues. Until then X hadn't shown any great tendency to crash, although it was slow and clunky compared to other systems I've tried on the same hardware.

Like sunsu, I've scraped google for every magical incantation I could find to try. Whilst I did manage some minor improvements, they were not of any great consequence.

Part of the problem is a lack of solid information to build on. For example, one thing I read was that it might be necessary to include the full /path/to/overlays rather than just name the overlay itself. I did try this, and although it had a dramatic effect, it was pretty much the opposite of what I was trying to achieve! It is also compounded by the fact that I've discovered overlays with the same name in different folders! Are they the same? The sizes seem to match, but that's no guarantee! What are the differences?

Systems like this are too complex for a "trial and error" approach, and I really don't have enough knowledge for a planned strategy here!

Cheers,

--
Pete

This is interesting. If I open Xfce with Firefox and Htop in a terminal it doesn't freeze up until I open a YouTube video. Specifically when I move the mouse pointer over a video. I browsed for about 45 minutes and did "regular" things. The pi didn't freeze until I tried out YouTube. The board gets REALLY hot though. Here is what I am testing in my boot config.txt for the Raspberry Pi 4 (/boot/platform/hwm_bw/config.txt):

KDE freezes immediately with Wayland enabled. I can last a few minutes longer in KDE if I disable the window manager compositor and Wayland. Surprisingly, Xfce runs longer if I keep the compositor enabled. Starting X in run level 3 with the "startx" command or in run level 4 with the display manager (sddm) doesn't seem to make a difference.

I see you are using the fkms driver, rather than kms. I used that on slarm64, and it was the only way (at the time) to get 1080 video to play properly. That was a few weeks back, and more recent kernels don't seem to play nicely with fkms anymore.

The advice I've managed to glean from google, is that kms should be used ideally, as this is seen as the way forward. The last few times I've tried fkms - on either slarm64 or slackwareaarch64 - it simply hasn't worked at all, so I'm surprised to see you getting away with it. There are differences between the 4b and 400, and I'm guessing these are the reasons.

On my system, it seems to be "copying and pasting", or attempting any kind of configuration under X (even calling the "System Settings" has been enough to cause an instant freeze!) seems to be what kicks mine off. But then, just to confuse me, it will freeze when I do something as simple as closing a window!

I keep gkrellm running on the desktop to try and keep an eye on system load and temperatures, but haven't seen anything untoward. Indeed, that is often the first thing that tells me its frozen - when the graphs stop moving!

FYI, here's my config.txt:
I'd be interested in your comments.

Cheers,

--
Pete

I tested all the options/configurations and rebooted several times. I started with what Stuart and I agreed upon a few weeks back:
https://slackware.uk/slackwarearm/pl...ets/config.txt

My previous post is where I left off. I tested with 5.17.5 on Slackware installed fresh yesterday. I am going to wait for 5.17.5+ or a 5.18.x to do any further testing. I think that commenting out hdmi_enable_4kp60=1 is a good idea since we are stuck at lower resolutions anyhow. I was only able to produce 480p or 720p and shortly after setting 720p it freezes. 1080p results in screen taring while moving a window across the screen. and a freeze immediately.

EDIT:
The 1080p, 720p, 480p I am referring to are youtube video settings. I have the desktop set to 1280x1024.

I've recently acquired a (cheap!) 4K monitor, but it can only do 30Hz at 4K (I said it was cheap!) so I've disabled 4K@60. My Pi seems to get its resolution over edid (?) correctly, the only downside being that the boot messages are microscopically small. I should add that the problems all started when it was hooked up to a 1080 monitor, so I'm not convinced the resolution is entirely to blame - especially as the manufacturers boast of 4K@60Hz!

I've downloaded the latest LibreElec/Kodi which allegedly is able to handle 4K@60. It appears the only way to install it is via an installer that only runs on windoze :( , so it might have to wait until I can pull an old rust-bucket out of retirement. It will be interesting to have a look at their configurations...

--
Pete

hi again, as far as i can say my looks exactly like pchristy's my lsmod is attached, i have re-downloaded stuarts config.txt and only commented out the 4k line.

Edit: i got 16min with an idle WM before it hung up

I found an old post from last November 2021 that refers to the raspberry pi foundation's move to kernel 5.15.x branch.

https://forums.raspberrypi.com/viewt...22879#p1932447
I modified it a little. These are my changes, and I had an uptime of 1 hour and 30 minutes with glxgears active and many tabs open in Firefox. I left it idle with all that stuff running. As soon as a came back and moved the mouse pointer, freeze. :banghead:

It seems that CMA must be set and so should gpu_mem.

I mentioned this problem in a post I made earlier, admittedly it was a side note and I should have made a separate thread. In 6 months I am going to ordain as a monk so I don't have a lot of money, the only computer I have now is my pi and as I only have 1 usb storage device I installed aaarch64 straight to the microSD. Thinking that I might be experiencing some hardware failure and as no one responded to my ping I presumed it was just me. Firefox would freeze regularly, I had xcompmgr running and thought that might be the issue, I closed it and saw some improvement. With it running X would freeze completely, without it running I was just seeing firefox stop. I am not running Slackware at the moment so I can't supply any additional information but I did check my hardware by installing the 32bit system using sarpi, it ran beautifully and I had no issues at all except there was no firefox (I am sure there is a good reason for this but couldn't find any information on it) so out of necessity I had to rely on raspberrypi os, although today I'm going to have a look at freeBSD.

There was another issue. I was connecting to the internet using inet1 and wpa_supplicant, everything connected smoothly on the 32bit but on aarch64 inet1 wouldn't pick up wpa_supplicant on boot, I had to connect manually using ./rc.inet1 wlan0_start everytime. I am not sure if anyone has encountered that particular problem as well, udev? I am really not qualified to speculate though.

I finally had a play with Libreelec/Kodi today to satisfy my curiosity. This claims to be "Just enough OS to support Kodi" and installs both itself and Kodi into a 512MB fat16 (yes, really!) partition. Actually, that's a little bit misleading, as there is a squashfs file there. I suspect this gets decompressed and the real program runs in RAM, but it is remarkably compact nonetheless. There is no indication as to what the underlying OS is, but I guess it is some kind of Linux.

The config.txt is minimal in the extreme! There is one line setting the gpu_mem to 76 (a comment indicating that this is the minimum requirement for the h264 decoder). And that's it! There is a line to include the "distroconfig.txt" file, which seems more relevant. When I downloaded it, it asked me what system I was downloading it for, and I chose the Pi 4/400 option, so I'm guessing this file is one that is platform dependent.

The distroconfig.txt file is much more interesting, though still minimal. Here are the relevant bits:
Note that they are running the kms overlay, not the fkms. I think that ripvid-v4l2 is relevant. I have put that in mine, but it appeared to have limited effect. I also note that "disable_fw_kms_setup=1" line. I thought that was something to do with the early boot procedure, but perhaps its tentacles reach further.

I'm also puzzled by that "dtoverlay= " statement. I would have expected that to over-ride and clear any earlier dtoverlay commands, but what do I know?

I will have a play around with some of these settings. I'm not holding my breath, but its worth a play.

Oh, and tried playing video on it, and one of my home edited 4K 30fps h265 videos plays perfectly smoothly! So it IS possible. Its just a question of getting all the configurations sorted out, and some may be hidden "under the bonnet"!

--
Pete