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?
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.
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.
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?
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?
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.
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.
/etc/mkinitcpio.conf
...
MODULES=()
...
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.
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.
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.
