[TRACKING] Framework 16 & Linux 6.9.0-rc4/rc5 - extreme screen flickering - anyone else?

Recently I have tested the Linux mainline kernel in development 6.9.0 rc4 and rc5 by installing Arch Linux package linux-mainline.

I noticed that both kernels do not work properly, in contrast to kernel 6.8.7 which works fine.

The screen flickers and is most of the time black. When typing or moving the mouse the screen is visible for a short time (1 second or less) and then turns black again.

I am wondering if this is just my machine or my configuration or if anyone else is seeing this behavior. If so, then this might be an upstream issue and should be bisected and reported before the formal release of kernel version 6.9.0.

Has anybody else tested kernel 6.9.0 and what are your experiences with the Framework 16?

Even if it’s a regression just for you, yes please bisect ASAP to understand it. Not very much time left before 6.9 release.

This was mentioned for some in the Fedora Rawhide kernel. However, I am not running it (due to that issue).

+1 to Mario - I would definitely recommend creating a bug (I dont use Arch, so I am not much help there).

I will bisect the kernel between 6.8.7 and 6.9.0-rc4. I am no too proficient in this, so it might take a bit longer. :slight_smile:

1 Like

FWIW (and maybe to usefully rule something out?) Fedora’s 6.9.0-0.rc5.44.fc41.x86_64 seems fine, albeit on a fw 13 AMD. Both laptop screen and external (via USB4 dock/DP) work without issues.

Just a thought: Does disabling scatter/gather with amdgpu.sg_display=0 make any difference?

Likewise in this train of thought, did you already upgrade to 3.03 BIOS?

I haven’t tried yet. I am in the middle of the bisection, which I will finish first. Thanks for the suggestion.

Yes, the system is running BIOS 3.03.

DMI: Framework Laptop 16 (AMD Ryzen 7040 Series)/FRANMZCP09, BIOS 03.03 03/27/2024

The bisection seems to be going well. I have several cases of good and bad situations, so it seems to be zooming into a possible bad commit.

The bisection is completed.

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[2f14c0c8cae8e9e3b603a3f91909baba66540027] drm/amd/display: Use freesync when `DRM_EDID_FEATURE_CONTINUOUS_FREQ` found

The offending commit is a amdgpu freesync patch specifically for the Framework 16 laptop with author Mario Limonciello. I guess you know what to do with this. :wink:

This is the offending commit.


I guess Freesync gets enabled, but it is not working properly.
The laptop is unusable in that state.

What compositor?

I think it is irrelevant.

The problem shows in the early boot process. The LUKS disk decryption passphrase input box is (almost) not visible. I need to type the decryption passphrase blindly, after which the SDDM login manager shows with the same problem.

If I type the linux user password blindly, then the login process continues and the desktop is loaded, but still almost invisible.

The screen is only shortly visible when typing or moving the mouse. If not typing or moving the mouse, then the screen turns black.

Do you need a video (using a mobile phone) from the laptop booting, or is this clear enough?

System details

  • Framework 16 - Ryzen 9 7940HS w/ Radeon 780M - no dGPU
  • Arch Linux
  • LUKS disk encryption
  • Plymouth
  • SDDM
  • Desktops: KDE Plasma + LXQt

OK something still doesn’t add up. That commit backported to 6.8.3 (as 23769fa6df257091bf401c52c2a8d307239e5531). If your bisect started at 6.8.7 as a good commit, this bisect seems incorrect.

I think a video would be helpful for me to understand the behavior.

Secondarily; are you using simpledrm in the initrd or amdgpu?

Can you post your Kconfig, maybe as a gist?

I did the bisection based on the available git tags in the linux-mainline git repository, which were: v6.8 and v6.9-rc4.

I agree. If it has been backported to 6.8.3, then the problem should show in Arch Linux stable kernel 6.8.7 as well… but it does not. :slight_smile:

If I understand the question correct: Arch Linux uses mkinitcpio to create the init ramdisk. There is a possibility of adding modules for early loading, however this is not the case on my system.



I will post my Kconfig and a video in a seperate reply.

In that case I think the bisect is incorrect and there is a second problem. Perhaps you should redo it apply that commit in anything missing along the way to see if you land on a second commit. I suspect you will.

If I understand the question correct: Arch Linux uses mkinitcpio to create the init ramdisk. There is a possibility of adding modules for early loading, however this is not the case on my system.

Unpack your initramfs and see if there is an amdgpu.ko added by mkinitcpio and the matching firmware for it. If there’s not, I don’t see how this bug could be in amdgpu.

Here a bit of a clumsy attempt to create a video (3m15) with one hand holding a phone and the other typing passwords. :slight_smile:

Roughly I try to show the following steps.

  • LUKS passphrase input visible (6.8.7)
  • Reboot (ctrl-alt-del)
  • Framework BIOS logo
  • Systemd boot menu
  • Selecting the linux-mainline (6.9.0 - bisected version, not a proper rc)
  • LUKS passphrase is not visible
  • Typing passphrase
  • SDDM login is shortly visible
  • Typing linux password
  • Desktop is shortly visible
  • Reboot
  • Show working version when selecting stable kernel 6.8.7

I understand there might be another offending commit, however I am just not sure how to find that. Can you give me some pointers of the process how to find it?

Sure. Basically save the patch with git format-patch -1 23769fa6df257091bf401c52c2a8d307239e5531.
Apply that v6.8 and ]make sure issue doesn’t happen.

Assuming it doesn’t start a new bisect and on every step apply the patch like this: patch -p1 < FOO.PATCH before you build a step. If it says it’s already applied treat it as normal. This way you’ll look for the second problem.

I have chosen the lazy way and reverted the patch on top of the bisected linux-mainline tree.

git revert 2f14c0c8cae8e9e3b603a3f91909baba66540027

After the revert, the bisected 6.9.0 kernel works fine.

I will perform another revert test by deleting the complete linux-mainline package including the cache and compile and install it again; this should be 6.9.0-rc5.
It should still show the reported problem.

Then I will revert the patch on the clean 6.9.0-rc5. If this makes it work again, then we at least have a possible fix for the release of 6.9.0, unfortunately without freesync.

I will report the result of this soon.