no idea what has happened but container really not happy

[chboishabba]

Hi mate :)

Not really sure what's going on with the container.. It may be worth confirming the compiled ones I have uploaded to hub match yours.
In any case, both the originally working container, and subsequent recompiled ones appear to be crashing at some low kernel level (python3 status D in top) I'm not sure if I've corrupted my gpu's bios or something but it's not even outputting errors/segfault etc.

Steps to reproduce:

(Mon Jun 16 11:26:43) c@archb ~$ docker run -it --name whisperx_live_edit_test \

  --device=/dev/kfd --device=/dev/dri \

  --group-add video \

  --ipc=host \

  --cap-add SYS_PTRACE \

  --security-opt seccomp=unconfined \

  -e ROC_ENABLE_PRE_VEGA=1 \

  -e HSA_OVERRIDE_GFX_VERSION=8.0.3 \

  -e JOBLIB_MULTIPROCESSING=0 \

  -p 7860:7860 \

  rocm64_gfx803_whisperx:latest bash

Use "faster-whisper" implementation

Device "cuda" is detected

* Running on local URL:  http://0.0.0.0:7860

* Running on public URL: https://dff5ea454672538144.gradio.live


This share link expires in 1 week. For free permanent hosting and GPU upgrades, run `gradio deploy` from the terminal in the working directory to deploy to Hugging Face Spaces (https://huggingface.co/spaces) 

Set model to small.en, languge english, compute type int8, upload test audio and press Generate.

Page indicates 'Initialising Model'

(Mon Jun 16 12:11:06) c@archb ~$ docker logs whisperx_live_edit_test ███████████████████████████| 75.5M/75.5M [01:33<00:00, 820kB/s]
Use "faster-whisper" implementation
Device "cuda" is detected
* Running on local URL:  http://0.0.0.0:7860
* Running on public URL: https://dff5ea454672538144.gradio.live

This share link expires in 1 week. For free permanent hosting and GPU upgrades, run `gradio deploy` from the terminal in the working directory to deploy to Hugging Face Spaces (https://huggingface.co/spaces)
Use "faster-whisper" implementation
Device "cuda" is detected
* Running on local URL:  http://0.0.0.0:7860
* Running on public URL: https://7cac9cb28f978a3bdc.gradio.live

This share link expires in 1 week. For free permanent hosting and GPU upgrades, run `gradio deploy` from the terminal in the working directory to deploy to Hugging Face Spaces (https://huggingface.co/spaces)
Traceback (most recent call last):
  File "/Whisper-WebUI/modules/whisper/base_transcription_pipeline.py", line 272, in transcribe_file
    for file in files:
                ^^^^^
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/gradio/queueing.py", line 625, in process_events
    response = await route_utils.call_process_api(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/gradio/route_utils.py", line 322, in call_process_api
    output = await app.get_blocks().process_api(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/gradio/blocks.py", line 2181, in process_api
    result = await self.call_function(
             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/gradio/blocks.py", line 1692, in call_function
    prediction = await anyio.to_thread.run_sync(  # type: ignore
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/anyio/to_thread.py", line 56, in run_sync
    return await get_async_backend().run_sync_in_worker_thread(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/anyio/_backends/_asyncio.py", line 2470, in run_sync_in_worker_thread
    return await future
           ^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/anyio/_backends/_asyncio.py", line 967, in run
    result = context.run(func, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/venv/lib/python3.12/site-packages/gradio/utils.py", line 889, in wrapper
    response = f(*args, **kwargs)
               ^^^^^^^^^^^^^^^^^^
  File "/Whisper-WebUI/modules/whisper/base_transcription_pipeline.py", line 318, in transcribe_file
    raise RuntimeError(f"Error transcribing file: {e}") from e
RuntimeError: Error transcribing file: 'NoneType' object is not iterable
config.json: 100%|█████████████████████████████████████████████████████████████████████████████| 2.32k/2.32k [00:00<00:00, 2.97MB/s]
vocabulary.txt: 100%|█████████████████████████████████████████████████████████████████████████████| 422k/422k [00:00<00:00, 453kB/s]
tokenizer.json: 100%|███████████████████████████████████████████████████████████████████████████| 2.13M/2.13M [00:05<00:00, 408kB/s]
model.bin: 100%|████████████████████████████████████████████████████████████████████████████████| 75.5M/75.5M [01:33<00:00, 812kB/s]
(Mon Jun 16 12:11:08) c@archb ~$ docker stop whisperx_live_edit_test███████████████████████████| 75.5M/75.5M [01:33<00:00, 820kB/s]
Error response from daemon: cannot stop container: whisperx_live_edit_test: tried to kill container, but did not receive an exit event
(Mon Jun 16 12:11:40) c@archb ~$ docker stop whisperx_live_edit_test
Error response from daemon: cannot stop container: whisperx_live_edit_test: tried to kill container, but did not receive an exit event
(Mon Jun 16 12:12:14) c@archb ~$ 

[chboishabba]

(Mon Jun 16 12:12:14) c@archb ~$ docker ps -a --no-trunc
CONTAINER ID                                                       IMAGE                           COMMAND                                    CREATED             STATUS                           PORTS                                                             NAMES
0ad1d97af8b31ea0317e364196b4b1b2644d4167ccd74e1d3ad43fbd5de4c8ed   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-WebUI/whisp.sh bash"   38 minutes ago      Up 27 minutes                    0.0.0.0:7860->7860/tcp, [::]:7860->7860/tcp                       whisperx_live_edit_test
c5cc5cd281d21be566a04415fae86e034a314959ef7f38d89d7980c1156310e4   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-WebUI/whisp.sh bash"   About an hour ago   Exited (255) 52 minutes ago      0.0.0.0:7860->7860/tcp, [::]:7860->7860/tcp                       rocm64_whisperx
7e063e5dc40a837f7730ff8433b0b5ddedc507c08f710632eb3140a69d720d25   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-WebUI/whisp.sh bash"   14 hours ago        Exited (255) About an hour ago   0.0.0.0:7860->7860/tcp, [::]:7860->7860/tcp                       whisperx_manual_debug
0bf8ef00f3ea0c67e979f6d0a771f58750de9aea900104a154bb11a0934b2f80   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-WebUI/whisp.sh"        3 weeks ago         Exited (255) 2 days ago          0.0.0.0:7860-7861->7860-7861/tcp, [::]:7860-7861->7860-7861/tcp   whisperx_webui


(Mon Jun 16 12:17:35) c@archb ~$ docker ps -a
CONTAINER ID   IMAGE                           COMMAND                  CREATED             STATUS                           PORTS                                                             NAMES
0ad1d97af8b3   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-…"   39 minutes ago      Up 28 minutes                    0.0.0.0:7860->7860/tcp, [::]:7860->7860/tcp                       whisperx_live_edit_test
c5cc5cd281d2   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-…"   About an hour ago   Exited (255) 53 minutes ago      0.0.0.0:7860->7860/tcp, [::]:7860->7860/tcp                       rocm64_whisperx
7e063e5dc40a   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-…"   14 hours ago        Exited (255) About an hour ago   0.0.0.0:7860->7860/tcp, [::]:7860->7860/tcp                       whisperx_manual_debug
0bf8ef00f3ea   rocm64_gfx803_whisperx:latest   "/bin/bash /Whisper-…"   3 weeks ago         Exited (255) 2 days ago          0.0.0.0:7860-7861->7860-7861/tcp, [::]:7860-7861->7860-7861/tcp   whisperx_webui
(Mon Jun 16 12:17:39) c@archb ~$ docker exec -it whisperx_live_edit_test bash
OCI runtime exec failed: exec failed: unable to start container process: error executing setns process: exit status 1
(Mon Jun 16 12:17:52) c@archb ~$ 

[chboishabba]

one thing i have changed is i installed plasma and used one of the extensions to set my background to a shader effect. i don't thihnk it was visible while i was experiencing an issuie but that may be relevant... few beers sorry :)

[chboishabba]

obvious cause :/ my bad

(Wed Jun 18 18:51:27) c@archb ~$ uname -a
Linux archb 6.15.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 10 Jun 2025 21:32:33 +0000 x86_64 GNU/Linux

[robertrosenbusch]

@chboishabba : hi and welcome back ^.^

jupp, the kernel version 6.15 is creepy. i am sorry to told you after using on arch ... i dont prefer or beeing deep into ARCH Linux, but it make sense to prove it something goes wrong

I am just on
6.8.0-56-generic #58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:33:28 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

[chboishabba]

I will try working with upstream. It seems fedora is doing some work if canonical are not interested...

…

On Thu, 19 June 2025, 10:32 am Robert Rosenbusch, ***@***.***> wrote: *robertrosenbusch* left a comment (robertrosenbusch/gfx803_rocm#35) <#35 (comment)> @chboishabba <https://github.com/chboishabba> : hi and welcome back ^.^ jupp, the kernel version 6.15 is creepy. i am sorry to told you after using on arch ... i dont prefer or beeing deep into ARCH Linux, but it make sense to prove it something goes wrong <https://github.com/robertrosenbusch/gfx803_rocm?tab=readme-ov-file#prevent-rocm-segfaults-on-your-linux-distro> I am just on 6.8.0-56-generic #58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:33:28 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGM4B3QABJLBD3UBHIX5LNT3EIALXAVCNFSM6AAAAAB7MAPA46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBWGEZTCNRQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chboishabba]

In any case the majority of my need is gone now so not so much of an issue for me at least.

…

On Thu, 19 June 2025, 12:24 pm Johl Brown, ***@***.***> wrote: I will try working with upstream. It seems fedora is doing some work if canonical are not interested... On Thu, 19 June 2025, 10:32 am Robert Rosenbusch, < ***@***.***> wrote: > *robertrosenbusch* left a comment (robertrosenbusch/gfx803_rocm#35) > <#35 (comment)> > > @chboishabba <https://github.com/chboishabba> : hi and welcome back ^.^ > > jupp, the kernel version 6.15 is creepy. i am sorry to told you after > using on arch ... i dont prefer or beeing deep into ARCH Linux, but it make > sense to prove it something goes wrong > <https://github.com/robertrosenbusch/gfx803_rocm?tab=readme-ov-file#prevent-rocm-segfaults-on-your-linux-distro> > > I am just on > 6.8.0-56-generic #58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:33:28 UTC > 2025 x86_64 x86_64 x86_64 GNU/Linux > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AGM4B3QABJLBD3UBHIX5LNT3EIALXAVCNFSM6AAAAAB7MAPA46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBWGEZTCNRQGI> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[chboishabba]

I did a bit of a dig, it seems like the kfd issues are far broader than just this repo, and apparently, even supported GPUs are broken on 6.15 . 6.14.0 seems to be the only stable recent kernel.

#AI

Thanks for confirming the CUDA check passed in the WhisperX WebUI. I’ll now begin a detailed investigation into compatibility issues affecting ROCm 6.4 with Polaris (gfx803) GPUs under Linux kernel 6.15.x (PREEMPT_DYNAMIC), with attention to the repro you’ve captured and the container logs.

I’ll analyze known upstream regressions, GCC 15 changes, Docker/kernel device passthrough, and whether other users or distros (Fedora/Ubuntu/Arch) have patches, workarounds, or bug reports. I’ll also gather the best pathways to escalate this to Fedora kernel maintainers or ROCm devs.

I’ll report back with the most comprehensive diagnosis and escalation strategy available.

Investigating ROCm 6.4 Failures on GFX803 (Polaris RX580) with Linux 6.15.2

Overview of the Issue

Running ROCm 6.4 (via WhisperX/Ollama containers) on a Polaris GPU (AMD RX580, GFX803) under an Arch Linux kernel 6.15.2-arch1-1 (PREEMPT_DYNAMIC) has led to reproducible GPU failures. Users have reported frequent segmentation faults in ROCm applications or sudden GPU resets, especially when using Docker containers for WhisperX (ASR) or Ollama (LLM inference). These failures appear tightly linked to the kernel version – multiple community reports indicate that certain kernel versions cause /dev/kfd (the ROCm kernel driver interface) to crash, while others work reliably. In particular, Arch Linux’s 6.15.x kernel (also Fedora 41’s kernel in early 2025) was flagged as “suspicious” for such crashes. The goal of this investigation is to pinpoint the root cause (kernel bug, compatibility break, or configuration issue) and recommend a solution or workaround.

Symptoms and Confirmed Reports

Affected systems show segfaults when initializing HIP/ROCm programs or heavy GPU workloads. For example, launching the WhisperX container may terminate unexpectedly, and dmesg logs on the host show GPU reset messages or KFD errors. In some cases the GPU may hang and recover (or require driver reload). Notably, a maintainer of the GFX803 ROCm project observed that on certain kernels “the devices /dev/dri and /dev/kfd crashed with SegFaults” when running Ollama or PyTorch inside the container. The project’s documentation advises users to check their Linux kernel version and switch to a known-working version if they encounter these crashes.

Multiple community sources corroborate this kernel-dependent failure:

• Robert Rosenbusch’s gfx803_rocm repo: Provides Dockerfiles for ROCm on Polaris and includes a compatibility table. It notes that as of April 2025, Fedora 41, Arch, and Debian 13 were shipping kernels that trigger ROCm segfaults, and that kernels 6.12.x and later had a fix for this issue. In the table, kernels 6.13, 6.14, 6.15 were marked as tested/working for ROCm 6.3.4/6.4.0 on Polaris, whereas some earlier kernels were not. (This aligns with user feedback that upgrading above Linux 6.12.21 resolved their GPU crashes.) Despite the table showing 6.15 as “working,” real-world results on Arch 6.15.2 suggest otherwise – indicating that additional factors (or subsequent regressions) are at play.

• Reddit (Nobara/Fedora users): One RX 6800XT user reported that ROCm worked flawlessly on kernel 6.14.0 but completely broke starting with 6.14.1, causing hipinfo to fail and any HIP apps to crash. Rolling back to 6.14.0 immediately restored functionality. Others in the thread confirmed the same issue on RDNA2 GPUs and resorted to downgrading kernels (one even fell back to 6.11). Notably, this is an officially-supported GPU on ROCm, implying the problem is not due to Polaris hacks but a broader ROCm+kernel regression. Indeed, an issue filed on ROCm’s GitHub by an affected user states “ROCm completely stopped working after kernel 6.14.0-202, and we’re now on 6.15.1 and it still doesn’t work.”. AMD’s team acknowledged it (though curiously labeled it a “Feature Request”), confirming that something in the 6.14.x→6.15 kernels disrupted ROCm on Linux.

• Docker/Frigate issue: In a related context, users running AMD GPUs in containers (e.g. for Frigate CCTV or Stable Diffusion) have encountered amdgpu crashes with newer kernels. One GitHub issue describes ROCm usage in Docker leading to amdgpu resets, which might be the same class of problem. This reinforces that the kernel’s amdgpu/AMDKFD drivers are the common denominator in these failures.

Symptoms in logs: When the failure occurs, you may see in dmesg output lines such as amdgpu: GPU reset begin... followed by a GPU halt and recovery sequence, or amdkfd: Failed to initialize queue errors. In some cases (especially if the process segfaults quickly), you might only see an HSA user-space error (e.g. a HIP runtime exception) and a generic segfault at IP… in syslog. Checking dmesg for KFD errors or GPU hangs is crucial. One user hint is to run dmesg | grep -i kfd – if there’s an issue like missing PCIe atomics (see next section) or a driver bug, it often appears there. For instance, failing to open /dev/kfd can log “Unable to open /dev/kfd read-write: Bad address” if prerequisites aren’t met.

Kernel Changes Impacting ROCm (Root Cause)

The timing of these regressions strongly suggests a kernel-side bug or interface change in the Linux 6.14 series. During the 6.14 development cycle, AMD’s graphics driver team made significant updates to the AMDGPU and AMDKFD components. A review of kernel patches reveals at least one fix directly relevant to GFX8 (Polaris): “drm/amdkfd: Fix user queue validation on Gfx7/8”. This patch, authored by AMD engineer Philip Yang, landed in Linux 6.14.0 and addresses how the kernel validates user-mode queues for GFX7/GFX8 GPUs. In practical terms, prior to this fix the KFD driver likely mis-identified or rejected compute queues on Polaris, which could cause segmentation faults when ROCm programs try to create GPU queues or submit work. It’s plausible that kernels before 6.14 had a bug causing Polaris-specific crashes in ROCm, and that 6.14.0 officially fixed that issue. This aligns with the gfx803_rocm maintainer’s note that “on Kernel version 6.12 it seems to be fixed” – in fact the fix was merged by 6.14, but might have been backported to some 6.12.x stable updates or simply observed by users once they jumped to 6.13/6.14.

However, the story doesn’t end there. The new breakage in 6.14.1+ (impacting even RDNA2) suggests that another change came with a stable update or in 6.15. Between 6.14.0 and 6.14.1, some modifications (perhaps to memory management or reset behavior) were introduced. Indeed, looking at the stable kernel changelogs: in Linux 6.14.9 there’s a fix for “amdkfd: Fix error handling for missing PASID in kfd_process_device_init_vm” and another for a “mode1 reset crash” in KFD. These hints imply that initial 6.14 code had issues with GPU VM initialization and reset handling. A PASID is a Process Address Space ID used by KFD; if the kernel erroneously handled a missing PASID, ROCm calls might crash or fail. The “mode1 reset” refers to GPU reset procedure – a bug there could easily cause unstable behavior when a GPU hang occurs. AMD did issue fixes for these in the stable series. By kernel 6.15.2 (the Arch version in question), one would expect those patches to be included (since 6.15 would incorporate 6.14 stable fixes). Yet, the ROCm failure persists on 6.15.2 for Polaris, likely because the user-space ROCm stack (6.4.0) hasn’t adapted to some kernel changes. In other words, even though the kernel might have fixed its internal bugs, it may have changed an interface or behavior that ROCm 6.4 wasn’t expecting, leading to a mismatch until ROCm is updated. AMD’s own response on the issue was that this might be resolved in a future ROCm release that aligns with the newer kernels (the user speculated ROCm 6.5 with Radeon 7000 support might solve it).

To summarize the root cause:

• Polaris support was broken in older kernels (possibly anything between 5.19 and 6.13) due to a KFD queue validation bug. This caused segfaults when using ROCm on GFX803 unless a patch or newer kernel was used. Kernel 6.14.0 introduced a fix for this.
• A regression for all ROCm GPUs appeared in kernel 6.14.1 (and persisted through 6.15), likely related to KFD’s VM/pasid management. This made ROCm user-space calls (HIP, OpenCL) fail or crash on otherwise supported devices. The kernel stable updates have addressed some of these issues by 6.15.x, but full functionality might require ROCm 6.4.1+ user-space to match. (ROCm 6.4.1 was released in May 2025, primarily adding RDNA4 support, but its release notes do not explicitly mention a fix for this issue – it’s something to watch in change logs of ROCr/HIP runtime components.)

Another kernel-related consideration is the introduction of GPU reset recovery. Linux kernels in recent years have improved AMDGPU’s ability to reset a hung GPU without rebooting the system. In fact, the reset-recovery code was enabled by default on many GPUs (Polaris included) around this time. This means on 6.15, if the RX580 encounters a computation hang, the driver will attempt a soft reset of the card. While generally positive, this could manifest to the user as a momentary freeze or error, whereas on older kernels the process might have just hung or died silently. The Phoronix coverage noted that GPU reset support was being flipped “on” by default for Polaris family GPUs (GCN4) after testing showed it works “for the most part”. It’s possible that under heavy load (e.g. running large WhisperX models or stable diffusion in ComfyUI), Polaris is more prone to hangs, and with resets enabled, the kernel will log a GPU reset and the ROCm runtime might see a device loss. If these resets happen frequently on 6.15, it could be perceived as instability. Undervolting/overclock settings can exacerbate this – indeed one user found their long-stable RX6000 undervolt became unstable on 6.15 (pointing to changes in power management in the driver). In short, kernel 6.15’s amdgpu driver might be less forgiving to any GPU instability, causing more frequent resets on Polaris.

Lastly, the PREEMPT_DYNAMIC kernel feature in use shouldn’t directly break ROCm, but it’s worth noting. PREEMPT_DYNAMIC allows the kernel to switch between full preemption and voluntary preemption modes at runtime. There are no known ROCm-specific issues with dynamic preemption in Linux 6.15; however, because it alters scheduling, it’s theoretically possible that timing-sensitive bugs (races in driver or user code) could surface. No evidence in our research points to PREEMPT_DYNAMIC as a root cause, so we do not suspect it here. (If needed, one could test a standard PREEMPT=none kernel to rule it out, but again, the widespread reports implicating specific kernel versions suggest it’s a code issue, not the preemption model.)

PCIe Atomics Requirement (Hardware Compatibility)

It’s important to confirm that the system itself meets ROCm’s hardware requirements, since Polaris GPUs are notorious in this regard. AMD ROCm requires PCI Express Atomics (a feature of PCIe 3.0) to be supported by both the CPU and motherboard/chipset for all GPUs GFX8 and newer. Polaris (RX 570/580) does support PCIe atomics at the GPU level, but if your platform (e.g., older Intel CPUs or consumer motherboards with limited firmware) doesn’t advertise this capability, the ROCm driver will refuse to initialize the GPU for computing. The error for this in dmesg is typically something like: “amdkfd: skipped device bus:device because PCIe atomics not supported” or the rocminfo output failing with “Unable to open /dev/kfd read-write: Bad address”.

Given that you have been running WhisperX/Ollama, you likely have already cleared this hurdle (otherwise ROCm wouldn’t have worked at all). But if the segfaults are happening very early (e.g., even rocminfo crashes), double-check that in your BIOS “Above 4G Decoding” or “Enable PCIe atomics” is turned on. On consumer motherboards, enabling 64-bit BAR support (4G decoding) is often necessary for atomics to function. You can verify support by running dmesg | grep -i atomic – successful initialization will log something about atomics enabled. As the ROCm GitHub issue #1205 succinctly states: “gfx803 (RX580) need PCIe Atomic support with both CPU and MotherBoard” – lacking this will cause a hard failure on opening /dev/kfd. This is not a software bug per se, but a requirement. (Atomics have been required since ROCm 1.x; Polaris was officially supported up to ROCm 4.3 provided this was in place.) In our context, since the containers did run and only started crashing on a new kernel, the PCIe setup is probably fine – the issue is software. But it’s worth mentioning to ensure no stone is left unturned.

GCC 15 and ABI Compatibility Concerns

Your environment features GCC 15.1.1 (as on Arch or bleeding-edge Fedora). Such a new compiler can introduce two types of problems: (1) compiling the ROCm software stack (or PyTorch, etc.) with it may require code changes, and (2) ABI mismatches if binaries were built with older compiler assumptions. Let’s break down the impact:

• Building ROCm/PyTorch with GCC 15: GCC 15 is a major update and has changes in the C++ standard library and default flags that affected ROCm code. A concrete example is libstdc++ enabling _GLIBCXX_ASSERTIONS by default on some distros. This inserts runtime bounds-checking asserts in container operations. When compiling device kernels for HIP, such asserts are not allowed (they call host functions). Indeed, when PyTorch was compiled for ROCm on Fedora 42 (with GCC 15), it triggered compile-time errors in HIP kernels – e.g. reference to host function '__glibcxx_assert_fail' in device function in ROCm’s OffsetCalculator.cuh. Essentially, GCC15’s std::array operator[] began calling an assert, which the HIP compiler caught as illegal. A PyTorch developer opened an issue about this, and it requires either disabling those debug asserts or updating the code to avoid triggering them. This kind of issue is likely to affect any ROCm component built from source with GCC 15: portions of HIP runtime, ROCm libraries, or even the LLVM-based ROCm compiler might need small fixes. Linux distributions have begun applying patches – for instance, Gentoo/Redcore Linux added a patch to update PyTorch’s bundled fmt library to v11 to fix GCC 15 build errors (since older fmt code wasn’t GCC15-compatible). If your Docker build is based on Ubuntu 24.04 (which probably uses GCC 13 or 14), you might not hit these compile issues inside the container. But if you ever rebuild ROCm or PyTorch on the host with GCC 15, be prepared for potential breaks until upstream addresses them. The key point: GCC 15 is new, and ROCm 6.4/PyTorch 2.4 were not developed against it, so minor build failures or warnings (treated as errors) can occur. These manifest at compile time, not as runtime segfaults, so they’re a secondary concern here.

• Kernel modules and GCC 15: The Linux kernel itself was compiled with GCC 15 in your case (Arch). Normally, this is fine – kernel and driver code is regularly updated for new compiler versions. AMD’s out-of-tree amdgpu-dkms module (used on Ubuntu for proprietary driver stacks) did fail to build on 6.13+ kernels – but that was due to code changes in the kernel, not the compiler. As long as you use the in-tree amdgpu (which Arch does), this isn’t an issue. No known ABI break was introduced by GCC 15 for the kernel <-> userland ROCm interface. (If anything, the break came from the kernel source changes, as discussed.) Therefore, we do not suspect that GCC 15 on the host is causing the runtime segfaults directly. The segmentation faults are occurring within ROCm/HIP runtime in user space, rather than symbol linkage errors or C++ ABI mismatches (those would typically cause compile or link errors, not segfaults at runtime for an already-built container).

In summary, GCC 15 primarily impacts developers building ROCm/PyTorch: you may need patches to compile successfully. It’s wise to use distro packages or containers for these big projects to avoid toolchain headaches on Arch. The Arch community repositories as of early 2025 were still on ROCm 6.2.4 (with PyTorch 2.1) partly due to the rapid changes – moving to 6.4 requires ensuring all these new compiler issues are resolved. Arch packagers or AUR maintainers might include fixes (for example, patching ROCm’s rocm-core or hipblt for GCC 15 if needed). If you encounter build problems, searching the Arch forums or GitHub for the specific error is recommended; chances are someone submitted a patch or PKGBUILD tweak. For the scope of this failure though, GCC 15 is not the culprit of the segfaults, but rather the kernel behavior is.

Workarounds and Recommendations

1. Use a Known Good Kernel Version

Downgrading the kernel is the most straightforward way to restore stability in the short term. All evidence points to kernel 6.15 (and late 6.14) being problematic, whereas earlier 6.12–6.13 and some LTS kernels are stable with ROCm:

• The GFX803 community suggests that Linux 6.9 through 6.12 were reliably working with ROCm 6.3.4/6.4.0 on Polaris. In fact, many users had success once they moved off the “bad” kernel. In your case, since you’re on Arch, you have access to the linux-lts package (which as of 2025 is likely tracking 6.1.x LTS). Kernel 6.1 LTS is older than the 6.14 regression and should be free of that issue. It may not include the Polaris queue fix that 6.14 had, but interestingly some users report ROCm worked on 6.1 for them – possibly because AMD never officially supported Polaris beyond ROCm 4.x, the newer queue feature might not be exercised in the same way. If you do try 6.1 LTS and still see segfaults on Polaris, then the queue fix patch might be missing there; in that case, going to 6.12.19 (the last 6.12 stable, if available) or 6.13.x could be an option. Arch doesn’t provide those older kernels pre-packaged, but you can compile a custom kernel or use the linux-mainline AUR for testing specific versions.

• For a quick test, consider booting into an Arch Linux LTS kernel (6.1). Ensure you also install matching kernel headers if needed by the container (usually not required, since the container uses user-space only). Users have reported that using an older kernel immediately fixed ROCm failures – e.g. Nobara (Fedora) users locked to 6.14.0 to keep ROCm running, and one went back to the 6.11 series with success. These versions predate whatever interface change broke ROCm.

• Looking forward, keep an eye on Linux 6.16+. It’s possible that by 6.16 or 6.17, AMD and the kernel community addressed the ROCm regression. For instance, there was mention that AMDKFD fixes were submitted during the 6.16 merge window (including support for new hardware and presumably bug fixes). Upgrading to 6.16 (once it’s stable) might resolve the issue without needing a permanent downgrade – but only test this after confirming a stable baseline on a known-good kernel. In other words, first get a working config (so you know how it behaves when fixed), then experiment with newer kernels to see if the fix has landed.

• Why not stay on 6.15? At the moment, 6.15.x requires a matching ROCm userland that isn’t out yet (ROCm 6.5 perhaps). Unless you have a pressing reason to use 6.15 (new hardware or feature), it’s safer to avoid it for ROCm on Polaris. The Arch kernel will move on fairly quickly anyway (6.16 will replace it in a few weeks given the kernel release cadence). So this is a temporary regression window to sidestep.

2. Patch or Rebuild ROCm Components (Advanced)

If kernel downgrade is not desirable, another approach is to try and rebuild the ROCm runtime from source with patches that make it compatible with newer kernels. This is non-trivial, but here are some pointers:

• AMD’s ROCm GitHub has the source for the runtime (ROCR), HIP, etc. If the issue is in user-space (e.g., assuming an old PASID handling), a patch could potentially be applied there. However, given that even RDNA2 users were affected, it suggests the user-space needed changes that likely only AMD knows in detail. Without an official patch from AMD, this path is guesswork.

• One thing you can do is run a simple ROCm program under gdb to see where it segfaults. For example, inside the container: HIP_VISIBLE_DEVICES=0 /opt/rocm/bin/rocminfo (or the WhisperX initialization) under gdb. A common point of failure could be at HSA queue creation or memory allocation. If it’s a null-pointer dereference in the ROCm user library, that confirms a software bug that might be worked around.

• Considering Polaris is unofficial, the community-maintained Docker already rebuilds many pieces (HIP, rocBLAS, PyTorch) to add GFX803 support. It’s possible the maintainers will update their Dockerfiles if a known fix emerges. Check the robertrosenbusch/gfx803_rocm issues for any mention of 6.15 – as of mid-June 2025, new issues (no idea what has happened but container really not happy #35, comfyui issue with cpu #36) were opened by users about container instability. The maintainer might respond with kernel-related advice or even a code workaround.

• Container runtime settings: Ensure you’re already using the recommended flags when launching the container. From the gfx803_rocm guide, the correct invocation is, for example:

  docker run -it --device=/dev/kfd --device=/dev/dri --group-add video \
             --ipc=host --cap-add=SYS_PTRACE --security-opt seccomp=unconfined \
             --name rocm64_whisperx ...

  This grants the container access to the GPU computing device and disables seccomp filtering and IPC isolation, which is needed for ROCm/HIP to function. If any of these options were missing, it could cause failures. (Your description indicates you did use --device and group video – just double-check all flags match the above.)

• Environment variables: Some environment tweaks can improve stability on the margin. For Polaris, one known quirk is limited SDMA engines (DMA copy engines). If you suspect issues during large data transfers, you can try disabling SDMA in ROCm by setting:

  export HSA_ENABLE_SDMA=0

  inside the container before running the workload. This forces ROCm to use PCIe for transfers instead of the GPU’s DMA engines. It might avoid certain hangs at the cost of performance. Another var is HSA_NO_SCRATCH_RECLAIM=1, which disables a memory optimization that sometimes causes problems on smaller VRAM GPUs. These are not guaranteed fixes for the segfault, but they are safe to experiment with and have helped in some ROCm scenarios. Also, since you use PyTorch in WhisperX, setting MIOPEN_LOG_LEVEL=3 will suppress benign warnings (unrelated to crashes, but cleans the log).

• Use ROCm 5.4.3 as a fallback: If nothing in ROCm 6.x will run on your setup with newer kernels, an alternative is to run the older ROCm stack that officially supported Polaris (ROCm 4.3 or the community-continued 5.4.x for GFX8). For example, Sunjay’s blog and others provided Docker images for ROCm 5.4.2 on Polaris. These might not have the latest features but could be more stable. However, mixing that with WhisperX/Ollama (which likely require newer PyTorch and HIP) may be infeasible. Thus, this is a last resort for basic OpenCL or older PyTorch models.

3. Reporting and Escalation

Since this issue spans kernel and ROCm user-space, you’ll want to escalate it through multiple channels to ensure it gets the necessary attention:

• Upstream Linux kernel: A bug that causes crashes or resets on supported GPUs (even though Polaris isn’t officially supported, the RX 6800XT case shows supported hardware is affected) should be reported to the kernel developers. The proper venue is the [kernel bug tracker on kernel.org](https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=DRM/AMD) or the amd-gfx mailing list. Provide a clear description that “ROCm workloads crash on kernels 6.14.1+” and include logs. Key data to attach: the output of dmesg around the failure (with AMDGPU and KFD messages), the exact kernel version, and steps to reproduce (for instance, “run rocminfo or start this public Docker image on a Polaris GPU”). Mention the specific commits if you know them – e.g., “possibly related to amdkfd user queue validation on GFX8 and subsequent PASID handling changes.” Kernel developers respond well to regressions that are bisected; if you have the time, performing a bisection between 6.14.0 and 6.14.1 could identify the offending patch. But even without that, linking to the public reports (Reddit/GitHub issues) like the Nobara user’s experience helps validate the problem. Since this might have been fixed in code already (just not in your user-space), the kernel devs might say “update your ROCm” – but it’s still useful to ensure they’re aware if any kernel bug is lurking.

• ROCm GitHub and AMD support: You’ve seen one issue (#4919) already filed on the ROCm GitHub. It wouldn’t hurt to add your information there – especially that you’re using Polaris, which adds another dimension. (They may not officially support it, but if the root problem is same, it’s still data.) If no one has filed a bug report on the AMD Community forums or Fedora Bugzilla for this, consider doing so. For Fedora, since ROCm 6.3.1 is packaged, a bug report could be filed in Red Hat Bugzilla under the ROCm component or the kernel component. Fedora maintainers might coordinate with AMD on a backported fix or at least document the issue for F42 release notes. Arch Linux, being community-driven, has an [Arch Bug Tracker](https://bugs.archlinux.org/) – you could open an issue under “Community Packages” for rocm or even under “Kernel” since it’s a kernel regression. Arch devs might not do much beyond possibly adding a warning in the package or forum post, but it alerts Arch users to the problem.

• Issue priority and follow-up: The fact that AMD labeled the GitHub issue a feature request suggests they might be rolling any fix into the next ROCm release rather than patching 6.4.x. That means we could expect ROCm 6.5 (or an hypothetical 6.4.2) to work properly with kernels ≥6.15. It’s worth watching the ROCm release notes and testing new versions when they drop. In the meantime, by reporting to the above channels, you ensure the problem isn’t forgotten. If you do report to kernel or distro, include references (for traceability) to others hitting the same issue – e.g., Debian bug #1093124 was apparently filed for Polaris ROCm and got resolved by the GFX8 queue patch. Mentioning that in your report shows prior art. Likewise, cite the Nobara/Fedora experiences so maintainers see it’s a cross-distro issue.

• Collecting logs and info for reports: You asked about log formatting – here are some tips:

  • Use dmesg -T > kernel_log.txt after a crash to get human-readable timestamps in the log. Trim that to the relevant portion (grep for amdgpu or kfd to find the errors). Attach this log to any bug report.
  • Run /opt/rocm/bin/rocminfo and /opt/rocm/bin/hipinfo (if available in the container) and capture their output. Even if they segfault, sometimes they print some info first. This helps identify ROCm version, HSA driver version, etc.
  • State your exact GPU model and driver in use. For instance: “AMD Radeon RX 580 (Polaris10, gfx803), using upstream amdgpu driver (LLVM 16 for shader compiler, firmware from linux-firmware 2025-01-10, etc).” You can get some of this from dmesg (look for “Virtual CRAT table created for GPU” which indicates KFD enabled the GPU, and “amdgpu: Topology: Add dGPU node [0x67df:…]” which identifies the chip).
  • If you managed to capture a stack trace from the segfault (e.g., using gdb or from /var/log/core with coredump), include that. It could show if the crash is in libhsa-runtime64.so or libhip.so etc., and what call might be failing.
  • Emphasize the reproduction steps: for example, “Start the WhisperX container and load a model, or run a simple HIP sample like vector_copy.” The easier you can make it for maintainers to reproduce the issue, the faster it will get addressed. Since not everyone has an RX580 on hand, they may try with a similar GFX8 card or even an RX6800 to see if any crash occurs.

4. Container-Specific Workaround

If you absolutely must continue using kernel 6.15 (say, due to other hardware requiring it) and cannot wait for a fix, one approach is to run a VM or container that encapsulates an older kernel. For example, you could use something like Docker with --privileged to run a lightweight VM (with KVM) that has Ubuntu 22.04 and a 5.x kernel, passing through the GPU. This is complex and not always worth it, but technologies like Kata Containers or even just running a second OS in a dual-boot might be considered. Most would find it easier to simply downgrade the host kernel, but I mention this for completeness.

In the context of Docker, ensure you’re using the updated images from the gfx803_rocm project. The maintainer recently uploaded pre-built images for the base and WhisperX containers to Docker Hub (issues #34 and #35 hint at that). Using those might save you build time and potentially include minor fixes. Always match the container’s expectation with the host: the host kernel must have /dev/kfd support and GPU drivers loaded – which you do – and the container’s ROCm stack version should not greatly exceed the host driver’s capabilities. (ROCm generally maintains backwards compatibility in user-space vs kernel, but there are limits.)

Conclusion

Root Cause Summary: The failures are caused by a combination of kernel regressions in Linux 6.14/6.15 affecting the AMD GPU compute driver (AMDKFD) and the fact that ROCm 6.4’s user-space isn’t aligned with those kernel changes. Polaris (gfx803) users were additionally hampered by historically missing support that was only recently patched in the kernel. The net effect under kernel 6.15.2 is that ROCm workloads trigger segfaults or GPU resets, whereas stable operation can be achieved on certain earlier kernels. GCC 15 and PREEMPT_DYNAMIC are ancillary factors – important for development and performance, but not the direct cause of the crashes. The fundamental issue lies in the kernel-driver <-> user-space ROCm interface.

Recommended Action: Run a kernel version known to work (e.g. downgrade to 6.12.x or 6.14.0, or use Arch’s 6.1 LTS), and/or await an update from AMD (ROCm 6.5 or a patched 6.4.x) that explicitly fixes compatibility with >6.14 kernels. In parallel, report the issue through appropriate channels (kernel bugzilla, Fedora/Arch bug trackers, ROCm GitHub) with logs to help expedite a permanent fix. By doing so, you not only solve your immediate problem by using a compatible kernel, but also contribute to the resolution for all users in the long run.

Environment Setup to Reproduce: To aid others in reproducing or debugging this, document your environment as follows:

• Distro/Kernel: “Arch Linux, kernel 6.15.2-arch1-1, CONFIG_PREEMPT_DYNAMIC=y (using default dynamic preemption).”
• GPU: “AMD RX 580 (Polaris 20, GFX803), 8GB VRAM, connected via PCIe 3.0 x16, motherboard supports atomics = yes.”
• ROCm Container: “Docker image rocm64_gfx803_whisperx:latest (based on Ubuntu 24.04, ROCm 6.4.0 userland, PyTorch 2.6.0 built for gfx803). Run with --device=/dev/kfd --device=/dev/dri --group-add video etc.”
• Reproduce by: “Inside container, run WhisperX’s transcription on a sample audio, or simply execute /opt/rocm/bin/rocminfo. Expected: rocminfo lists device. Observed: Segmentation fault (core dumped) after printing GPU name, accompanied by kernel log messages about KFD or a GPU reset.”

Such a block of information in a bug report will be extremely useful for developers to trace the problem.

Sources

• AMD GFX803 ROCm project documentation (Robert Rosenbusch) – notes on kernel version stability
• User reports on Reddit (r/NobaraProject) – confirmation that ROCm fails on 6.14.1+ and works on 6.14.0, user workarounds by downgrading
• Issue report on ROCm GitHub – “ROCm stopped working after 6.14.0, still broken on 6.15.1”
• Linux kernel commit logs (LWN.net) – fix for GFX7/GFX8 in amdkfd and references to KFD fixes in stable series
• AMD ROCm documentation / community notes – requirement of PCIe 3.0 + atomics for GFX8 GPUs
• PyTorch issue tracker – build failures of ROCm components with GCC 15 (libstdc++ assertions)
• Gfx803_rocm Docker guide – showing container run flags and notes on rebuilding PyTorch/rocBLAS for Polaris.

[chboishabba]

**TL;DR — Your snippets are useful: the repeated
[drm] scheduler comp_1.1.1 is not ready, skipping lines in /tmp/gpu.log point to an amdgpu ring-scheduler stall, a failure the kernel raises when the compute queue on Polaris-class GPUs (RX 470/480/570/580, ID 0x67DF) stops making forward progress. This is almost always a driver/firmware regression, power-management corner case or ROCm-compute quirk rather than an outright hardware defect. Below you’ll find (1) what the message means, (2) the most common root-causes on Arch, (3) quick checks you can run right now, (4) a “safe-bisect” recipe that won’t endanger your main install, and (5) longer-term options if the card itself is marginal.

---

1 What the key log lines actually mean

Log line | Meaning | Why it matters -- | -- | -- scheduler comp_1.1.1 is not ready, skipping | Kernel scheduler can’t wake the compute ring comp_1 after a job timeout. | GPU is wedged; driver refuses to submit new work, causing the UI freeze you observed. bbs.archlinux.org amdgpu_job_timedout + GPU reset begin! | Kernel tried a soft reset of the affected ring. | If the reset also stalls, the card hard-locks and takes Xorg/Wayland with it. lore.kernel.org Polaris10 / PCI ID 0x67DF | Confirms you are on a Polaris-class desktop card (RX 570/580). | Important because many newer ROCm builds and some recent kernels drop full Polaris support. techpowerup.com

**TL;DR — Your snippets are useful: the repeated [drm] scheduler comp_1.1.1 is not ready, skipping lines in /tmp/gpu.log point to an amdgpu ring-scheduler stall, a failure the kernel raises when the compute queue on Polaris-class GPUs (RX 470/480/570/580, ID 0x67DF) stops making forward progress. This is almost always a driver/firmware regression, power-management corner case or ROCm-compute quirk rather than an outright hardware defect. Below you’ll find (1) what the message means, (2) the most common root-causes on Arch, (3) quick checks you can run right now, (4) a “safe-bisect” recipe that won’t endanger your main install, and (5) longer-term options if the card itself is marginal. 1 What the key log lines actually mean Log line Meaning Why it matters scheduler comp_1.1.1 is not ready, skipping Kernel scheduler can’t wake the compute ring comp_1 after a job timeout. GPU is wedged; driver refuses to submit new work, causing the UI freeze you observed. [bbs.archlinux.org](https://bbs.archlinux.org/viewtopic.php?id=302729&utm_source=chatgpt.com) amdgpu_job_timedout + GPU reset begin! Kernel tried a soft reset of the affected ring. If the reset also stalls, the card hard-locks and takes Xorg/Wayland with it. [lore.kernel.org](https://lore.kernel.org/all/bug-219895-2300-sna5i9njlR%40https.bugzilla.kernel.org%2F/?utm_source=chatgpt.com) Polaris10 / PCI ID 0x67DF Confirms you are on a Polaris-class desktop card (RX 570/580). Important because many newer ROCm builds and some recent kernels drop full Polaris support. [techpowerup.com](https://www.techpowerup.com/forums/threads/amd-rocm-4-5-drops-polaris-architecture-support.288864/?utm_source=chatgpt.com) 2 Why Polaris cards hit this bug in 2024

Regression in 6.8/6.9 DRM scheduler – Several reports show the new out-of-order job logic mis-handles ring timeouts on GFX8 GPUs, producing the exact comp_1.* warning you see.
bbs.archlinux.org
shatsky.github.io

ROCm ≥ 5.x no longer ships Polaris firmware – When a compute workload tries to initialise HIP/ROCm on an unsupported card the KFD layer wedges, leading to the stall.
techpowerup.com

Aggressive runtime-PM – The default amdgpu.runpm=1 path powers the card down between frames; on some boards it never wakes correctly after heavy load.

3 Quick triage steps (5 min each)

Boot the LTS kernel (6.6-LTS on Arch) – Many users confirm 6.6 does not trigger the comp_1 stall.

Disable runtime-PM for one session:

sudo grub-editenv - set \"amdgpu.runpm=0 amdgpu.gpu_recovery=1\"

→ prevents the card from fully powering down and enables early ring reset logic.
bbs.archlinux.org

Update Polaris firmware (pacman -S linux-firmware) – AMD pushed a new polaris10_k_smc.bin that fixes power-gate sequences.
docs.kernel.org

Stress-test underclock vs. default – If a mild core/mem down-clock stops the stall, the issue is voltage-margin rather than software.
github.com

Confirm no ROCm workloads – rocm-smi --showpids; if anything is listed, kill it or install ROCm 4.5 (the last version that supports Polaris).
techpowerup.com

If any single step eliminates the hang you’ve found the trigger; keep that workaround while you investigate a permanent fix.
4 Capturing better diagnostics
What to capture How Why
Verbose DRM trace add drm.debug=0x1ff log_buf_len=4M on the kernel cmd-line Gives per-ring timeline, invaluable when filing bugs.
kernel.org
Full GPU reset trace echo 'w' sudo tee /sys/kernel/debug/dri/0/amdgpu_debugfs_gpu_reset after a freeze
Power / temp history watch -n1 rocm-smi -a or watch -n1 sensors Over-temp throttling can masquerade as a scheduler hang.
lore.kernel.org

[chboishabba]

https://nvd.nist.gov/vuln/detail/CVE-2025-21940

[robertrosenbusch]

@chboishabba : What did i told and freaked out here on my Git-Repo?

---

Why do I thank you for your feedback(s)? Because you pointed out something to me that I really never thought possible. Kernel versions.

I don't know which Indian, Chinese, Russian, MAGA or AI was or is involved... I like them all. but producing this shit (!!!!!!!) without regresstion tests for the /dev/dri and /dev/kfd on gfx803 under 6.13 is really going too far. And all the fringe distros just take it over. I'm foaming at the mouth right now. Anyway.

Take a look on ARCH Linux where i am easy able to switch between the delivered Kernel Stuff 6.13 and the future Kernel 6.14 without a recompile.

Mmmh :-)

[chboishabba]

Brother, chill. You've done the community a big favour by making this repo. The fact you're getting so many requests points to how useful your work has been. I'm trying to assist with a lot of the issues here as well, I get email notifications for them all. Nobody expects you to manage these other kernels. On my end, I am trying to narrow down exactly which kernel commits led to breaking your work. Ultimately there should be upstream tests or something I will be able to pass to you. You have shown that it works on *A* kernel version. That much is sufficient. Update it with respect to your needs. I get it might feel overwhelming. But this repo is making a difference. Don't let it bog you down.

…

On Sat, 21 June 2025, 6:21 am Robert Rosenbusch, ***@***.***> wrote: *robertrosenbusch* left a comment (robertrosenbusch/gfx803_rocm#35) <#35 (comment)> @chboishabba <https://github.com/chboishabba> : What did i told and freaked out here on my Git-Repo? ***@***.*** : Why do I thank you for your feedback(s)? Because you pointed out something to me that I really never thought possible. Kernel versions. I don't know which Indian, Chinese, Russian, MAGA or AI was or is involved... I like them all. but producing this shit (!!!!!!!) without regresstion tests for the /dev/dri and /dev/kfd on gfx803 under 6.13 is really going too far. And all the fringe distros just take it over. I'm foaming at the mouth right now. Anyway. Take a look on ARCH Linux where i am easy able to switch between the delivered Kernel Stuff 6.13 and the future Kernel 6.14 without a recompile.` Mmmh :-) — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGM4B3S6QSRDDX7SMGUTKV33ERUNZAVCNFSM6AAAAAB7MAPA46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJSGY4TGMRVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chboishabba]

I am working on the regression tests myself, I was just letting you know, in case it was helpful. My life is still a whirlwind and I just need somewhere central to store my research. I think GitHub should show I am passing these issues up to eg ROCm official, with intention to contribute to kernel given sufficient aptitude on my end. Best regards

…

On Mon, 23 June 2025, 5:13 pm Johl Brown, ***@***.***> wrote: Brother, chill. You've done the community a big favour by making this repo. The fact you're getting so many requests points to how useful your work has been. I'm trying to assist with a lot of the issues here as well, I get email notifications for them all. Nobody expects you to manage these other kernels. On my end, I am trying to narrow down exactly which kernel commits led to breaking your work. Ultimately there should be upstream tests or something I will be able to pass to you. You have shown that it works on *A* kernel version. That much is sufficient. Update it with respect to your needs. I get it might feel overwhelming. But this repo is making a difference. Don't let it bog you down. On Sat, 21 June 2025, 6:21 am Robert Rosenbusch, ***@***.***> wrote: > *robertrosenbusch* left a comment (robertrosenbusch/gfx803_rocm#35) > <#35 (comment)> > > @chboishabba <https://github.com/chboishabba> : What did i told and > freaked out here on my Git-Repo? > > ***@***.*** : Why do I thank you for your feedback(s)? Because you > pointed out something to me that I really never thought possible. Kernel > versions. > > I don't know which Indian, Chinese, Russian, MAGA or AI was or is > involved... I like them all. but producing this shit (!!!!!!!) without > regresstion tests for the /dev/dri and /dev/kfd on gfx803 under 6.13 is > really going too far. And all the fringe distros just take it over. I'm > foaming at the mouth right now. Anyway. > > Take a look on ARCH Linux where i am easy able to switch between the > delivered Kernel Stuff 6.13 and the future Kernel 6.14 without a recompile.` > > Mmmh :-) > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AGM4B3S6QSRDDX7SMGUTKV33ERUNZAVCNFSM6AAAAAB7MAPA46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJSGY4TGMRVHE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >