I don’t want to dismiss other people’s issues but just to give an alternate experience, I have been on 6.12 since it’s release and 6.12.3 since this morning and haven’t had any issue.
I have a setup usually prone to issues (plugged in a dock that is itself plugged in a KVM which is plugged to 3 screens) and my experience so far with 6.12 is better than previous kernels.
6.12 is not the LTS kernel. LTS is around 6.6.63 right now. I would recommend staying on LTS for the time being as the bleeding edge arch kernel has had major issues with the amd graphics for a while now. Lockups, multi-monitor issues, 3d accel not working in wayland with one monitor, sleep locks, etc. All these seem to go away on the LTS kernel.
Arch, Debian, Ubuntu, Manjaro, whatever. they do not dictate LTS kernels or kernel labels. Kernel maintainters dictate LTS kernels. 6.12 is indeed an LTS kernel. It will be Long Term Supported while other kernels will be deprecated and given EOL status after some time. Maintaining a complete and special kernel for their distro would be a waste of efforts, its better to depend on kernel devs and just add out of tree modules if you want them.
As for 6.12.1 its super unstable. I expect to see 6.12.4+ as being stable considering how many patches they rammed through to fix issues as soon as 6.12 was released. I just jumped on 6.13rc1 to test since Manjaro hasn’t release anything past 6.12.1 which causes lock ups for me. So Far 6.13rc1 seems stable (only been testing for a few hours) on my FW16, and it would probably be the closeset thing to 6.12.4 without me compiling the kernel myself. Stupid bluetooth module crashes have stopped. (yeah I’m still using the MT7922 wifi module).
All sorts of (I suspect) VRR related issues on 6.12.6. Running KWin 6.2.4. System will often freeze entirely (but sound will continue in the background), sometimes immediately upon logging in. Other times it’ll freeze or drop framerate down to low single digits upon opening an accelerated app like Firefox. Certain fullscreen games will always cause the system to freeze entirely, such as Final Fantasy XIV, others like Factorio will just report 60fps but actually be displaying at way less (should note that Factorio is a native OpenGL game, FFXIV uses dxvk).
All these problems go away when downgrading to 6.10.10 (the last non-lts kernel in my pacman cache) or to 6.6 lts. amdgpu.dcdebugmask=0x400 also did not help much. It stopped the Final Fantasy freeze but still had issues with logging in sometimes, and Firefox making the desktop run at single digit framerates also still happened.
Sorry, haven’t got any logs, like I said, the system freezes entirely. I’ve locked my system to 6.10.10 for the time being.
I’ve had a similar issue when watching a full-screen video in Firefox. For me, the system became almost completely unresponsive. Occasionally the mouse would eventually move when I provided input on the touchpad, but it was very slow and infrequent. I had to give up and force the system off by holding the power button.
very new FW16 with dGPU user here. Installed Arch two weeks ago and have been having somewhat regular freezes for 0.5-2 seconds ever since. The freezes occur sometimes multiple times a minute. It is most apparent when using Vivaldi (also occurs on Chromium). I’d be reading a web page and when I scroll or switch tabs, the freeze would happen. Whenever it happens, this block of stuff appears in dmesg:
dmesg output
[ 410.510908] [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).
[ 410.510968] amdgpu 0000:03:00.0: amdgpu: PSP is resuming...
[ 410.567375] amdgpu 0000:03:00.0: amdgpu: reserve 0x1300000 from 0x81fc000000 for PSP TMR
[ 410.662339] amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available
[ 410.669750] amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available
[ 410.669754] amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[ 410.669758] amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
[ 410.669763] amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x00000035, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x00525c00 (82.92.0)
[ 410.669768] amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
[ 410.709709] amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
[ 410.717991] [drm] DMUB hardware initialized: version=0x07002A00
[ 412.051184] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[ 412.051196] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[ 412.051202] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[ 412.051206] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[ 412.051210] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[ 412.051214] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[ 412.051218] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[ 412.051221] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[ 412.051223] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[ 412.051225] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[ 412.051227] amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0
[ 412.051229] amdgpu 0000:03:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[ 412.051231] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1 on hub 8
[ 412.051233] amdgpu 0000:03:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0
[ 412.056830] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes
[ 412.057540] [drm] ring gfx_32790.1.1 was added
[ 412.057888] [drm] ring compute_32790.2.2 was added
[ 412.058210] [drm] ring sdma_32790.3.3 was added
[ 412.058243] [drm] ring gfx_32790.1.1 ib test pass
[ 412.058276] [drm] ring compute_32790.2.2 ib test pass
[ 412.058350] [drm] ring sdma_32790.3.3 ib test pass
This happens regardless of whether an external monitor is connected. I’m on Gnome & Wayland with Linux 6.12.6-arch1-1 but it also happened on kernel version from the last at least one week. My FW16 has a dedicated GPU installed.
Workaround for me: Keeping nvtop running in a terminal in the background seems to help with the issue.
Based on the log output and that workaround, might it be related to GPU power management?
I am very new to Framework and hadn’t been a Linux user for like 8 years before this and I’m considering if this is worth a post on the Arch forums as well. But based on the fact that multiple people here are mentioning somewhat similar issues, it might be more Framework hardware related…?
Got basically this same thing showing up when I check dmesg on Gnome & Wayland with Linux 6.12.7-arch1-1 and mesa 24.3.1-arch1.1 after seeing display artifacts, specifically on the lower half of the display, when switching workspaces. Testing has not been done with an external monitor as I do not have one present, though I will update when I have information on that front. The symptoms seem most prevalent when switching to workspaces with Firefox, but it does not occur every single time. Have seen no issues on the Windows side of the dual boot.
I have had no signs of the freezing mentioned here though.
As mentioned, the issue seems to be absent when running amdgpu_top.
The Arch’s “auto suspend” timeout for PCI (dGPU) is ridiculously low by default. Check your file: /sys/bus/PCI/devices/0000:03:00.0/power/autosuspend_delay_ms. By default, it has a timeout of 5 sec (5000 ms). Increase it to 600000 ms (10 minutes). It solved the issue for me.
You need to modify it on each restart Does anyone know how to make the change permanent?
P.S. Just in case if your dGPU has different PCI address, use lspci to check:
I set up this udev rule as a test which seems to work. Not sure I want to keep it though. I kind of want the dGPU to suspend at the default 5 seconds when on battery. Only application the suspension annoys me a lot is in Ultimaker Cura. That app freezes up for several seconds after the gpu suspends. I’d rather just force it to use the internal gpu. I used 5 minutes (300000).
Is the external monitor connected to the rear dGPU usb port? You should not see the freezes in this case (I don’t). But yes, it is due to dGPU power management and your app requesting to use it again when you “change” something like scrolling in chromium.