6.9.1.arch1-1 crashing when reaching graphical interface
Description:
When updating to 6.9 or greater, as soon as the graphical session starts, the system freezes. This applies to linux, linux-zen and through testing, also the latest LTS. However, when building linux-git from the AUR, 6.9.1 works fine and doesn't show any of the issues from the Arch kernel. I was able to apply the Arch kernel patches to the linux-git package and it also worked fine.
Additionally, when using the Arch kernel 6.9 or above, if I remove one of my monitors from the equation and boot single monitor, the issue is gone. I can power on the monitor after the graphical session starts and use it, however, resuming from sleep results in the same crash.
Additional info:
-
≥ linux 6.9.arch1-1, linux-zen 6.9.1.zen1-1, linux-lts 6.6.31-1 (haven't tried older LTS versions)
-
config and/or log files:
- this is a full output from a single boot until the crash happens. My system is set to auto-login, so it all happens relatively quickly.
I would like to try the arch kernel without patches, however, I'm not able to successfully modify the PKGBUILD to complete that.
Activity
added priority3-normal severity4-low statusunconfirmed labels
assigned to @freswa, @anthraxx, @toolybird, and @gromit
If needed,
amdgpuissues can be reported upstream at https://gitlab.freedesktop.org/drm/amd. But if it's already fixed on mainline.. probably no point. The chances are a fix will filter through to the stable tree before too long..added scoperegression statuswaiting-input labels and removed statusunconfirmed label
If you want you could try to install this kernel which the regular
linuxpackage but built with the config fromaur/linux-git:$ sudo pacman -U https://pkgbuild.com/~gromit/linux-53/linux-6.9.1.arch1-1.1-x86_64.pkg.tar.zstIf that works for you the config is to blame, if it does not we'll need to find the commit that has caused the issue
Also, did you also check if the 6.9 (mainline release) kernel has this issue for you? You can check either via
aur/linux-mainline(has a repo with precompiled stuff) or via the repo package:$ sudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.9.arch1-1-x86_64.pkg.tar.zst- Using:
$ sudo pacman -U https://pkgbuild.com/~gromit/linux-53/linux-6.9.1.arch1-1.1-x86_64.pkg.tar.zst https://pkgbuild.com/~gromit/linux-53/linux-headers-6.9.1.arch1-1.1-x86_64.pkg.tar.zstFreezes my main tty on boot at
[ OK ] Finished Virtual Console Setup., but switching to another one allows me to enter. Hyprland still crashes, unable to properly check SDDM.Full Crash log: arch1-1.1.txt
- Using:
$ sudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.9.arch1-1-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/l/linux/linux-headers-6.9.arch1-1-x86_64.pkg.tar.zstDoes not freeze my main tty, launches SDDM perfectly fine. Hyprland still crashes when attempting to connect to GPU for rendering.
Full Crash log: 6.9-arch1-1.txt
NOTE: dkms modules were installed correctly for each of the tests i performed.
The only mkinitcpio warnings I have gotten:
==> WARNING: Possibly missing firmware for module: 'qed' ==> WARNING: Possibly missing firmware for module: 'qla1280' ==> WARNING: Possibly missing firmware for module: 'wd719x' ==> WARNING: Possibly missing firmware for module: 'qla2xxx' ==> WARNING: Possibly missing firmware for module: 'bfa' ==> WARNING: Possibly missing firmware for module: 'aic94xx'Which should totally be fine.
Edited by Alex Murkoff$ sudo pacman -U https://pkgbuild.com/~gromit/linux-53/linux-6.9.1.arch1-1.1-x86_64.pkg.tar.zst$ sudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.9.arch1-1-x86_64.pkg.tar.zstBoth of these crash for me.
So at present -
- 6.9+ with arch config crashes
- 6.9 without arch config crashes
- 6.9 mainline crashes
- linux-git works.
Should I just build 6.9 myself then and see if it crashes as well to get the bad starting point for bisecting? Seems like Arch might not be the culprit.
commit 34241dc665cf21bc628f1fea2249adb10010dfc0 drm/amd/display: reenable windowed mpo odm support on dcn32 and dcn321Well, that is where I ended up, which makes sense as the issue is clearly drm related. I'm curious to learn if there's a way for me to build 6.9 without that specific commit to test it?
Yes. Add the following before the patch application block in the prepare function of the PKGBUILD:
git revert -n 34241dc665cf21bc628f1fea2249adb10010dfc0Edited by loqsSeems simple enough, yet here I am... lol
... prepare() { cd $_srcname echo "Setting version..." echo "-$pkgrel" > localversion.10-pkgrel echo "${pkgbase#linux}" > localversion.20-pkgname git revert -n 34241dc665cf21bc628f1fea2249adb10010dfc0 local src for src in "${source[@]}"; do src="${src%%::*}" src="${src##*/}" src="${src%.zst}" [[ $src = *.patch ]] || continue echo "Applying patch $src..." patch -Np1 < "../$src" done ...results in
==> Starting prepare()... Setting version... fatal: bad object 34241dc665cf21bc628f1fea2249adb10010dfc0 ==> ERROR: A failure occurred in prepare(). Aborting...Are you applying it to the tarball based linux PKGBUILD? If so you would need to add the patch to the sources then revert it:
--- a/PKGBUILD +++ b/PKGBUILD @@ -34,6 +34,7 @@ _srctag=v${pkgver%.*}-${pkgver##*.} source=( https://cdn.kernel.org/pub/linux/kernel/v${pkgver%%.*}.x/${_srcname}.tar.{xz,sign} $url/releases/download/$_srctag/linux-$_srctag.patch.zst{,.sig} + 34241dc665cf21bc628f1fea2249adb10010dfc0.diff::https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=34241dc665cf21bc628f1fea2249adb10010dfc0 config # the main kernel config file ) validpgpkeys=( @@ -46,11 +47,13 @@ sha256sums=('01b414ba98fd189ecd544435caf3860ae2a790e3ec48f5aa70fdf42dc4c5c04a' 'SKIP' '8cb3d0a2769d1471c38fb5f1bdd1395333790453a399767c3af8673bc6a714b5' 'SKIP' + 'ef5e05d11aee99a383ae53c9128a8e43df523ea3782f5852bc301f047e942891' 'bbf3ebee5fcf2780a5f6b14fd13ceea809b0e332eebc452a63b5d0513747bf7e') b2sums=('388af1d13e78a424f72a961697f4b0b6a234e54ce1e4a2532fc73717301e048c6f4a6251b6e3c4541179d1382566c3f411baa6883818a10d178ef27d036b5379' 'SKIP' '3d8c25071e26979713ea100a4dca112eccd21bc421a6292354f49b19b462697985777fb7624d7fed320ea392d20b121c03b9af2f6b3fe1a6d7d511e092395ed2' 'SKIP' + '8bcdf31e3de0845c1bdf91159c783f5d15205952285997b5ce5aaabdf1b209034fa9dd6980e4c358cd0809e4a224d5a725024a94efeb84bca9a35c153c9ca955' '7834f8e796d188bad31689f85cad01fdd9311b1f40d37405bcf64b44245008e44cff09410690e6e9b67dc8f6281f02fcf60b355e5844eaffd4906a19a0cba6b8') export KBUILD_BUILD_HOST=archlinux @@ -64,6 +67,8 @@ prepare() { echo "-$pkgrel" > localversion.10-pkgrel echo "${pkgbase#linux}" > localversion.20-pkgname + patch -Rp1 -i ../34241dc665cf21bc628f1fea2249adb10010dfc0.diff + local src for src in "${source[@]}"; do src="${src%%::*}"I certainly wasn't going to be able to figure out that wizardry, so thanks. That worked and I can confirm that 6.9.1-arch works with that commit removed, albeit with a nasty stutter that completely freezes everything for a moment every maybe 5 seconds? This is all anecdotal, but I experienced that on 6.8.x as well, however, it was considerably less noticeable and not nearly as impactful.
linux-gitdidn't seem to be as bad, but I'll retry that one as well.So, with all of that being said, since
linux-gitdoesn't have the issue and you all have helped me confirm that arch isn't the issue, should I just wait it out then? Or would it be worthwhile taking it to the drm gitlab and creating an issue there for it?edit - just built linux-git again from the AUR and it's flawless. 6.8.9-arch was good, 6.9.x with the problem commit removed works, but poorly and linux-git is the superior one out of all of them.
Edited by ScottYou can use git bisect to find the fixed commit:
git bisect start --term-new=fixed --term-old=unfixed git bisect fixed git bisect unfixed v6.9-
Did you ever check what fixes the issue @u-2at? Then we could maybe point the stable team and subsystem maintainers to it so they can backport the fix
-
Also feel free to use the kernels I already prebuilt: https://pkgbuild.com/~gromit/linux-bisection-kernels/
If you want I can also build you missing images
Edited by Christian Heusel It's okay. You guys do more than enough. I used the linux-git aur package this time around and it was insanely faster than doing it all manually.
So I finished up and ran the commands mentioned above to try and isolate the fixed commit and received this -
❯ git bisect start --term-new=fixed --term-old=unfixed Updating files: 100% (25015/25015), done. Previous HEAD position was 340383c734f8 drm/amd/display: Remove pixle rate limit for subvp Switched to branch 'master' Your branch is up to date with 'origin/master'. status: waiting for both good and bad commits ❯ git bisect fixed status: waiting for good commit(s), bad commit known ❯ git bisect unfixed v6.9 Bisecting: 6677 revisions left to test after this (roughly 13 steps) [db5d28c0bfe566908719bec8e25443aabecbb802] Merge tag 'drm-next-2024-05-15' of https://gitlab.freedesktop.org/drm/kernelSo does this mean I need to do another round of bisecting to get to the fixed commit?Never mind... I actually read the link above and realized I'm in a new fixed/unfixed series. Had no idea this was a thing. Pretty cool.Edited by ScottI got about 3 or 4 revisions in and hit a wall. It errored out, so I figured I'd try
make cleanto reset things a bit, and it didn't work. Ultimately, that lead to me runningmake oldconfigbecause it was complaining about a missing .config, but even after doing that, I'm still hitting a wall -Warning: 'make modules_install' requires /doesnt/exist. Please install it. This is probably in the kmod package. ==> Tidying install... -> Removing libtool files... -> Purging unwanted files... -> Removing static library files... -> Copying source files needed for debug symbols... -> Compressing man and info pages... ==> Checking for packaging issues... ==> Creating package "linux-git"... -> Generating .PKGINFO file... -> Generating .BUILDINFO file... -> Adding install file... -> Generating .MTREE file... -> Compressing package... ==> Starting package_linux-git-headers()... Installing build files... install: cannot stat 'tools/bpf/resolve_btfids/resolve_btfids': No such file or directory ==> ERROR: A failure occurred in package_linux-git-headers(). Aborting...-
I think that was only introduced recently: 3d3514fd Maybe you'll have to revert the change mentioned above
@gromit that is indeed what it was, so thanks for that. I was able to get through the rest of it today and here's the result. I'll bring all of these findings over the the issue on the drm gitlab page. Thanks for the help, everyone!
ab6a0edb7ded060e84dc1a24e3936c86c3d048b9 is the first fixed commit commit ab6a0edb7ded060e84dc1a24e3936c86c3d048b9 Author: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Date: Mon Apr 22 07:43:55 2024 -0600 Revert "drm/amd/display: Add fallback configuration when set DRR" This reverts commit d76c0a23b557c6ebb3fac32548100d76a1e0ce23. This change must be reverted since it caused soft hangs when changing the refresh rate to 122 & 144Hz when using a 7000 series GPU. Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reported-by: Mark Broadworth <Mark.Broadworth@amd.com> Cc: Daniel Wheeler <daniel.wheeler@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-)
- Resolved by Christian Heusel
Can confirm, same is happening on my system. NVidia, Hyprland. Downgrading to
linux 6.8.9.arch1-2 linux-headers 6.8.9.arch1-2Fixes the issue. Software rendering still works, SDDM loads fine. The Hyprland doesn't seem to be the one responsible for the issue, as GPU rendering broke specifically after kernel update.
- Last reply by Alex Murkoff
Hey, @ptr1337 ! I tried to pass it as a kernel param for my efistub, didn't seem to change anything for 6.8.9.arch1-2, but passing it for 6.9.1.arch1-1 seems to break even sddm, as the system isn't even able to launch it, being stuck in an infinite loop.
Wlroots-hyprland doesn't launch either, still can't find the GPU.
[CRITICAL] m_sWLRRenderer was NULL! This usually means wlroots could not find a GPU or enountered some issues. [CRITICAL] Critical error thrown: wlr_gles2_renderer_create_with_drm_fd() failed!Does your system have an amdgpu? Can you reproduce the bisection results?
Hey, @loqs! I don't have any AMD GPUs I could use to test, but my brother's rx560 (laptop) seems to work fine on the latest kernel release. I'll keep You updated in case his system starts failing to reach graphical interface.
I faced the same issue on 6.9.1.hardened1-2 but for me everything works fine on 6.9.1.arch1-2. I'm using nvidia-open-dkms 550.78-5 which won't compile on 6.8.9.hardened.* (mkinitcpio can't find nvidia module) but works fine on 6.8.9.arch1-2. So based on that I assume that newer versions of nvidia-open-dkms conflicts with some parameters in config.
Hey, @loqs, just wanted to make sure, You wanted me to bisect the linux repo or PKGBUILD repo?
That would be wonderful, @gromit. Do i just mark as "good" the last commit that was working and mark the first that isn't working as "bad"?
Then, after the bisection is started, it will scroll through all the commits starting from the one that comes right after the one that was working, while automatically checking out?
Also... Do i just git clone the Torvald's repo and scroll through commits, or should i clone the ArchLinux's Linux repo?
Sorry if this sounds silly of me, Git is still really confusing to me...
Edited by Alex Murkoff-
Yeah that is roughly how it is working:
- You mark the starting commits as good/bad
- You keep build and testing the revision it throws at you
- You tell if the current build is good or bad
That just continues until the culprit is found
I can also just provide you the kernels to test (like I did in #56 (comment 187650))
Can you please test the three kernels from #56 (comment 187653).
Well, I tried installing the mainline-linux package from the bisection
sudo pacman -U https://pkgbuild.com/~gromit/linux-56/linux-mainline-v6.8.r8073.g480e035-1-x86_64.pkg.tar.zst https://pkgbuild.com/~gromit/linux-56/linux-mainline-headers-v6.8.r8073.g480e035-1-x86_64.pkg.tar.zstThe main problem is that there is not enough space on my boot partition for that...
-> Early uncompressed CPIO image generation successful zstd: error 70 : Write error : cannot write block : No space left on device bsdtar: Write error bsdtar: Write error ==> ERROR: Initcpio image generation FAILED: 'bsdtar (step 1)' reported an errorMy /boot/ is only 512MB in capacity... I guess I could remove the main kernel and replace it with the mainline one for testing?
-
Uh thats indeed a bit small
I think generally its a good idea to still have another kernel lying around because after all its a mainline kernel, so some other issues might arise with it during the bisection (usually nothing major). But if you choose to go the route of uninstalling the 'linux' package maybe create yourself a usb of which you can do a possible rescue from first.
Thanks, @gromit! I've managed to install the mainline kernel by removing the fallback images and disabling them in configs. I'm using efistub, should I just create a EFI entry for
vmlinuz-linux-mainline?-
Uhm, I guess ...? (I don't know this tool, I have only used
grubandsystemd-boot)Maybe confirm that you have ended up with the right kernel after booting by running
uname -aEdited by Christian Heusel Alrighty, I've booted to the mainline kernel successfully! Unfortunately, WLRoots renderer is still unable to find my GPU, even though it is there... Even SDDM managed to pick it up!
Just in case, I'm referring to the
https://pkgbuild.com/~gromit/linux-56/linux-mainline-v6.8.r8073.g480e035-1-x86_64.pkg.tar.zstkernel.So... This one commit doesn't work... I suppose it is expected?
Edited by Alex Murkoff-
Can you please test the three kernels from #56 (comment 187653).
Did you test all three kernels? So also confirmed that 6.8 works and 6.9 does not?
-
@loqs just FYI, I have put all the prebuilt kernels from the latest bisections here: https://pkgbuild.com/~gromit/linux-bisection-kernels/
Edited by Christian Heusel -
@loqs do you want to continue with this or should I?
-
Please test:
sudo pacman -U https://pkgbuild.com/~gromit/linux-bisection-kernels/linux-mainline-v6.8.rc6.r1453.g119b225-1-x86_64.pkg.tar.zstEdit: sorry, wrong link!
Edited by Christian Heusel @413x1nkp have you posted a dmesg for your issue?
v6.7.rc5.r2691.gd559744-1has everything working as intended.@loqs Here's the dmesg for 6.9: dmesg-6.9
Also, just for comparison, here's the dmesg for 6.8.9: dmesg-6.8.9
Edited by Alex MurkoffYeah,
6.8.0-rc3-1-mainline-00208-g0d966d59d1e5works.Also, should I post dmesg of every bisection that doesn't work?
Edited by Alex MurkoffIf the bisect ends up in efifb or sysfb it may be worth checking if enabling NVIDIA#DRM_kernel_mode_setting resolves the issue.
Edited by loqsThis one works well.
6.7.0-rc5-1-mainline-02495-g29f3067a236aEdited by Alex MurkoffThis one didn't work. Here's the dmesg: dmesg
This one performed even worse than the last one. Here's the dmesg: dmesg
-
Seems like have landed on one of the regions @loqs already suggested in #53 (comment 188798)
$ 9040d0297a476a4cea468663741177a79c19626b git bisect good 9040d0297a476a4cea468663741177a79c19626b is the first bad commit commit 9040d0297a476a4cea468663741177a79c19626b Author: Thomas Zimmermann <tzimmermann@suse.de> Date: Mon Feb 12 10:06:12 2024 +0100 fbdev/efifb: Remove PM for parent device The EFI device has the correct parent device set. This allows Linux to handle the power management internally. Hence, remove the manual PM management for the parent device from efifb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-5-tzimmermann@suse.deClick to see bisect log
$ it bisect log git bisect start # status: waiting for both good and bad commits # bad: [a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6] Linux 6.9 git bisect bad a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 # good: [e8f897f4afef0031fe618a8e94127a0934896aba] Linux 6.8 git bisect good e8f897f4afef0031fe618a8e94127a0934896aba # bad: [480e035fc4c714fb5536e64ab9db04fedc89e910] Merge tag 'drm-next-2024-03-13' of https://gitlab.freedesktop.org/drm/kernel git bisect bad 480e035fc4c714fb5536e64ab9db04fedc89e910 # good: [9187210eee7d87eea37b45ea93454a88681894a4] Merge tag 'net-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next git bisect good 9187210eee7d87eea37b45ea93454a88681894a4 # bad: [119b225f01e4d3ce974cd3b4d982c76a380c796d] Merge tag 'amd-drm-next-6.9-2024-03-08-1' of https://gitlab.freedesktop.org/agd5f/linux into drm-next git bisect bad 119b225f01e4d3ce974cd3b4d982c76a380c796d # bad: [9ac4beb7578a88baa4f7e6a59eeb5be79d7b011a] Merge tag 'drm-misc-next-2024-02-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-next git bisect bad 9ac4beb7578a88baa4f7e6a59eeb5be79d7b011a # good: [d5597444032b2f5c8624918fb5b29be5bba78a3c] drm/amdgpu: Fix HDP flush for VFs on nbio v7.9 git bisect good d5597444032b2f5c8624918fb5b29be5bba78a3c # good: [0d966d59d1e58df8555a3e6760a6eb3956b3d0ef] drm: bridge: simple-bridge: use drm_bridge_edid_read() git bisect good 0d966d59d1e58df8555a3e6760a6eb3956b3d0ef # good: [f1ee98cff3d86271491b08315fcdfa4c3f097e1e] drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects git bisect good f1ee98cff3d86271491b08315fcdfa4c3f097e1e # good: [247f2ee4498cfcaf18b3c3486dffd2302d56fc17] drm/xe: Fix a missing argument to drm_err_printer git bisect good 247f2ee4498cfcaf18b3c3486dffd2302d56fc17 # skip: [eb927f01dfb6309c8a184593c2c0618c4000c481] drm/i915/gt: Restart the heartbeat timer when forcing a pulse git bisect skip eb927f01dfb6309c8a184593c2c0618c4000c481 # good: [29f3067a236ac55f245ea8f23712a0d240cf1f30] drm/i915/alpm: Calculate ALPM Entry check git bisect good 29f3067a236ac55f245ea8f23712a0d240cf1f30 # good: [75fa9b7e375e35739663cde0252d31e586c6314a] video: Add helpers for decoding screen_info git bisect good 75fa9b7e375e35739663cde0252d31e586c6314a # skip: [d2435a8e3d683adb9143b9ad3c416ac3a4ca9688] drm/i915: Add flex arrays to struct i915_syncmap git bisect skip d2435a8e3d683adb9143b9ad3c416ac3a4ca9688 # skip: [a797099562267ebb281acd59750f1a8dbba36eef] drm/i915/huc: Allow for very slow HuC loading git bisect skip a797099562267ebb281acd59750f1a8dbba36eef # skip: [86ceaaaec59707b06216a15b3852867fa2f1574e] drm/i915/gem: Atomically invalidate userptr on mmu-notifier git bisect skip 86ceaaaec59707b06216a15b3852867fa2f1574e # good: [6f167a3673463c2b1733ff04fada65346bbc772b] Merge tag 'drm-intel-gt-next-2024-02-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next git bisect good 6f167a3673463c2b1733ff04fada65346bbc772b # bad: [784e27f2811884ab78edc713a4ef0d4deca9b668] fbdev/efifb: Do not track parent device status git bisect bad 784e27f2811884ab78edc713a4ef0d4deca9b668 # bad: [9040d0297a476a4cea468663741177a79c19626b] fbdev/efifb: Remove PM for parent device git bisect bad 9040d0297a476a4cea468663741177a79c19626b # good: [036105e3a776b6fc2fe0d262896a23ff2cc2e6b1] video: Provide screen_info_get_pci_dev() to find screen_info's PCI device git bisect good 036105e3a776b6fc2fe0d262896a23ff2cc2e6b1 # good: [9eac534db0013aff9b9124985dab114600df9081] firmware/sysfb: Set firmware-framebuffer parent device git bisect good 9eac534db0013aff9b9124985dab114600df9081 # first bad commit: [9040d0297a476a4cea468663741177a79c19626b] fbdev/efifb: Remove PM for parent deviceEdited by Christian Heusel Well, I assume this is the primary cause of the issue... I can't thank you enough for helping with this stuff, I don't think i would be able to figure this stuff on my own...
Just in case, the settings i pass to the kernel are
quiet loglevel=3 nvidia_drm.modeset=1 ibt=off vt.global_cursor_default=0 splash... But the issue still exists even withoutnvidia_drm.modeset=1and/oribt=offThe modprobe.d/nvidia.conf:
options nvidia-drm modeset=1Here's the journalctl from
linux-mainline-v6.8.rc3.r271.g9eac534-1: journalctl.logAnd the dmesg: dmesg
Please let me know if there is more information I could provide
@loqs Huh... This worked!
6.8.0-rc3-1-mainline-00271-g9eac534db001launched without issues (except that TTYs are flashing to an odd grey color on switch, for some reason) and the GPU is seen by all graphical applications.I'll test on
6.9.arch1-1and report the results though.I had tested the
nvidia_drm.fbdev=1setting already, but this time I also hadibt=offpassed with it, maybe that could be it? I'll update when I've tested this.UPDATE: the release
6.9.arch1-1doesn't work, with the same settings as onlinux-mainline-v6.8.rc3.r271.g9eac534-1... The dmesg and journalctl: dmesg journalctl.logEdited by Alex Murkoff-
@loqs hm, any idea?
The latest dmesg shows:
[ 0.000000] Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=PARTUUID=c35af39b-b346-454d-bf06-0d68302a6b26 loglevel=3 systemd.show_status=0 zswap.enabled=0 rw rootfstype=ext4 quiet systemd.show_status=0 splashIf the nvidia_drm options are being passed later in a config file so their absence is expected my only suggestion would be to work backwards through the bad bisection points to try and find where nvidia_drm.modeset=1 nvidia_drm.fbdev=1 stops fixing the issue.
Edited by loqs@loqs To be entirely honest, I wouldn't call this a fix... I mean, yes, it does mitigate the issue I had for the bisected commit; however being forced to use experimental flags like
nvidia_drm.fbdev=1doesn't really sound like a good idea.The kernel has changed something, this issue started to appear; the bisection found the first commit that has this issue. What's the point of doing another bisection, just to find when this issue stopped being mitigated by the experimental flag?
Why should it matter when/whether an additional experimental flag "fixes" it?
@loqs To be entirely honest, I wouldn't call this a fix... I mean, yes, it does mitigate the issue I had for the bisected commit; however being forced to use experimental flags like
nvidia_drm.fbdev=1doesn't really sound like a good idea.Can you reproduce the issue with an untainted kernel?
https://lore.kernel.org/regressions/321c4216-bd43-47cc-b1e5-b4f7230f241c@leemhuis.info/
Can you reproduce the issue with an untainted kernel?
With an untainted kernel as in "Without NVIDIA graphics drivers"? If so - then no, since the issue has to do with some DEs that need proper graphics drivers to even function, which means that testing them with an untainted kernel (i.e. without NVIDIA graphics drivers) is essentially impossible, unless You're using a software renderer (which also wouldn't really help since the issue is with GPU firmware handling, or something like that)
Edited by Alex MurkoffUPDATE! Just updated to 6.9.5 and it works! No clue what happened or what changed... But it just works!
I'll test 6.9.4 too, just in case.
EDIT: Just tested 6.9.4, it works too...
Now, I realize I wasted a LOT of time of other people, I just assumed that whenever this issue would be closed is whenever the problem will be fixed; which, in hindsight, is a weird assumption to make, I admit.
Thanks for Your help.
If I can somehow help - please let me know!
Best, Alex
Edited by Alex MurkoffSince this is technically a different issue, I just want to note that the original issue that I am experiencing is still present in 6.9.5.
There's an issue created on the DRM page at https://gitlab.freedesktop.org/drm/amd/-/issues/3405Issue is unrelated.Edited by ScottYour bisection found the cause was drm/amd/display: Fix DSC-re-computing 3f0b5af as in the upstream report you linked?
I assumed that was the issue when I started this. That issue was created after I started this one and the journal output and description of the issue is almost identical. However, the fixed commit that I landed on has already been implemented in 6.9.5 for sure, but I still have the issue on that kernel.
I saved every kernel I built this time though so maybe I can go back through the process and double check things.
https://bbs.archlinux.org/viewtopic.php?pid=2173443#p2173443 is the bisection log for that issue if it helps.
- Resolved by Christian Heusel
The linked journal report is not available. Can you please post the full system journal or at least all kernel messages from a boot with the issue. I am interested in how many simple drm devices are created which seems to be the cause of https://bbs.archlinux.org/viewtopic.php?id=295923.
- Last reply by Scott
I was initially going to open an issue, butk it looks like it's the same as here.
With kernels linux 6.9.1.arch1-1 and 6.9.5.arch1-1 as well as linux-zen 6.9.1.zen1-1 and 6.9.5.zen1-1, I can't boot. The system freeze at this stage:
:: running early hook [udev] Starting systemd-udevd version 256-3-arch-g5c79cde :: running hook [udev] :: Triggering uevents...I can't provide any
journalctloutput since I did not even reach the stage were something start being recorded.However, I can boot with linux-lts 6.6.34-1.
Like the author, I am several (3) monitors and have an AMD CPU (AMD Ryzen 5 1600X) and GPU (AMD Radeon RX 480).
Let me know if you want to make me try a specific kernel.
I know you mentioned that you're unable to check the journal output because of the crash, but can you load into a session with a kernel that works and run
journalctl -rb -nwhere n is the number of sessions since you booted the failing kernel? That will give you the show the final moments of your crash before it happened and we can hopefully compare. 6.10 has been stable for me and ultimately, it was never an issue with the arch kernel like I initially suspected.-
@u-2at As I said in #53 (comment 191977), it crashes too early, so in journalctl I only see the boots on the LTS kernel since I was never able to boot on vanilla and zen kernels.
@gromit Because:
- My issue appeared at the same time: 6.9
- Also have multiple monitors (3)
- Also have an AMD GPU
- Also same observed behavior
Since it's upstream, I'll have to report it to https://gitlab.freedesktop.org/drm/amd? What was the issue where this bug was reported?
-
@u-2at I'm not using a docking station but a DisplayPort Hub (https://fr.aliexpress.com/item/1005001722437306.html) which may end up being the same issue if it is MST related.
Yeah, there's a better chance it's your issue then
added resolutioncompleted label
