Debian User Forums

Debian has ROCm libraries in-repo. They're an older libary version than AMD's but Debian libraries have all architectures since gfx800 compiled so should work on many GPUs that official ROCm doesn't support.

You need either Bookworm Backports kernel or Trixie kernel, those both expose all required kernel interfaces.

There is no need to install the external amdgpu driver or external ROCm drivers. That arguably provides an inferior experience to just using Debian's ROCm.

I don't know about ...

The biggest difference between them is that Docker keeps a service/daemon running, but Podman only runs to launch a container and if you run a podman command.

The Podman design is considered preferable from a security perspective, because there is no daemon running to offer the opportunity for vulnerabilities.

In my experience, which you use depends on the containers you want to run.

Some containers only support Docker because they intentionally use Docker features. The Nextcloud All-In-One ...

Found this thread from your comment elsewhere. This appears to be a solution to your problem:

https://unix.stackexchange.com/a/619587/39229

Recording solutions here too:

- Update BIOS and set PSU Idle to Typical Current Idle
- Kernel parameters for both your computer and all Virtual Machines running on it: idle=nomwait processor.max_cstate=5

This seems to have solved the problem for other Ryzen 1000 series owners. Maybe it will solve for you as well?

No, there is no way to eliminate all these messages.

You can get upstream linux-firmware's amdgpu directory and copy it to your system, which will add some files and get rid of some of the messages. Some people might frown upon this because you'd be overriding packages supplied by Debian's linux-firmware package.

However for some of these files, the driver declares a firmware file which doesn't actually exist. At least AMD have not contributed it to upstream linux-firmware and it isn't ...

There were reports of this with the very first Ryzen 1000 series, eg:

* https://unix.stackexchange.com/questions/526162/random-freezes-with-amd-ryzen-on-linux
* https://community.amd.com/t5/processors/ryzen-linux-kernel-bug-196683-random-soft-lockup/td-p/156304
* https://bbs.archlinux.org/viewtopic.php?id=245608
* https://community.amd.com/t5/processors/amd-ryzen-freezes-linux/td-p/333729

These seem to have been resolved either with BIOS config, kernel cstate config (one line in a config file ...

I was a little worried before because I thought it might not work later but now I am not worried at all since I know this problem is known and fixed. :)


Just today, Intel have posted a patch which resolves this in Linux v6.1.y longterm kernels.

I guess next that patch needs to go into the main Linux kernel, then backport to 6.1.y longterm, then Debian can consume that in a regular kernel update.


Could you please open a bug report in the Debian Bug Tracking System about it ?


Yes ...

I was able to bisect this down to a commit 0fc6fea41c71 introduced between v6.1.22 and v6.1.23 which was a backport of a commit from v6.3-rc5.

The problem doesn't happen on any of v6.2 or v6.3 or 6.4 so I guess v6.1.x longterm (which Debian uses) is missing a commit.

It's been reported upstream on the GPD Pocket 3 as well:

https://lore.kernel.org/lkml/fce7ea8d-d ... arloff.de/

https://gitlab.freedesktop.org/drm/intel/-/issues/8419

Success.

I had more of a think about this. If the system boots without modesetting (i.e. with userspace Xorg driver), then the problem logically must be the kernel's modsetting (KMS). So it's a kernel problem. A friend who knows a lot more about Linux graphics agreed with that.

I built kernel v6.4.6 (latest upstream stable release) and it boots fine with KMS on MicroPC. Display can be rotated, acceleration works, etc. (I didn't try Plymouth but that's probably fine too)

Considering Ubuntu ...

I have found this problem too. Exactly the same symptom you describe.

The workaround of nomodeset is a good step forward. iiuc this will prevent the Intel graphics driver from working, but at least the system can be booted.

It could probably also boot into a text mode install, and you can rotate the text framebuffer with fbcon=rotate:1

Try applying the MicroPC configs from the Ubuntu MATE maintainer at https://github.com/wimpysworld/umpc-ubuntu particularly the Xorg ones, they change some ...