RX 7800 XT fails to initialize after rebooting from linux 6.7

LemmyCook · 2024-01-07 17:23:00

6.7-rc1 with 5f38ac54e60562323ea4abb1bfb37d043ee23357 reverted is good.

loqs · 2024-01-07 17:31:52

Please post the contents of of the two code blocks from https://bbs.archlinux.org/viewtopic.php … 7#p2141827 and that reverting 5f38ac54e60562323ea4abb1bfb37d043ee23357 also no longer produces the issue to https://gitlab.freedesktop.org/drm/amd/-/issues/3062

debellator · 2024-01-10 13:51:12

Just switched from 6.6.10.arch1-1 to 6.7.0-arch1-1 by activating the testing repository and have the exact same issue on a reboot as the initiator of this topic. My GPU is a Sapphire Radeon RX 7700 XT Pulse.

jiggol · 2024-01-13 07:15:01

I am using the 6.6.10-arch1-1 and 6.6.11-1-lts kernels, and I am experiencing the same issue on both of these kernels. The GPU in use is the XFX 7800XT.

OpusOne · 2024-01-15 02:29:40

So it hasn't been solved in the 6.7.0 release or has it? I have a 6650XT, don't know if it's affected or not. But I certainly won't like this issue, so asking before I upgrade the kernel.

jiggol · 2024-01-15 02:32:20

OpusOne wrote:

So it hasn't been solved in the 6.7.0 release or has it? I have a 6650XT, don't know if it's affected or not. But I certainly won't like this issue, so asking before I upgrade the kernel.

I am using the 7800XT, and today I updated the kernel to version 6.7. However, the same issue is still occurring.

Reslore · 2024-01-15 03:04:44

This is not a kernel issue, it's a SDDM issue, at least for me on my 7800 XT. There was a similar issue when the 6xxx series cards came out. To work around it until it gets fixed try first logging out of your desktop session, and then shut down from that screen. No issues for me booting up from that, if just trying to reboot directly from the desktop (KDE), that's when you can get hangups.

spiffeeroo · 2024-01-15 04:31:58

Reslore wrote:

This is not a kernel issue, it's a SDDM issue, at least for me on my 7800 XT. There was a similar issue when the 6xxx series cards came out. To work around it until it gets fixed try first logging out of your desktop session, and then shut down from that screen. No issues for me booting up from that, if just trying to reboot directly from the desktop (KDE), that's when you can get hangups.

This issue is not because of SDDM. I do not have SDDM installed on another Arch Linux partition. No display manager installed (for Hyprland). I cannot get a TTY to show up; the monitor just turns off. I can only boot into kernel 6.7 from a cold boot after powering off. Booting a Linux 6.7 kernel and then rebooting into an older kernel (6.6) or another distro like Fedora/Debian afterward will have problems as well.

I have the same error amdgpu kernel error message as stated in the original post of this thread with kernel 6.7.

Last edited by spiffeeroo (2024-01-15 04:33:43)

OpusOne · 2024-01-15 05:08:56

Ok thanks, that sounds pretty bad. Do you think it can affect the 6650 XT?

Algernop · 2024-01-17 20:06:47

OpusOne wrote:

Ok thanks, that sounds pretty bad. Do you think it can affect the 6650 XT?

I've installed 6.7.0 and the issue doesn't seem to affect my 6650 XT.

OpusOne · 2024-01-17 22:45:47

Algernop wrote:

OpusOne wrote:
Ok thanks, that sounds pretty bad. Do you think it can affect the 6650 XT?
I've installed 6.7.0 and the issue doesn't seem to affect my 6650 XT.

Thanks.

Jeager · 2024-01-17 23:48:43

I think it can happen too because sometime I'm able to boot (mostly from a coldboot)
I guess you need to recompile the kernel in order to fix this right ? (its too advanced for me)

balnav · 2024-01-19 12:47:36

The same thing happens to me, I had arch installed but I wanted to reinstall it and I can't start the system unless I put "nomodeset" in grub, and if I do it it doesn't detect the 2 screens.

My graphics card is the SAPPHIRE Pulse Radeon RX 7800 XT

how can I solve that?

flippette · 2024-01-19 14:19:37

For anyone coming across this thread, here's a 6.7 release kernel I built with 5f38ac54e60562323ea4abb1bfb37d043ee23357 reverted:

https://drive.google.com/drive/folders/ … sp=sharing

And here's the patch file if you don't trust me:

From d37e8871709976e3827d8c9a68d8093b9e470681 Mon Sep 17 00:00:00 2001
From: flippette <quangdatle2006@outlook.com>
Date: Mon, 8 Jan 2024 06:29:01 +0700
Subject: [PATCH] Revert "drm/amd/pm: fix the high voltage and temperature
 issue"

This reverts commit 5f38ac54e60562323ea4abb1bfb37d043ee23357.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c    | 24 ++++----------
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c     | 33 ++-----------------
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  1 -
 drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h  |  2 --
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c    | 13 --------
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  | 18 ++--------
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  | 18 ++--------
 7 files changed, 15 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 93cf73d6fa11..960966f4bd20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4050,23 +4050,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 				}
 			}
 		} else {
-			switch (amdgpu_ip_version(adev, MP1_HWIP, 0)) {
-			case IP_VERSION(13, 0, 0):
-			case IP_VERSION(13, 0, 7):
-			case IP_VERSION(13, 0, 10):
-				r = psp_gpu_reset(adev);
-				break;
-			default:
-				tmp = amdgpu_reset_method;
-				/* It should do a default reset when loading or reloading the driver,
-				 * regardless of the module parameter reset_method.
-				 */
-				amdgpu_reset_method = AMD_RESET_METHOD_NONE;
-				r = amdgpu_asic_reset(adev);
-				amdgpu_reset_method = tmp;
-				break;
-			}
-
+			tmp = amdgpu_reset_method;
+			/* It should do a default reset when loading or reloading the driver,
+			 * regardless of the module parameter reset_method.
+			 */
+			amdgpu_reset_method = AMD_RESET_METHOD_NONE;
+			r = amdgpu_asic_reset(adev);
+			amdgpu_reset_method = tmp;
 			if (r) {
 				dev_err(adev->dev, "asic reset on init failed\n");
 				goto failed;
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index e1a5ee911dbb..308ebeb43563 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -733,7 +733,7 @@ static int smu_early_init(void *handle)
 	smu->adev = adev;
 	smu->pm_enabled = !!amdgpu_dpm;
 	smu->is_apu = false;
-	smu->smu_baco.state = SMU_BACO_STATE_NONE;
+	smu->smu_baco.state = SMU_BACO_STATE_EXIT;
 	smu->smu_baco.platform_support = false;
 	smu->user_dpm_profile.fan_mode = -1;
 
@@ -1753,31 +1753,10 @@ static int smu_smc_hw_cleanup(struct smu_context *smu)
 	return 0;
 }
 
-static int smu_reset_mp1_state(struct smu_context *smu)
-{
-	struct amdgpu_device *adev = smu->adev;
-	int ret = 0;
-
-	if ((!adev->in_runpm) && (!adev->in_suspend) &&
-		(!amdgpu_in_reset(adev)))
-		switch (amdgpu_ip_version(adev, MP1_HWIP, 0)) {
-		case IP_VERSION(13, 0, 0):
-		case IP_VERSION(13, 0, 7):
-		case IP_VERSION(13, 0, 10):
-			ret = smu_set_mp1_state(smu, PP_MP1_STATE_UNLOAD);
-			break;
-		default:
-			break;
-		}
-
-	return ret;
-}
-
 static int smu_hw_fini(void *handle)
 {
 	struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 	struct smu_context *smu = adev->powerplay.pp_handle;
-	int ret;
 
 	if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
 		return 0;
@@ -1795,15 +1774,7 @@ static int smu_hw_fini(void *handle)
 
 	adev->pm.dpm_enabled = false;
 
-	ret = smu_smc_hw_cleanup(smu);
-	if (ret)
-		return ret;
-
-	ret = smu_reset_mp1_state(smu);
-	if (ret)
-		return ret;
-
-	return 0;
+	return smu_smc_hw_cleanup(smu);
 }
 
 static void smu_late_fini(void *handle)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index f8b2e6cc2568..e8329d157bfe 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -419,7 +419,6 @@ enum smu_reset_mode {
 enum smu_baco_state {
 	SMU_BACO_STATE_ENTER = 0,
 	SMU_BACO_STATE_EXIT,
-	SMU_BACO_STATE_NONE,
 };
 
 struct smu_baco_context {
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
index 95cb919718ae..cc02f979e9e9 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -299,7 +299,5 @@ int smu_v13_0_update_pcie_parameters(struct smu_context *smu,
 				     uint8_t pcie_gen_cap,
 				     uint8_t pcie_width_cap);
 
-int smu_v13_0_disable_pmfw_state(struct smu_context *smu);
-
 #endif
 #endif
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index cf1b84060bc3..a49e5adf7cc3 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -2477,16 +2477,3 @@ int smu_v13_0_update_pcie_parameters(struct smu_context *smu,
 
 	return 0;
 }
-
-int smu_v13_0_disable_pmfw_state(struct smu_context *smu)
-{
-	int ret;
-	struct amdgpu_device *adev = smu->adev;
-
-	WREG32_PCIE(MP1_Public | (smnMP1_FIRMWARE_FLAGS & 0xffffffff), 0);
-
-	ret = RREG32_PCIE(MP1_Public |
-					   (smnMP1_FIRMWARE_FLAGS & 0xffffffff));
-
-	return ret == 0 ? 0 : -EINVAL;
-}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index 82c4e1f1c6f0..2ba77b1d1283 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -2574,20 +2574,14 @@ static int smu_v13_0_0_baco_enter(struct smu_context *smu)
 static int smu_v13_0_0_baco_exit(struct smu_context *smu)
 {
 	struct amdgpu_device *adev = smu->adev;
-	int ret;
 
 	if (adev->in_runpm && smu_cmn_is_audio_func_enabled(adev)) {
 		/* Wait for PMFW handling for the Dstate change */
 		usleep_range(10000, 11000);
-		ret = smu_v13_0_baco_set_armd3_sequence(smu, BACO_SEQ_ULPS);
+		return smu_v13_0_baco_set_armd3_sequence(smu, BACO_SEQ_ULPS);
 	} else {
-		ret = smu_v13_0_baco_exit(smu);
+		return smu_v13_0_baco_exit(smu);
 	}
-
-	if (!ret)
-		adev->gfx.is_poweron = false;
-
-	return ret;
 }
 
 static bool smu_v13_0_0_is_mode1_reset_supported(struct smu_context *smu)
@@ -2772,13 +2766,7 @@ static int smu_v13_0_0_set_mp1_state(struct smu_context *smu,
 
 	switch (mp1_state) {
 	case PP_MP1_STATE_UNLOAD:
-		ret = smu_cmn_send_smc_msg_with_param(smu,
-											  SMU_MSG_PrepareMp1ForUnload,
-											  0x55, NULL);
-
-		if (!ret && smu->smu_baco.state == SMU_BACO_STATE_EXIT)
-			ret = smu_v13_0_disable_pmfw_state(smu);
-
+		ret = smu_cmn_set_mp1_state(smu, mp1_state);
 		break;
 	default:
 		/* Ignore others */
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index 81eafed76045..19c1289d000c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -2499,13 +2499,7 @@ static int smu_v13_0_7_set_mp1_state(struct smu_context *smu,
 
 	switch (mp1_state) {
 	case PP_MP1_STATE_UNLOAD:
-		ret = smu_cmn_send_smc_msg_with_param(smu,
-											  SMU_MSG_PrepareMp1ForUnload,
-											  0x55, NULL);
-
-		if (!ret && smu->smu_baco.state == SMU_BACO_STATE_EXIT)
-			ret = smu_v13_0_disable_pmfw_state(smu);
-
+		ret = smu_cmn_set_mp1_state(smu, mp1_state);
 		break;
 	default:
 		/* Ignore others */
@@ -2531,20 +2525,14 @@ static int smu_v13_0_7_baco_enter(struct smu_context *smu)
 static int smu_v13_0_7_baco_exit(struct smu_context *smu)
 {
 	struct amdgpu_device *adev = smu->adev;
-	int ret;
 
 	if (adev->in_runpm && smu_cmn_is_audio_func_enabled(adev)) {
 		/* Wait for PMFW handling for the Dstate change */
 		usleep_range(10000, 11000);
-		ret = smu_v13_0_baco_set_armd3_sequence(smu, BACO_SEQ_ULPS);
+		return smu_v13_0_baco_set_armd3_sequence(smu, BACO_SEQ_ULPS);
 	} else {
-		ret = smu_v13_0_baco_exit(smu);
+		return smu_v13_0_baco_exit(smu);
 	}
-
-	if (!ret)
-		adev->gfx.is_poweron = false;
-
-	return ret;
 }
 
 static bool smu_v13_0_7_is_mode1_reset_supported(struct smu_context *smu)
-- 
2.43.0

hazelnut · 2024-01-21 13:16:35

Reslore wrote:

This is not a kernel issue, it's a SDDM issue, at least for me on my 7800 XT. There was a similar issue when the 6xxx series cards came out. To work around it until it gets fixed try first logging out of your desktop session, and then shut down from that screen. No issues for me booting up from that, if just trying to reboot directly from the desktop (KDE), that's when you can get hangups.

It's not, followed the exact instructions here and got the same issue. It's the kernel.

loqs · 2024-01-23 12:12:26

@flippette have you considered opening an issue on the Arch gitlab instance asking for 5f38ac54e60562323ea4abb1bfb37d043ee23357 to be reverted. It might save some time while compared to waiting for https://gitlab.freedesktop.org/agd5f/li … a72080e4c8 to make its way to stable.

elmendario · 2024-01-29 09:31:59

Still happens in 6.7.2 kernel, using lts. No news about this bug??

loqs · 2024-01-29 14:48:43

elmendario wrote:

Still happens in 6.7.2 kernel, using lts. No news about this bug??

https://gitlab.freedesktop.org/drm/amd/ … te_2258879

sickie · 2024-02-01 15:42:07

Reading from tkg's patch notes it looks like the patch is reverted in 7.3 so it should be okie now!

EDIT: Thank you flippette and everyone else involved in ironing out this issue!!

EDIT 2: Well that's embarrassing... tkg said it was reverted so they removed their implementation of this patch, but actually it seems that the offending code is still present in upstream source since with 7.3 tkg this problem is present, while it wasn't with tkg 7.1 or 7.2.

Last edited by sickie (2024-02-01 20:03:59)

loqs · 2024-02-02 10:19:45

Upstream the revert has reached https://cgit.freedesktop.org/drm/drm/co … d33ec5e412 so should be merged into Linus's tree for 6.8-rc3 then back-ported to stable.
Edit:
Merged to Linus's tree https://git.kernel.org/pub/scm/linux/ke … 798609d297

Last edited by loqs (2024-02-02 21:45:11)

debellator · 2024-02-08 21:24:15

Testing with linux-6.7.4.arch1-1 showed me that the issue still exists. Does someone know if the patch was included this version?

loqs · 2024-02-08 21:39:51

debellator wrote:

Testing with linux-6.7.4.arch1-1 showed me that the issue still exists. Does someone know if the patch was included this version?

It has not. No one has reported the issue on the Arch gitlab instance asking for the fix to be applied before upstream applies it. I will not as I am not affected by the issue. https://git.kernel.org/pub/scm/linux/ke … 199f78ca08 looks properly labeled to me for upstream stable to pick it up automatically within a few upstream stable releases.
Edit:
https://git.kernel.org/pub/scm/linux/ke … 7bd74a86ec queued for 6.7.5.

Last edited by loqs (2024-02-13 15:48:39)

jiggol · 2024-02-15 06:08:37

After downloading the head from the https://git.kernel.org/pub/scm/linux/ke … mware.git/ site, and copying the amdgpu firmware files, I haven't experienced any reboot issues since kernel 6.7.4.

Last edited by jiggol (2024-02-15 06:08:50)

elmendario · 2024-02-17 20:25:50

Can confirm that with kernel 6.7.5 the issue is resolved.

cryptearth · 2024-02-17 22:41:42

I was affected by this, too.
As I have a Sapphire RX 7700 XT PULSE with 2x HDMI and 2x DP I use a DP-splitter (active, usb powered) to hook up 3 monitors with passive DP-to-DVI cables.
As mentioned in my additional info topic https://bbs.archlinux.org/viewtopic.php?id=292594 I tested without the splitter and with HDMI only. I was also able to reproduce this issue with a RX 570 and a R9 290X when explicitly using the amdgpu driver (the 290 defaults to the older radeon driver). For me it only happened when I had the DP-splitter hooked up. When using only direct connections it worked without issues. Also not using DP had not caused the issue. At least to me and for my tests it seems that
a) this affects (now affected) any card using the amdgpu driver - not just the recent 6000 and 7000 cards
b) the original change that caused this issue and now got revereted at least for me seem to somewhat have in play in DP
Additional: When the issue was triggered and the system rebooted warm into windows it always recovered no matter the wiring.

Nice to see that this issue got resolved so fast - although it's now up to someone to figure out what happened and what was the original change about and if it's still required and hence has to be redone without causing that issue again.

My system spec below:

[main@main ~]$ LANG=C pacman -Qi linux
Name            : linux
Version         : 6.7.5.arch1-1
Description     : The Linux kernel and modules
Architecture    : x86_64
URL             : https://github.com/archlinux/linux
Licenses        : GPL2
Groups          : None
Provides        : KSMBD-MODULE  VIRTUALBOX-GUEST-MODULES  WIREGUARD-MODULE
Depends On      : coreutils  initramfs  kmod
Optional Deps   : wireless-regdb: to set the correct wireless channels of your country
                  linux-firmware: firmware images needed for some devices [installed]
Required By     : zfs-linux  zfs-linux-headers
Optional For    : base
Conflicts With  : None
Replaces        : virtualbox-guest-modules-arch  wireguard-arch
Installed Size  : 130.76 MiB
Packager        : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date      : Sat Feb 17 15:02:33 2024
Install Date    : Sat Feb 17 23:12:27 2024
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

[main@main ~]$ LANG=C pacman -Qi linux-firmware
Name            : linux-firmware
Version         : 20240115.9b6d0b08-2
Description     : Firmware files for Linux
Architecture    : any
URL             : https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary
Licenses        : GPL2  GPL3  custom
Groups          : None
Provides        : None
Depends On      : linux-firmware-whence
Optional Deps   : None
Required By     : None
Optional For    : linux
Conflicts With  : None
Replaces        : None
Installed Size  : 216.96 MiB
Packager        : Tobias Powalowski <tpowa@archlinux.org>
Build Date      : Thu Feb 1 09:25:33 2024
Install Date    : Thu Feb 1 21:54:36 2024
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

[main@main ~]$ LANG=C uname -a
Linux main 6.7.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 17 Feb 2024 14:02:33 +0000 x86_64 GNU/Linux
[main@main ~]$ LANG=C neofetch
                   -`                    main@main 
                  .o+`                   --------- 
                 `ooo/                   OS: Arch Linux x86_64 
                `+oooo:                  Host: MS-7C56 2.0 
               `+oooooo:                 Kernel: 6.7.5-arch1-1 
               -+oooooo+:                Uptime: 2 mins 
             `/:-:++oooo+:               Packages: 1555 (pacman) 
            `/++++/+++++++:              Shell: bash 5.2.26 
           `/++++++++++++++:             Resolution: 1920x1080, 1920x1080, 1920x1080 
          `/+++ooooooooooooo/`           DE: Plasma 5.27.10 
         ./ooosssso++osssssso+`          WM: KWin 
        .oossssso-````/ossssss+`         Theme: [Plasma], Breeze [GTK2/3] 
       -osssssso.      :ssssssso.        Icons: [Plasma], breeze-dark [GTK2/3] 
      :osssssss/        osssso+++.       Terminal: konsole 
     /ossssssss/        +ssssooo/-       CPU: AMD Ryzen 5 5600 (12) @ 3.500GHz 
   `/ossssso+/:-        -:/+osssso+-     GPU: AMD ATI Radeon RX 7700 XT / 7800 XT 
  `+sso+:-`                 `.-/+oso:    Memory: 9828MiB / 32018MiB 
 `++:.                           `-/+/
 .`                                 `/

This reminds me of a quite similar issue with usb audio interfaces: Someone pushed some maintenance patch which caused an issue for some usb audio interfaces to be only be used as either inputs or outputs but not both the same time any longer. I have a Roland Tri-Capture which was affected and a Behringer xenyx q802usb which was not affected.
The issue was discovered quite fast within only a few days, the affecting commit was figured out within yet another day - and the fix was done so fast it was pushed with the very next update. Overall from first issues to fixed within two weeks or so.
I'm quite impressed to just blown away by how the community is able to figure out AND fix such issues so fast. For me it's a confirmation of it was the right move from switching from Win7 after end of support to Arch. Yes, getting affected from time to time is part of running new hardware and a bleeding-edge dristo - and maybe using a more slower paced distro would prevent this - but as I use my system mainly for gaming and, at least until now, had no issues with Citrix and work from home I can live with such minor inconveniences as to shutdown and cold-start instead of warm reboot.

To anyone worked on this: Get your self a cold beer and celebrated the weekend - cheers!

Arch Linux

#51 2024-01-07 17:23:00

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#52 2024-01-07 17:31:52

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#53 2024-01-10 13:51:12

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#54 2024-01-13 07:15:01

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#55 2024-01-15 02:29:40

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#56 2024-01-15 02:32:20

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#57 2024-01-15 03:04:44

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#58 2024-01-15 04:31:58

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#59 2024-01-15 05:08:56

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#60 2024-01-17 20:06:47

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#61 2024-01-17 22:45:47

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#62 2024-01-17 23:48:43

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#63 2024-01-19 12:47:36

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#64 2024-01-19 14:19:37

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#65 2024-01-21 13:16:35

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#66 2024-01-23 12:12:26

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#67 2024-01-29 09:31:59

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#68 2024-01-29 14:48:43

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#69 2024-02-01 15:42:07

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#70 2024-02-02 10:19:45

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#71 2024-02-08 21:24:15

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#72 2024-02-08 21:39:51

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#73 2024-02-15 06:08:37

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#74 2024-02-17 20:25:50

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

#75 2024-02-17 22:41:42

Re: RX 7800 XT fails to initialize after rebooting from linux 6.7

Board footer