Oh, dear, still no joy with the Pi400 following the Jan 6 updates, indeed its even worse than previously!

1) Full install from scratch to SD card, following the instructions meticulously. Install appears to go as expected. Check for "irqpoll" in extlinux.conf. Yes, its there.

Reboot. Boot stalls 31 secs in immediately after the line "vcc-sd: disabling". This is exactly the same error that has been there since the 20th September updates. It very effectively stops the boot process at that point.

2) Copy the whole install (using "dd") from sd-card to USB-SSD. It now boots and I can get to a command line.

Carry out some minor configuration (set up ntp, add non-root user and edit config.txt as suggested for Pi 400).

Reboot. Startxfce4. Xfce starts and appears to be OK. Startx. KDE tries to start, but crashes reporting a segmentation fault in ksplashqml.

3) Reboot. Startxfce4. All the task managers and panels have disappeared! Startx. KDE crashes with segmentation fault in ksplashqml again.

Xfce is clearly not happy. The background has a weird pulsating going on, and it hurts the eyes. The panels appear to have disappeared for good! I can get to KDE's system settings, but any attempt to change anything results in an instant crash.

I've managed to get the xfce panels back, after a lot of googling, but now the rest of the desktop has disappeared! No wallpaper, no icons, no mouse pointer, just black with the panels on it!

I've tried replacing the Pi4-b overlay with the Pi400 one in config.txt to no avail. I also notice that I'm still getting the error during boot about enabling hdmi_enable_4kp60 in config.txt, but it is enabled (It is by default)! I've also updated the eeprom as suggested.

The system still only partly shuts down in response to a "halt" or "shutdown -h now" command. The power light on the keyboard goes out, but the GPU is still powered (output to monitor) as are any ancillaries plugged in (SSD, TV tuner, etc). I've now invested in a USB-C in-line power switch, as I was worried about the long term effects of constantly unplugging the USB-C power lead on a surface mount connector (or scrabbling around on the floor for the 13amp power lead!).

On the plus side, it does appear to be finally using the correct V3D driver, but because of the other issues, I haven't been able to check any further.

I appreciate that Stuart doesn't have a Pi 400, and I believe there are some subtle differences between the 400 and 4, but don't know the details. I also believe there are some further updates in the pipeline.

I've tried to set out the issues I'm having as clearly as possible, but if there's any other information I can provide, I'll be happy to oblige. If anyone has any ideas, I'd love to hear them!

Cheers,

--
Pete

Thanks for the report.

Which DTB did you replace them with? I had thought about updating them but it means building the RPi's 6.1 Kernel, as they don't distribute just the DTBs for 6.1 yet (as far as I can see).

Do you have a serial console onto the Rpi? If so the next Installer and OS InitRD will support being able to step through the module list, which might help discover which particular module it is that causes the hang.

1 members found this post helpful.

that sounds interesting

I haven't replaced anything. The whole install is exactly as downloaded. All I've done is switch between "device_tree=bcm2711-rpi-4-b.dtb" and "device_tree=bcm2711-rpi-400.dtb", which made no perceptible difference.

I've also added to the overlay line thus: "dtoverlay=vc4-kms-v3d-pi4,cma-512", which made a noticeable difference on, er, other slackware derived systems, but not here. I also tried uncommenting "gpu_mem=128", which again has helped video performance elsewhere, but didn't help here. Mind you, I haven't been able to try video at all, yet...!

One thing I have just noticed is an "upstream-pi4" dtbo overlay, whose apparent purpose is to "fix divergences between the RPi device tree and what upstream provides"! This does exist in your overlays folder, so I will give that a go shortly.

Yes, I do. I haven't tried it as, on the SD-card version, at present the hang occurs fairly early in the boot process. Since I can't even get to the login line, I'm not sure if I would be able to ssh into it. It maybe before the network is up. I'll have to check.

I'll try adding that "upstream-pi4" overlay and report back...

UPDATE: No, dammit, that didn't work either! The SD-card still hangs at the same point.

--
Pete

I've just updated KDE on my SSD install (the only one that boots), but it still crashes with the same error as noted above (ksplashqml segfault). I also reinstalled xfce4, but that still doesn't work either. I get the panels (top and bottom) but the window is black, there is no mouse cursor and right clicking brings up no menus. The only way out of both xfce4 and KDE is ctl-alt-backspace.

I've attached my config.txt, extlinux.conf (had to rename it to .txt to upload) and syslog.txt to see if that gives any clues to any of the problems.

Things worth noting in the syslog: This was taken straight after login at a command prompt (no attempt to start X). At this point, the network wasn't up, so ntp hadn't kicked in hence the wrong date and time. I can post another version after trying to startx, but I couldn't see anything relevant to the KDE/XFCE problems there, though there were a lot of pulseaudio warnings.

I've mentioned before the long pause during booting. On the console, this happens immediately after sda4 and sda2 are remounted/mounted. Sda4 is SLKroot and sda2 is SLKhwm_bw. In the syslog, this is visible at line 27, and appears to involve bluetooth. I've added a line "dtparam=krnbt=on" to my config.txt as this was necessary on other Slackware derived installs to get bluetooth working. Commenting it out makes no difference to the boot time, and without a working GUI, I can't easily tell if bluetooth is working or not.

The first two lines in the syslog appear to refer to the "irqpoll" setting in extlinux.conf. I have tried removing this, and it has made no difference other than the warnings in the syslog disappear!

Also note lines 19 and 20 requesting adding "hdmi_enable_4kp60" to config.txt. It IS in config.txt! I tried moving it down to the end of the file in case it was being parsed too soon (before the overlays had kicked in), but it didn't make any difference.

If there is anything else I can submit that will help with debugging this, let me know, and I'll help if I can.

Cheers,

--
Pete

Attached Files

	config.txt (2.9 KB, 2 views)
	syslog.txt (2.7 KB, 2 views)
	extlinux.txt (7.0 KB, 11 views)

There's quite a bit to unpack there.

Regarding just booting the Installer:
To start, grab the latest installer and before you boot it, mount the 2nd partition.
Edit the extlinux.conf and add slkpbs_modstep to the APPEND line.

This will confirm each module prior to loading it, so you may get some idea of which one is causing the problem.
This is a crude tool though because one of the subsequent modules may load as a dependency one of those that you rejected; but it's still useful.
Don't move too quickly either because some modules take a moment to instantiate.

Hi Stuart,

Just to clarify: The only problem with the installer is if you try to install to somewhere other than an SD-card. If you try to install directly to a SSD, it completes OK, but doesn't remove the installer. This means that on rebooting, you go straight back into the installer rather than into Slackware. This is why I have to install to the SD-card first, and then clone that to the SSD. (Is this likely to be addressed in the new installer?)

Moving on, adding slkpbs_modstep to extlinux.conf stops the kernel from booting (on the SD-card). It loads the initrd and kernel throws up a couple of (expected) lines, gets to "Starting the Kernel" and then stops. I waited about 10 mins, just in case it was taking a while, before giving up. I haven't tried it on the SSD, because that works - as a command line system, at least!

I tried to reset xfce4 to its default settings by completely removing the ~/.config/xfce4 folder, but it hasn't changed anything. All I get is the top and bottom panel, no wallpaper, no icons, no mouse cursor, nothing. The only thing I can think of is that when kde crashed, it over wrote something in my desktop settings that is affecting xfce4. Maybe I'll try creating another user and see if it works OK there!

I'll have to leave it there for today, as other chores are awaiting me. I may be limited on time tomorrow as well, but if you have any further suggestions or requests, I'll get to them asap.

Cheers,

--
Pete

You'd need to open another shell before saying 'Yes' at the removal dialog, and see if /boot is still mounted. The only reason the installer image would remain is if the installer isn't removable, which would probably be if the mmc sub system fell over and /boot was umounted. I can't think of any other reason.
Is there any messages in dmesg ?

The A-i-O installers are the same installer images as before, but with another partition containing the packages.

You have to access it over the serial console.

XFCE works fine here, it's just KDE that's crashing within QT; but it doesn't on the RockPro64.
If anybody figures that out , let me know.

I think the segfault only happens in wayland sessions. I worked around this issue by "startx" (this will launch X11 session) in runlevel 3, disabled compositing in KDE settings, and killing X (CTRL+ALT+BACKSPACE). Upon executing "startx" again I had no segmentation fault and glxinfo reports V3d is active.

Also, the segfault in question on my system caused plasmashell to crash and relaunch after a few seconds. In wayland there was extreme slugishness after that until eventually locking up.

I attached a screen shot and I can do further testing soonish. In the screenshot you can see that I can play a video in firefox with a few tabs open. On my Raspberry Pi 4 B (2019) 4GB. I'd like to note that this was not tested on a fresh installation. I had a snapshot of -current from some weeks back with just the a/ ap/ d/ l/ and n/ package series since I was using my Pi 4 without a desktop. SO, the KDE series and X series were all freshly installed based on today's change log.

I know the original report was for the Pi 400. I do not own one of those and will not be buying one.

Attached Thumbnails

 

I think we might be talking at cross purposes here! Maybe I haven't explained very well. Forget the SD-card, there is NO SD-card at all in this scenario. Put the installer images straight on to the USB-SSD, and boot from there. Once booted, use fdisk to add sda3 and sda4 for swap and root. Then run setup. Everything goes smoothly (and a LOT quicker than using an SD-card!). Once completed, and setup asks if you want to remove the installer, select "yes", and the subsequent messages imply it is trying to remove the installer from the SD-card - which doesn't exist. The installer is on the USB-SSD, so it doesn't get removed.

Ah! Thanks for the clarification.

Is this possible if the kernel hasn't booted? All the messages I've seen up to this point seem to be part of the pre-kernel boot process (U-boot?).

Yes, I think this may have been something that got screwed on my machine after the panels vanished. The panels vanishing seems to be a recurring issue on xfce. When I was googling for a solution, some of the advice was over a decade old, yet others were complaining of the same issue recently (on systems other than slackware).

I followed one piece of advice which seemed to be highly recommended, and that got the panels back, but after rebooting, everything else had vanished. I had hoped just cleaning all the xfce config files in my user account would force a "default" reload, but it hasn't worked.

I am starting from the command line, using either startx for kde or startxfce4 for xfce. I don't think the problem is related to X11. It seems to be something that has changed in the latest release of kde, as previously it worked fine - if slowly.

--
Pete

Not sure if this helps or not! I have a SD-card with a sarpi64 install. This uses the slackwareaarch64-current applications tree, but its own kernel and installer. I've just updated the kde to the latest version - which is giving problems in the mainstream slackwareaarch64 - and kde is working perfectly! In fact, I'm writing this from kde on sarpi64!

I have no idea what other changes there are between the two systems, I thought it was just the kernel and installer, maybe some configurations, but I could be wrong. Kernel is currently 6.0.14.

To me, it indicates that the problem is something external to kde, but unique to the Pi.

That reaches the limit of my knowledge!

Update: Just noticed that Exaga has issued a kernel update to 6.1.4. I've applied the update, and kde is still running fine. Whatever the issue is, it does not appear to be with kde itself.

--
Pete

OK, now it's starting to make sense. I'm not surprised - it's designed to be installed from the SD card.
At some point I'll add in a check before offering the removal dialog.


If you are using a serial console, then anything after 'Starting Linux..' is when the Kernel has started.

I had wondered if the problem with KDE was related to the Kernel, so I'm glad you've found that it is. At some point it'll probably work with the proper Kernel.

1 members found this post helpful.