You are not logged in.
The environment will not survive the shell where you exported it (logging out or rebooting will clear that, otherwise you can also https://man.archlinux.org/man/unset.n variables)
Thank you.
That's gonna be a stale XAuthority entry, https://bbs.archlinux.org/viewtopic.php?id=304410
It's not an issue per se, but you can have a look at the magic cookies and remove it (or your .XAuthority, is should™ be recreated automatically)
Actually I already did that. I also found another thread here on the forum about that error, but I will try again.
You cannot access the nvidia GPU (because nouveau is still blacklisted? "lsmod | grep nouveau")
Unfortunately not. 'Nouveau' appears in the output of:
lsmod | grep -E 'drm|amdgpu|nouveau'
amdgpu 16596992 16
nouveau 3796992 0
drm_gpuvm 49152 1 nouveau
mxm_wmi 12288 1 nouveau
amdxcp 12288 1 amdgpu
i2c_algo_bit 24576 2 amdgpu,nouveau
drm_ttm_helper 16384 3 amdgpu,nouveau
ttm 126976 3 amdgpu,drm_ttm_helper,nouveau
drm_suballoc_helper 20480 1 amdgpu
drm_exec 12288 3 drm_gpuvm,amdgpu,nouveau
drm_panel_backlight_quirks 12288 1 amdgpu
gpu_sched 65536 2 amdgpu,nouveau
drm_buddy 24576 1 amdgpu
drm_display_helper 290816 2 amdgpu,nouveau
cec 106496 2 drm_display_helper,amdgpu
video 81920 2 amdgpu,nouveau
wmi 36864 5 hp_wmi,video,wmi_bmof,mxm_wmi,nouveau
Thank you! I just set the brightness 'by writing a number to brightness' with an echo command as described in the wiki.
The cards are reversed, try to add "nvidia_drm.modeset=1" to the https://wiki.archlinux.org/title/Kernel_parameters (all that does is to block the simpledrm device, restore the normal card order and hopfully fix your backlight?)
Regarding this, in the wiki you posted (https://wiki.archlinux.org/title/Nouvea … kan_Driver), for my graphics card it recommends adding nouveau.config=NvGspRm=1 as a kernel parameters, my question is if nvidia_drm.modeset=1 can somehow interfere with this command.
And sorry about this but, if it is possible, can you explain me what do you mean with "The cards are reversed"? Thanks a lot in advance.
[edit]
I forgot to show the xauth list command
archpeter/unix:0 MIT-MAGIC-COOKIE-1 664e81022153eaff559600a15a14265b
archpeter:0 MIT-MAGIC-COOKIE-1 664e81022153eaff559600a15a14265b
archpeter:0 MIT-MAGIC-COOKIE-1 8c90f66e6371ad34ffff1700314f13cd
archpeter:0 MIT-MAGIC-COOKIE-1 8c90f66e6371ad34ffff1700314f13cd
archpeter.lan:0 MIT-MAGIC-COOKIE-1 8c90f66e6371ad34ffff1700314f13cd
And the hostnamectl output
Static hostname: archpeter
Icon name: computer-laptop
Chassis: laptop ?
Machine ID: 4a6dccc48df644c49c1722940d0d3ab7
Boot ID: bf38d55864fd471ebdec17929d5baa8a
Operating System: Arch Linux
Kernel: Linux 6.15.2-zen1-1-zen
Architecture: x86-64
Hardware Vendor: HP
Hardware Model: Victus by HP Laptop 16-e1xxx
Firmware Version: F.23
Firmware Date: Tue 2024-08-20
Firmware Age: 9month 3w 2d
As requested in the topic you shared.
Last edited by Peter_Parch (2025-06-13 18:00:16)
Offline
archpeter:0 MIT-MAGIC-COOKIE-1 8c90f66e6371ad34ffff1700314f13cd
archpeter:0 MIT-MAGIC-COOKIE-1 8c90f66e6371ad34ffff1700314f13cd
matches the cookie that flares up and as you'll notice shows up as double.
Actually I already did that.
While the X11 server was running? Don't. Do it from the multi-user.target
if nvidia_drm.modeset=1 can somehow interfere with this command.
No. You're not loading the nvidia modules anyway, all that will do is to block the simpledrm device.
can you explain me what do you mean with "The cards are reversed"?
Typically the IGP/APU is card0 and the dedicated GPU (nvidia) is card1, but the simpledrm device takes the card0 slot, the APU registers as card1, deactivates the simpledrm device, card0 becomes an open slot and the nvidia GPU picks that up.
Though in your case its even weirder because the nvidia GPU shows up as card1 (as supposed to) but the AMD one is then card2 => let's see what happens when the simpledrm device doesn't interfere.
Offline
matches the cookie that flares up and as you'll notice shows up as double.
Sorry but I don't understand what I have to do in this case.
While the X11 server was running? Don't. Do it from the multi-user.target
Ok, thank you so much! But, another time sorry for the noob's question, what do you mean with "do it multi-target.service"?
let's see what happens when the simpledrm device doesn't interfere
I'm about to try this. I hope it goes well.
Offline
I'm about to try this. I hope it goes well.
It goes well, I think. Anyway now the dedicated GPU (nvidia) is card0 and the AMD one is card1. I also noticed that the brightness increased, as if it added the brightness I adjusted the other day to the one that was there before the problems.
However the Nvidia card still not loaded.
Here the Xorg.0.log file: http://0x0.st/8EFJ.txt
And here is the output of
startx -- -logverbose 9 -verbose 9
Thanks
Offline
Please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Then remove "nouveau.config=NvGspRm=1" and try again.
Offline
Please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Here it is: http://0x0.st/8EC8.txt
Then remove "nouveau.config=NvGspRm=1" and try again.
Now I'll try it.
Offline
giu 14 11:52:36 archpeter kernel: ------------[ cut here ]------------
giu 14 11:52:36 archpeter kernel: WARNING: CPU: 10 PID: 195 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:201 r535_gsp_msg_recv+0x48f/0x620 [nouveau]
giu 14 11:52:36 archpeter kernel: Modules linked in: snd_seq_dummy rfcomm snd_hrtimer snd_seq ccm cmac algif_hash algif_skcipher af_alg bnep vfat fat amd_atl intel_rapl_msr snd_soc_dmic snd_soc_acp6x_mach snd_acp6x_pdm_dma intel_rapl_common snd_sof_amd_acp70 snd_sof_amd_acp63 snd_sof_amd_vangogh snd_sof_amd_rembrandt snd_sof_amd_renoir snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils kvm_amd snd_pci_ps snd_soc_acpi_amd_match snd_amd_sdw_acpi soundwire_amd snd_hda_codec_realtek mt7921e soundwire_generic_allocation kvm mt7921_common soundwire_bus snd_hda_codec_generic mt792x_lib snd_soc_sdca snd_hda_scodec_component snd_hda_codec_hdmi irqbypass mt76_connac_lib polyval_clmulni snd_soc_core snd_hda_intel polyval_generic uvcvideo mt76 snd_compress ghash_clmulni_intel snd_intel_dspcfg ac97_bus btusb videobuf2_vmalloc sha512_ssse3 snd_usb_audio snd_intel_sdw_acpi btrtl snd_pcm_dmaengine sha256_ssse3 uvc btintel sha1_ssse3 snd_usbmidi_lib snd_rpl_pci_acp6x videobuf2_memops mac80211 snd_hda_codec aesni_intel btbcm snd_acp_pci
giu 14 11:52:36 archpeter kernel: snd_ump videobuf2_v4l2 btmtk crypto_simd joydev snd_amd_acpi_mach libarc4 snd_hda_core snd_acp_legacy_common snd_rawmidi mousedev cryptd hp_wmi videobuf2_common snd_pci_acp6x snd_seq_device snd_hwdep sparse_keymap bluetooth wmi_bmof rapl cfg80211 snd_pcm snd_pci_acp5x ucsi_acpi r8169 videodev spd5118 snd_timer snd_rn_pci_acp3x typec_ucsi amd_pmf snd_acp_config realtek snd hid_multitouch mc i2c_piix4 typec snd_soc_acpi amdtee mdio_devres i2c_smbus k10temp ccp snd_pci_acp3x libphy rfkill soundcore roles amd_sfh i2c_hid_acpi platform_profile i2c_hid tee wireless_hotkey amd_pmc acpi_tad mac_hid crypto_user dm_mod loop nfnetlink ip_tables x_tables amdgpu nouveau drm_gpuvm amdxcp mxm_wmi i2c_algo_bit drm_ttm_helper ttm sdhci_pci drm_suballoc_helper sdhci_uhs2 drm_exec drm_panel_backlight_quirks nvme sdhci gpu_sched drm_buddy cqhci nvme_core drm_display_helper mmc_core nvme_keyring cec nvme_auth video wmi serio_raw
giu 14 11:52:36 archpeter kernel: CPU: 10 UID: 0 PID: 195 Comm: kworker/10:1 Not tainted 6.15.2-zen1-1-zen #1 PREEMPT(full) 2f7feaf691cb823e531d425333142fca39eaa226
giu 14 11:52:36 archpeter kernel: Hardware name: HP Victus by HP Laptop 16-e1xxx/8A22, BIOS F.23 08/20/2024
giu 14 11:52:36 archpeter kernel: Workqueue: pm pm_runtime_work
giu 14 11:52:36 archpeter kernel: RIP: 0010:r535_gsp_msg_recv+0x48f/0x620 [nouveau]
giu 14 11:52:36 archpeter kernel: Code: ff 48 8b 44 24 30 65 48 2b 05 85 4c cc eb 0f 85 99 01 00 00 48 83 c4 38 48 89 d8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 6c bd a9 e8 <0f> 0b 48 89 ef 48 c7 c5 92 ff ff ff e8 70 0e 0e e9 48 89 eb eb c1
giu 14 11:52:36 archpeter kernel: RSP: 0018:ffffd1e14074f978 EFLAGS: 00010246
giu 14 11:52:36 archpeter kernel: RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000fcab20
giu 14 11:52:36 archpeter kernel: RDX: ffff8f3c8eaa0d40 RSI: 0000000000000001 RDI: ffffd1e14074f8f8
giu 14 11:52:36 archpeter kernel: RBP: ffff8f39aaf00000 R08: 0000000000000002 R09: 0000000000000000
giu 14 11:52:36 archpeter kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 000000000001aa10
giu 14 11:52:36 archpeter kernel: R13: ffff8f39aaf00020 R14: 0000000000000004 R15: ffff8f39943bd000
giu 14 11:52:36 archpeter kernel: FS: 0000000000000000(0000) GS:ffff8f3ce236b000(0000) knlGS:0000000000000000
giu 14 11:52:36 archpeter kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
giu 14 11:52:36 archpeter kernel: CR2: 00007fdd9e01af50 CR3: 00000001063ba000 CR4: 0000000000f50ef0
giu 14 11:52:36 archpeter kernel: PKRU: 55555554
giu 14 11:52:36 archpeter kernel: Call Trace:
giu 14 11:52:36 archpeter kernel: <TASK>
giu 14 11:52:36 archpeter kernel: r535_gsp_rpc_push+0x161/0x1e0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: fbsr_memlist+0x159/0x1e0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: r535_instmem_suspend+0x3bc/0x670 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: ? srso_alias_return_thunk+0x5/0xfbef5
giu 14 11:52:36 archpeter kernel: ? nvkm_instmem_fini+0x2f/0x60 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nvkm_instmem_fini+0x2f/0x60 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nvkm_subdev_fini+0x6a/0xc0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nvkm_device_fini+0x94/0x140 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nvkm_udevice_fini+0x50/0x70 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nvkm_object_fini+0xb4/0x140 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nvkm_object_fini+0x70/0x140 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: nouveau_do_suspend+0xf1/0x180 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: ? srso_alias_return_thunk+0x5/0xfbef5
giu 14 11:52:36 archpeter kernel: nouveau_pmops_runtime_suspend+0x3e/0xb0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 11:52:36 archpeter kernel: pci_pm_runtime_suspend+0x6a/0x1a0
giu 14 11:52:36 archpeter kernel: ? __pfx_pci_pm_runtime_suspend+0x10/0x10
giu 14 11:52:36 archpeter kernel: ? __pfx_pci_pm_runtime_suspend+0x10/0x10
giu 14 11:52:36 archpeter kernel: __rpm_callback+0x44/0x160
giu 14 11:52:36 archpeter kernel: ? __pfx_pci_pm_runtime_suspend+0x10/0x10
giu 14 11:52:36 archpeter kernel: rpm_suspend+0x39c/0x780
giu 14 11:52:36 archpeter kernel: ? __schedule+0x455/0x2360
giu 14 11:52:36 archpeter kernel: ? srso_alias_return_thunk+0x5/0xfbef5
giu 14 11:52:36 archpeter kernel: pm_runtime_work+0x98/0xb0
giu 14 11:52:36 archpeter kernel: process_one_work+0x193/0x350
giu 14 11:52:36 archpeter kernel: worker_thread+0x254/0x3a0
giu 14 11:52:36 archpeter kernel: ? __pfx_worker_thread+0x10/0x10
giu 14 11:52:36 archpeter kernel: kthread+0xfc/0x240
giu 14 11:52:36 archpeter kernel: ? __pfx_kthread+0x10/0x10
giu 14 11:52:36 archpeter kernel: ret_from_fork+0x34/0x50
giu 14 11:52:36 archpeter kernel: ? __pfx_kthread+0x10/0x10
giu 14 11:52:36 archpeter kernel: ret_from_fork_asm+0x1a/0x30
giu 14 11:52:36 archpeter kernel: </TASK>
giu 14 11:52:36 archpeter kernel: ---[ end trace 0000000000000000 ]---
Why did you add the parameter itfp?
Offline
Why did you add the parameter itfp?
What do you mean? This is my /boot/loader/entries/arch.conf:
title Arch Linux
linux /vmlinuz-linux-zen
initrd /amd-ucode.img
initrd /initramfs-linux-zen.img
options root=PARTUUID=0ef6b543-f53c-48d7-820d-b257323f93d7 rw quiet loglevel=3 systemd.show_status=auto nmi_watchdog=0 modprobe.blacklist=sp5100_tco nvidia_drm.modeset=1 rd.udev.log_level=3 btusb.enable_autosuspend=0
And here the 'sudo journalctl -b | curl -F 'file=@-' 0x0.st' after deleted "nouveau.config=NvGspRm=1": http://0x0.st/8ECQ.txt
Also the Xorg.0.log file: http://0x0.st/8EC1.txt
And also the startx log: http://0x0.st/8ECe.txt
Offline
What do you mean?
I mean, what was that parameter meant to achieve. It's a power management parameter, the wiki somehow links it to vulkan (no idea whether that's actually required) and maybe it also was an attempt to avoid the crash?
But unfortunately
giu 14 13:07:14 archpeter kernel: ------------[ cut here ]------------
giu 14 13:07:14 archpeter kernel: WARNING: CPU: 2 PID: 130 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:201 r535_gsp_msg_recv+0x48f/0x620 [nouveau]
giu 14 13:07:14 archpeter kernel: Modules linked in: ccm snd_seq_dummy rfcomm snd_hrtimer snd_seq cmac algif_hash algif_skcipher af_alg bnep vfat fat intel_rapl_msr amd_atl intel_rapl_common snd_soc_dmic snd_soc_acp6x_mach snd_acp6x_pdm_dma snd_sof_amd_acp70 snd_sof_amd_acp63 snd_sof_amd_vangogh snd_sof_amd_rembrandt snd_sof_amd_renoir snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils kvm_amd mt7921e snd_pci_ps snd_soc_acpi_amd_match mt7921_common snd_amd_sdw_acpi soundwire_amd mt792x_lib kvm soundwire_generic_allocation snd_hda_codec_realtek mt76_connac_lib soundwire_bus mt76 snd_soc_sdca snd_hda_codec_generic irqbypass snd_soc_core polyval_clmulni snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_compress polyval_generic ac97_bus mac80211 snd_intel_dspcfg ghash_clmulni_intel snd_pcm_dmaengine snd_usb_audio snd_intel_sdw_acpi sha512_ssse3 snd_rpl_pci_acp6x sha256_ssse3 snd_acp_pci uvcvideo btusb snd_usbmidi_lib snd_hda_codec sha1_ssse3 snd_amd_acpi_mach videobuf2_vmalloc snd_ump btrtl aesni_intel
giu 14 13:07:14 archpeter kernel: snd_acp_legacy_common libarc4 uvc snd_hda_core snd_rawmidi btintel crypto_simd joydev videobuf2_memops hp_wmi snd_pci_acp6x cryptd snd_seq_device snd_hwdep btbcm mousedev videobuf2_v4l2 btmtk sparse_keymap wmi_bmof rapl snd_pcm videobuf2_common snd_pci_acp5x cfg80211 bluetooth spd5118 amd_pmf r8169 ucsi_acpi snd_timer snd_rn_pci_acp3x typec_ucsi amdtee videodev snd_acp_config snd realtek amd_sfh typec snd_soc_acpi i2c_piix4 hid_multitouch mdio_devres mc i2c_smbus k10temp ccp libphy rfkill snd_pci_acp3x soundcore roles platform_profile i2c_hid_acpi tee i2c_hid amd_pmc wireless_hotkey acpi_tad mac_hid crypto_user loop dm_mod nfnetlink ip_tables x_tables amdgpu nouveau drm_gpuvm amdxcp mxm_wmi i2c_algo_bit drm_ttm_helper sdhci_pci ttm sdhci_uhs2 drm_suballoc_helper drm_exec sdhci drm_panel_backlight_quirks nvme gpu_sched drm_buddy cqhci nvme_core drm_display_helper mmc_core nvme_keyring cec nvme_auth video wmi serio_raw
giu 14 13:07:14 archpeter kernel: CPU: 2 UID: 0 PID: 130 Comm: kworker/2:1 Not tainted 6.15.2-zen1-1-zen #1 PREEMPT(full) 2f7feaf691cb823e531d425333142fca39eaa226
giu 14 13:07:14 archpeter kernel: Hardware name: HP Victus by HP Laptop 16-e1xxx/8A22, BIOS F.23 08/20/2024
giu 14 13:07:14 archpeter kernel: Workqueue: pm pm_runtime_work
giu 14 13:07:14 archpeter kernel: RIP: 0010:r535_gsp_msg_recv+0x48f/0x620 [nouveau]
giu 14 13:07:14 archpeter kernel: Code: ff 48 8b 44 24 30 65 48 2b 05 85 4c 6c ce 0f 85 99 01 00 00 48 83 c4 38 48 89 d8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 6c bd 49 cb <0f> 0b 48 89 ef 48 c7 c5 92 ff ff ff e8 70 0e ae cb 48 89 eb eb c1
giu 14 13:07:14 archpeter kernel: RSP: 0018:ffffd3edc0603978 EFLAGS: 00010246
giu 14 13:07:14 archpeter kernel: RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000fde2ec
giu 14 13:07:14 archpeter kernel: RDX: ffff8dd88e8a0d40 RSI: 0000000000000001 RDI: ffffd3edc06038f8
giu 14 13:07:14 archpeter kernel: RBP: ffff8dd5a9b40000 R08: 0000000000000002 R09: 0000000000000000
giu 14 13:07:14 archpeter kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 000000000001aa10
giu 14 13:07:14 archpeter kernel: R13: ffff8dd5a9b40020 R14: 0000000000000004 R15: ffff8dd58e6e3000
giu 14 13:07:14 archpeter kernel: FS: 0000000000000000(0000) GS:ffff8dd8ff96b000(0000) knlGS:0000000000000000
giu 14 13:07:14 archpeter kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
giu 14 13:07:14 archpeter kernel: CR2: 000055936b05a530 CR3: 000000011d18b000 CR4: 0000000000f50ef0
giu 14 13:07:14 archpeter kernel: PKRU: 55555554
giu 14 13:07:14 archpeter kernel: Call Trace:
giu 14 13:07:14 archpeter kernel: <TASK>
giu 14 13:07:14 archpeter kernel: r535_gsp_rpc_push+0x161/0x1e0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: fbsr_memlist+0x159/0x1e0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: r535_instmem_suspend+0x3bc/0x670 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: ? srso_alias_return_thunk+0x5/0xfbef5
giu 14 13:07:14 archpeter kernel: ? nvkm_instmem_fini+0x2f/0x60 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nvkm_instmem_fini+0x2f/0x60 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nvkm_subdev_fini+0x6a/0xc0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nvkm_device_fini+0x94/0x140 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nvkm_udevice_fini+0x50/0x70 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nvkm_object_fini+0xb4/0x140 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nvkm_object_fini+0x70/0x140 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: nouveau_do_suspend+0xf1/0x180 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: ? srso_alias_return_thunk+0x5/0xfbef5
giu 14 13:07:14 archpeter kernel: nouveau_pmops_runtime_suspend+0x3e/0xb0 [nouveau 03b6b32385736c2023697739462b03279e5e9fa9]
giu 14 13:07:14 archpeter kernel: pci_pm_runtime_suspend+0x6a/0x1a0
giu 14 13:07:14 archpeter kernel: ? __pfx_pci_pm_runtime_suspend+0x10/0x10
giu 14 13:07:14 archpeter kernel: ? __pfx_pci_pm_runtime_suspend+0x10/0x10
giu 14 13:07:14 archpeter kernel: __rpm_callback+0x44/0x160
giu 14 13:07:14 archpeter kernel: ? __pfx_pci_pm_runtime_suspend+0x10/0x10
giu 14 13:07:14 archpeter kernel: rpm_suspend+0x39c/0x780
giu 14 13:07:14 archpeter kernel: ? __schedule+0x455/0x2360
giu 14 13:07:14 archpeter kernel: pm_runtime_work+0x98/0xb0
giu 14 13:07:14 archpeter kernel: process_one_work+0x193/0x350
giu 14 13:07:14 archpeter kernel: worker_thread+0x254/0x3a0
giu 14 13:07:14 archpeter kernel: ? __pfx_worker_thread+0x10/0x10
giu 14 13:07:14 archpeter kernel: kthread+0xfc/0x240
giu 14 13:07:14 archpeter kernel: ? __pfx_kthread+0x10/0x10
giu 14 13:07:14 archpeter kernel: ret_from_fork+0x34/0x50
giu 14 13:07:14 archpeter kernel: ? __pfx_kthread+0x10/0x10
giu 14 13:07:14 archpeter kernel: ret_from_fork_asm+0x1a/0x30
giu 14 13:07:14 archpeter kernel: </TASK>
giu 14 13:07:14 archpeter kernel: ---[ end trace 0000000000000000 ]---
giu 14 13:07:14 archpeter kernel: ------------[ cut here ]------------
Does it help to add "pcie_port_pm=off" to the kernel parameters?
Do you actually have that problem on the non-zen or lts kernel?
Offline
Sorry for the late reply but I haven't had time to test.
I mean, what was that parameter meant to achieve. It's a power management parameter, the wiki somehow links it to vulkan (no idea whether that's actually required) and maybe it also was an attempt to avoid the crash?
I don't remember having entered this parameter somewhere and I can't find it on the wiki. Is it on my /boot/loader/entries/arch.conf?
Does it help to add "pcie_port_pm=off" to the kernel parameters?
I'll try now.
Do you actually have that problem on the non-zen or lts kernel?
I have never tried any other kernels other than zen.
Offline
Does it help to add "pcie_port_pm=off" to the kernel parameters?
Adding this parameter made strange things happen. I don't have logs because the system automatically rebooted 3 times shortly after booting. However, on the first boot it showed me error messages related to zsh and rebooted itself while I was trying to figure it out. Then again two more times, so I immediately removed the parameter and it stopped. I fixed the error related to the .zsh_history file corruption, rebooted but it took a while, showing this message:
A stop job is running for Session1 of User user_name
And than:
[1758.995263] systemd-shutdown[1]: Waiting for process: 801 (Xorg)
Then some more pages that I don't know if they were errors but there were references to 'nouveau', I don't know how to share those log. It closed with
[6573.887571] </TASK>
[6573.887867] ---[ end trace 0000000000000000 ]---
It wouldn't restart. I tried CTRL+ALT+DEL and it restarted.
Last edited by Peter_Parch (2025-06-16 17:13:14)
Offline
Sorry for the long delay.
That's a kernel warning or error - with all the relevant parts missing
Might easily be the RIP in #34, though.
The instant reboots supposed power supply issues, ryzens are notorious for those though at this point I'd frankly test the nvidia or nvidia-open (nvidia-dkms resp. nvidia-open-dkms for the zen kernel) to check whether the hardware is actually ok.
Offline
Sorry for the long delay.
Don't worry, in fact, thanks for your help.
The instant reboots supposed power supply issues, ryzens are notorious for those though at this point I'd frankly test the nvidia or nvidia-open (nvidia-dkms resp. nvidia-open-dkms for the zen kernel) to check whether the hardware is actually ok.
That auto restart problem though only happened when I added "pcie_port_pm=off" to the kernel parameter and disappeared as soon as I removed it. Furthermore, mine is a dual boot system, on two internal but separate SSDs, with Windows and both graphics cards work well there, so the hardware should be ok, right?
Even after deleting "pcie_port_pm=off", however, the problem "A stop job is running for Session1 of User" remained, which prevented the restart and shutdown unless CTRL+ALT+DEL was used. Not all the times, however. Also, X often started, but with a delay of several seconds. In practice, when it started late, it shut down normally, and when it didn't shut down due to the "A stop job is running for Session1 of User" error, after CTRL+ALT+DEL, it started without a delay. However, now I have blacklisted nouveau again and it doesn't seem to give this problem anymore. For now, I think I'll limit myself to using only the AMD card, also because here on Arch I don't play gaming or do anything else that requires the Nvidia card.
Should I mark this topic as solved since the system no longer freezes when starting X as it title says?
Offline
Furthermore, mine is a dual boot system, on two internal but separate SSDs, with Windows
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
But as mentioned in the wiki article, windows seems less prone to trigger this behavior (but it can be caused there by tools like corecycler which provoke the problematic conditions)
"A stop job is running for Session1 of User" remained
The journal should record which job is misbehaving here.
I'll limit myself to using only the AMD card
at this point I'd frankly test the nvidia or nvidia-open
Should I mark this topic as solved since the system no longer freezes when starting X as it title says?
Yes, maybe also mention in the OP that this is nouveau specific and blacklisting it addresses the problem for now.
Offline
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Thanks. I had already disabled Fast-Start and Hybernation, but I still checked with the Windows commands recommended in the wiki and to be safe I launched the command
powercfg /H off
in the Windows shell and restarted both OS twice for woodo reasons. Anyway, I always believe for some strange reason woodo, after this operation the 'dual pairing' bluetooth of the mouse no longer works, which I had managed to make work on both OS without having to re-pair every time I switched from one OS to the other, as indicated in the ArchWiki.
Anyway, again, it randomly froze while I was replying to you, and this kind of freeze is happening way too often lately. At least 3 or 4 times since I started this thread. Before that it happened sometimes 3 or 4 times but since I've been using Arch (almost 2 years). I don't know. This is the
# journalctl -b -1
Yes, maybe also mention in the OP that this is nouveau specific and blacklisting it addresses the problem for now.
Thanks. Do you mean by editing my initial post on the topic, right?
Offline
after this operation the 'dual pairing' bluetooth of the mouse no longer works, which I had managed to make work on both OS without having to re-pair every time
https://wiki.archlinux.org/title/Blueto … ot_pairing
If this has otherwise worked before and no longer does you have somehow relied on the stale connection from the hibernating windows…
Anyway, again, it randomly froze while I was replying to you, and this kind of freeze is happening way too often lately.
giu 23 12:21:22 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
giu 23 12:21:22 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
giu 23 12:21:22 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
giu 23 12:21:22 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
giu 23 12:21:23 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
giu 23 12:21:33 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* [CRTC:79:crtc-0] flip_done timed out
giu 23 12:21:43 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* flip_done timed out
giu 23 12:21:43 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* [CRTC:79:crtc-0] commit wait timed out
giu 23 12:21:53 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* flip_done timed out
giu 23 12:21:53 archpeter kernel: amdgpu 0000:07:00.0: [drm] *ERROR* [PLANE:58:plane-3] commit wait timed out
There're numerous threads about various iterations of the 20250613 amdgpu firmware breaking things causing quite a fuss in https://gitlab.archlinux.org/archlinux/ … mmits/main
"summer", to many interns running amd unchecked during the vacations
You could try to go back to the latest 20250508 firmware (what also means to undo the recent linux-firmware split)
Do you mean by editing my initial post on the topic, right?
Yes.
Offline
I apologize, in turn, for the delay in responding.
If this has otherwise worked before and no longer does you have somehow relied on the stale connection from the hibernating windows…
It was probably just a temporary problem. From the next start the bluetooth pairing worked on both systems.
There're numerous threads about various iterations of the 20250613 amdgpu firmware breaking things causing quite a fuss in https://gitlab.archlinux.org/archlinux/ … mmits/main
"summer", to many interns running amd unchecked during the vacations tongue
Ok, thanks. I think I'll be patient on this one too.
Thank you so much for the support!
I'm going to mark the topic as solved following your instructions.
Offline
If the -9 release doesn't fix it for you I'd probably fall back to 20250508 for now and a stable system. Reports over which of the 20250613 patch levels work are all over the place and likely closely tied to the specific hardware.
Offline
Ok. Thank you so much for your help!
Offline