Skip to content
Snippets Groups Projects

[nv50][Linux 6.2] Nouveau unusable with kernel 6.2

    • Closed Issue created by H. ROMANO @rv

    Hi,

    After updating my archlinux computer from linux 6.1.12 to linux 6.2.1 today, nouveau crashes (screen freeze) right after booting with:

    kernel: nouveau 0000:01:00.0: DRM: [DRM/00000002:sor-0002-0342] [ACQUIRE proto:TMDS head:0 hdmi:1 max_ac_packet:6 rekey:56 scdc:0 hda:0] or:0 link:0 (ret:-22)
kernel: nouveau 0000:01:00.0: disp: ERROR 3 [RESERVED_METHOD] 00 [] chid 0 mthd 05c0 data 00000201
kernel: nouveau 0000:01:00.0: disp: ERROR 5 [INVALID_STATE] 05 [] chid 0 mthd 0080 data 00000002
...

    I had to reboot with ssh.

    The complete kernel log is joined here: kernel.log

    With a linux-rt 6.0.5.14 that was already installed on my computer, everything is working well. I still haven't tested with a reinstall of previous kernel, but I guess it will work too.

    It seems something doesn't work nicely between nouveau and latest kernel specifically.

    Thanks for your help.

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • H. ROMANO
      H. ROMANO @rv ·
      Author

      Just reinstalled linux 6.1.12 and everything is working.

    • Karol Herbst
      Karol Herbst @karolherbst ·
      Owner

      what GPU is that with?

    • H. ROMANO
      H. ROMANO @rv ·
      Author

      Sorry, I forgot. Here is lspci:

      NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Same problem today with 6.2.2:

        kernel: nouveau 0000:01:00.0: vgaarb: deactivate vga console
kernel: nouveau 0000:01:00.0: NVIDIA G98 (298200a2)
kernel: nouveau 0000:01:00.0: bios: version 62.98.3c.00.58
kernel: nouveau 0000:01:00.0: bios: M0203T not found
kernel: nouveau 0000:01:00.0: bios: M0203E not matched!
kernel: nouveau 0000:01:00.0: fb: 512 MiB DDR2
kernel: nouveau 0000:01:00.0: DRM: VRAM: 512 MiB
kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
kernel: nouveau 0000:01:00.0: DRM: TMDS table version 2.0
kernel: nouveau 0000:01:00.0: DRM: DCB version 4.0
kernel: nouveau 0000:01:00.0: DRM: DCB outp 00: 02000300 00000028
kernel: nouveau 0000:01:00.0: DRM: DCB outp 01: 01000302 00020030
kernel: nouveau 0000:01:00.0: DRM: DCB outp 02: 02021332 00020010
kernel: nouveau 0000:01:00.0: DRM: DCB outp 03: 04012310 00000028
kernel: nouveau 0000:01:00.0: DRM: DCB conn 00: 00001030
kernel: nouveau 0000:01:00.0: DRM: DCB conn 01: 00002161
kernel: nouveau 0000:01:00.0: DRM: DCB conn 02: 00000200
kernel: nouveau 0000:01:00.0: DRM: MM: using M2MF for buffer copies
kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
kernel: fbcon: nouveaudrmfb (fb0) is primary device
kernel: nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
kernel: nouveau 0000:01:00.0: DRM: [DRM/00000002:sor-0002-0342] [ACQUIRE proto:TMDS head:0 hdmi:1 max_ac_packet:6 rekey:56 scdc:0 hda:0] or:0 link:0 (ret:-22)
kernel: nouveau 0000:01:00.0: disp: ERROR 3 [RESERVED_METHOD] 00 [] chid 0 mthd 05c0 data 00000201
kernel: nouveau 0000:01:00.0: disp: ERROR 5 [INVALID_STATE] 05 [] chid 0 mthd 0080 data 00000002
kernel: nouveau 0000:01:00.0: disp: Core:
kernel: nouveau 0000:01:00.0: disp:         0084: 03000400 -> 80000000
kernel: nouveau 0000:01:00.0: disp:         0088: 00000000 -> f0000000
kernel: nouveau 0000:01:00.0: disp: Core - DAC 0:
kernel: nouveau 0000:01:00.0: disp:         0400: 00000000              
kernel: nouveau 0000:01:00.0: disp:         0404: 00000000              
kernel: nouveau 0000:01:00.0: disp:         0420: 00010000              
…
      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        mhh I can't trigger this issue myself as it seems.

        You are using HDMI, right?

        Worse case if it's super reliable, I think you might have to do a git bisect if @skeggsb or @lyudess also have no ideas on what's up here.

        Edited by Karol Herbst
      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Yes, I'm using HDMI and it's super reliable (I just have to boot to a 6.2 kernel).

        Did you really meant "I can" or "I can't" in your reply?

        I'll try to bisect, but it's a computer I built around 2007, so kernel compilation takes few hours each time.

        Thanks

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        I meant I can't. I also only have one GPU from that arch with HDMI, so it might just be bad luck on my or your side.

      • Hugo Devillers
        Hugo Devillers @Gobrosse ·

        Able to repro this on 6.3.5 (also arch) with a 9600GT.

        Using analogue DVI works fine, hot-plugging HDMI doesn't do anything, leaving HDMI plugged in and rebooting yields nothing but garbled analogue output (but I can use a terminal just fine) and generates the same error in dmesg

        Edited by Hugo Devillers
      • Please register or sign in to reply
      • H. ROMANO
        H. ROMANO @rv ·
        Author

        This is the bisect result:

        f530bc60 drm/nouveau/disp: move HDMI config into acquire + infoframe methods

        It's a quite big commit with 21 files changed, 503 insertions, 378 deletions.

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        okay.. I think I'm seeing a relevant change which might mess this up.. let's see...

        Could you add back those lines:

        -		nvkm_mask(device, 0x61653c + hoff, 0x00000001, 0x00000000);
-		nvkm_mask(device, 0x616520 + hoff, 0x00000001, 0x00000000);

        inside g84_sor_hdmi_ctrl in drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c? It's this change: f530bc60

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        I patched a 6.2.7 kernel but it didn't solve the problem. I still have the same screen freeze with:

        kernel: nouveau 0000:01:00.0: DRM: [DRM/00000002:sor-0002-0342] [ACQUIRE proto:TMDS head:0 hdmi:1 max_ac_packet:6 rekey:56 scdc:0 hda:0] or:0 link:0 (ret:-22)
kernel: nouveau 0000:01:00.0: disp: ERROR 3 [RESERVED_METHOD] 00 [] chid 0 mthd 05c0 data 00000201
kernel: nouveau 0000:01:00.0: disp: ERROR 5 [INVALID_STATE] 05 [] chid 0 mthd 0080 data 00000002

        Is there some sub-commit history somewhere in a branch so I could test the changes step by step?

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        It doesn't solve the issue but there seems to be a copy-paste error inside g84_sor_hdmi_infoframe_vsi in drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c :

        	nvkm_mask(device, 0x61653c + hoff, 0x00010001, 0x00010000);
	if (!size)
		return;

        but it should be :

        	nvkm_mask(device, 0x61653c + hoff, 0x00000001, 0x00000000);
	if (!size)
		return;
      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Sorry for the noise. I misread the lines in the commit…

      • Please register or sign in to reply
    • wojnilowicz
      wojnilowicz @wojnilowicz ·

      Same with me. My lspci is 01:00.0 VGA compatible controller: NVIDIA Corporation G96CM [GeForce 9600M GT] (rev a1)

      I'm not sure if HDMI worked on my machine, but on 6.2.2-300.fc37.x86_64 connecting a HDMI cable slows down considerably the system or hangs it, and on 6.0.7-301.fc37.x86_64 it at least shows something (not usable though).

      I use Fedora 37 and have xorg-x11-drv-nouveau-1.0.17 installed. In both cases xrandr shows: DVI-D-1 (I don't have any DVI port on my laptop) as an output while nvidia-340xx shows HDMI-0

    • Karol Herbst added bisected regression labels

      added bisected regression labels

    • Karol Herbst added display label

      added display label

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        I don't know if it can help, but when I set grub to some low text mode resolution, the display stays in that mode during all boot process and never switches to a better graphical resolution.

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        huh... that's interesting as this suggest nouveau fails to load. Do you have a kernel log from that? I'm still trying to get my hands on a G9x GPU with HDMI, so sorry if it takes a while to resolve this as no nouveau developer seems to have access to such a GPU sadly

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Here it is with kernel 6.3.7:

        kernel-clean.log

        And what I get on the screen:

        20230612_132236

        I can do some testing myself if you don't have access to such old GPU. Just point me to the right direction.

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        yeah.. I'm mostly wondering why my suggestion doesn't work, but maybe you also did something different than I wanted you to, so maybe I just post a patch here:

        diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c
index 23ae451ba473..f0df119a2d96 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c
@@ -87,6 +87,8 @@ g84_sor_hdmi_ctrl(struct nvkm_ior *ior, int head, bool enable, u8 max_ac_packet,
 
 	if (!(ctrl & 0x40000000)) {
 		nvkm_mask(device, 0x6165a4 + hoff, 0x40000000, 0x00000000);
+		nvkm_mask(device, 0x61653c + hoff, 0x00000001, 0x00000000);
+		nvkm_mask(device, 0x616520 + hoff, 0x00000001, 0x00000000);
 		nvkm_mask(device, 0x616500 + hoff, 0x00000001, 0x00000000);
 		return;
 	}
      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Thank you for the patch.

        I tried it (and verified it was actually applied), but with the same result. The kernel log seems also exactly the same:

        kernel-20230613-clean.log

        The only difference I can notice is a less garbled screen:

        20230613_115903

        So the patch may be a part of the solution, but something else is still missing. Is some order of operations/initialization changed by commit f530bc60?

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        mhhh... yeah, the order could have changed, but it could also be something else regressed it on top. Do you know if the patch works on top of f530bc60? If so, there might be another change you could try to bisect, which would be a bit more painful as you have to carry that patch around.

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        I meant did f530bc60 changed some order of init? Anyway, I'll try your suggestion (apply the patch directly on top of f530bc60).

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        Yeah.. I think it changed some ordering around, but I don't expect it to cause anything... but if the fix on top of f530bc60 doesn't fix it, I suspect I'll have to look a bit deeper to figure out what's wrong there.

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        No luck. It is the same when the patch is applied directly on top of f530bc60…

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        okay, then something else is still wrong, let me think about it a bit more

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        didn't check if it compiles or runs, but maybe something like this on top of f530bc60:

        diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index edf899670287..5a0aaa331c14 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -769,25 +769,6 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct nouveau_crtc *nv_crtc,
 	max_ac_packet /= 32;
 
 	if (hdmi->scdc.scrambling.supported) {
 		const bool high_tmds_clock_ratio = mode->clock > 340000;
 
-		ret = drm_scdc_readb(nv_encoder->i2c, SCDC_TMDS_CONFIG, &config);
-		if (ret < 0) {
-			NV_ERROR(drm, "Failure to read SCDC_TMDS_CONFIG: %d\n", ret);
-			return;
-		}
-
-		config &= ~(SCDC_TMDS_BIT_CLOCK_RATIO_BY_40 | SCDC_SCRAMBLING_ENABLE);
-		if (high_tmds_clock_ratio || hdmi->scdc.scrambling.low_rates)
-			config |= SCDC_SCRAMBLING_ENABLE;
-		if (high_tmds_clock_ratio)
-			config |= SCDC_TMDS_BIT_CLOCK_RATIO_BY_40;
-
-		ret = drm_scdc_writeb(nv_encoder->i2c, SCDC_TMDS_CONFIG, config);
-		if (ret < 0)
-			NV_ERROR(drm, "Failure to write SCDC_TMDS_CONFIG = 0x%02x: %d\n",
-				 config, ret);
-
 		if (high_tmds_clock_ratio || hdmi->scdc.scrambling.low_rates)
 			scdc |= NVIF_OUTP_ACQUIRE_V0_TMDS_HDMI_SCDC_SCRAMBLE;
 		if (high_tmds_clock_ratio)
@@ -824,6 +805,27 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct nouveau_crtc *nv_crtc,
 	nvif_outp_infoframe(&nv_encoder->outp, NVIF_OUTP_INFOFRAME_V0_VSI, &args.infoframe, size);
 
 	nv50_audio_enable(encoder, nv_crtc, nv_connector, state, mode);
+
+	if (hdmi->scdc.scrambling.supported) {
+		const bool high_tmds_clock_ratio = mode->clock > 340000;
+
+		ret = drm_scdc_readb(nv_encoder->i2c, SCDC_TMDS_CONFIG, &config);
+		if (ret < 0) {
+			NV_ERROR(drm, "Failure to read SCDC_TMDS_CONFIG: %d\n", ret);
+			return;
+		}
+
+		config &= ~(SCDC_TMDS_BIT_CLOCK_RATIO_BY_40 | SCDC_SCRAMBLING_ENABLE);
+		if (high_tmds_clock_ratio || hdmi->scdc.scrambling.low_rates)
+			config |= SCDC_SCRAMBLING_ENABLE;
+		if (high_tmds_clock_ratio)
+			config |= SCDC_TMDS_BIT_CLOCK_RATIO_BY_40;
+
+		ret = drm_scdc_writeb(nv_encoder->i2c, SCDC_TMDS_CONFIG, config);
+		if (ret < 0)
+			NV_ERROR(drm, "Failure to write SCDC_TMDS_CONFIG = 0x%02x: %d\n",
+				 config, ret);
+	}
 }
 
 /******************************************************************************
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c
index 23ae451ba473..054bcc1fd31c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.c
@@ -87,6 +87,8 @@ g84_sor_hdmi_ctrl(struct nvkm_ior *ior, int head, bool enable, u8 max_ac_packet,
 
 	if (!(ctrl & 0x40000000)) {
 		nvkm_mask(device, 0x6165a4 + hoff, 0x40000000, 0x00000000);
+		nvkm_mask(device, 0x61653c + hoff, 0x00000001, 0x00000000);
+		nvkm_mask(device, 0x616520 + hoff, 0x00000001, 0x00000000);
 		nvkm_mask(device, 0x616500 + hoff, 0x00000001, 0x00000000);
 		return;
 	}
        Edited by Karol Herbst
      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Thanks for the patch. Didn't you changed the second line of the patch afterwards?

        const bool high_tmds_clock_ratio = mode->clock > 340000;

        was yesterday:

        - const bool high_tmds_clock_ratio = mode->clock > 340000;

        Anyway, I had already added it because it raised a build error if missing.

        Concerning the bug, it sadly still doesn't change anything. Same kernel log and same result on the screen…

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        mhhh.. something is funky... maybe there is something else I overlooked, but I think that's already quite close to the original

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        mind compiling the kernel with NOUVEAU_DEBUG_PUSH=y? and upload dmesg running on f530bc60 and 9793083f?

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Here are the dmesg for each kernel, but I can't see a difference in the log with or without that switch.

        kernel-9793083f.logkernel-f530bc60.log

        Do I need to change something else? These are the nouveau switches used in my kernel config.

        CONFIG_DRM_NOUVEAU=m
# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
# CONFIG_NOUVEAU_DEBUG_MMU is not set
CONFIG_NOUVEAU_DEBUG_PUSH=y
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_NOUVEAU_SVM=y
      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        ohh yeah.. need to run your kernel with nouveau.debug=disp=trace

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        These are the logs :

        9793083f.log f530bc60.log

        The first difference is there :

        9793083f

        [    3.176856] fbcon: nouveaudrmfb (fb0) is primary device
[    3.176968] nouveau 0000:01:00.0: disp: outp 02:0002:0342: acquire 00 |= 02 0000000000000000
[    3.177320] nouveau 0000:01:00.0: disp: supervisor 00000010 000002a0
[    3.177325] nouveau 0000:01:00.0: disp: Core:
[    3.177329] nouveau 0000:01:00.0: disp: 	0084: 019e02e2 -> 80000000
[    3.177333] nouveau 0000:01:00.0: disp: 	0088: 00000000 -> f0000000
…

        f530bc60

        [    3.217170] fbcon: nouveaudrmfb (fb0) is primary device
[    3.217267] nouveau 0000:01:00.0: disp: outp 02:0002:0342: acquire 00 |= 02 0000000000000000
[    3.217271] nouveau 0000:01:00.0: disp: outp 02:0002:0342: release 02 &= fffffffd (____ptrval____)
[    3.217274] nouveau 0000:01:00.0: DRM: [DRM/00000002:sor-0002-0342] [ACQUIRE proto:TMDS head:0 hdmi:1 max_ac_packet:6 rekey:56 scdc:0 hda:0] or:0 link:0 (ret:-22)
[    3.217312] nouveau 0000:01:00.0: disp: ERROR 3 [RESERVED_METHOD] 00 [] chid 0 mthd 05c0 data 00000201
[    3.217341] nouveau 0000:01:00.0: disp: ERROR 5 [INVALID_STATE] 05 [] chid 0 mthd 0080 data 00000002
…

        The problem seems to be the release just after acquire.

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        thanks! yes, that's helpful, let's see what's actually going wrong here.

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        on top of 9793083f:

        diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 5a0aaa331c14..dbe115a9d93b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1622,11 +1622,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state *sta
 
 	switch (nv_encoder->dcb->type) {
 	case DCB_OUTPUT_TMDS:
-		if (disp->disp->object.oclass == NV50_DISP ||
-		    !drm_detect_hdmi_monitor(nv_connector->edid))
-			nvif_outp_acquire_tmds(outp, nv_crtc->index, false, 0, 0, 0, false);
-		else
-			nv50_hdmi_enable(encoder, nv_crtc, nv_connector, state, mode, hda);
+		nv50_hdmi_enable(encoder, nv_crtc, nv_connector, state, mode, hda);
 
 		if (nv_encoder->outp.or.link & 1) {
 			proto = NV507D_SOR_SET_CONTROL_PROTOCOL_SINGLE_TMDS_A;

        this potentially breaks in weird ways, but might checking if this gives you your main display back?

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Shouldn't it be on f530bc60?

        9793083f is a working kernel. Anyway, the patch can be applied on f530bc60 with an offset of -2 lines and a warning of unused variable outp.

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        ahh yeah, that's what I meant

      • H. ROMANO
        H. ROMANO @rv ·
        Author

        Sadly I get the same problem and the same kernel log…

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        uhh.. maybe I don't understand the code enough.. let's ask @skeggsb or @lyudess

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        @rv I just noticed that testing fixes on top of f530bc60 won't work, because it requires future changes to get pulled in :upside_down: Mind trying the patch out on linux/master ?

      • Karol Herbst
        Karol Herbst @karolherbst ·
        Owner

        okay.. got it working, just have to figure out some details.

      • Please register or sign in to reply
    • Karol Herbst assigned to @karolherbst

      assigned to @karolherbst

    • Paul Dufresne
      Paul Dufresne @dufresnep ·

      I see many red flags from kernel.log file:

      mars 02 22:01:10 archlinux kernel: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20221020/dspkginit-438) many similar lines, seems a BIOS warning, not a real bug.

      mars 02 22:01:10 archlinux kernel: pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)

      mars 02 22:01:10 archlinux kernel: pnp 00:01: disabling [mem 0x00000000-0x00000fff window] because it overlaps 0000:03:00.0 BAR 6 [mem 0x00000000-0x0001ffff pref]

      mars 02 22:01:10 archlinux kernel: pnp 00:05: disabling [mem 0x000d8400-0x000dbfff] because it overlaps 0000:01:00.0 BAR 6 [mem 0x000c0000-0x000dffff]

      ars 02 22:01:10 archlinux kernel: system 00:05: [mem 0x000f0000-0x000f7fff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0x000f8000-0x000fbfff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0x000fc000-0x000fffff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0xcfcf0000-0xcfcfffff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0xffff0000-0xffffffff] has been reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0x00000000-0x0009ffff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0x00100000-0xcfceffff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0xcfd00000-0xcfdfffff] has been reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0xcfe00000-0xcfefffff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0xfec00000-0xfec00fff] could not be reserved
mars 02 22:01:10 archlinux kernel: system 00:05: [mem 0xfee00000-0xfee00fff] could not be reserved
      mars 02 22:01:14 maisondubonheur kernel: ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\SOR1) (20221020/utaddress-204)
mars 02 22:01:14 maisondubonheur kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver?
      mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: DRM: [DRM/00000002:sor-0002-0342] [ACQUIRE proto:TMDS head:0 hdmi:1 max_ac_packet:6 rekey:56 scdc:0 hda:0] or:0 link:0 (ret:-22)
mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: disp: ERROR 3 [RESERVED_METHOD] 00 [] chid 0 mthd 05c0 data 00000201
mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: disp: ERROR 5 [INVALID_STATE] 05 [] chid 0 mthd 0080 data 00000002
mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: disp: Core:
mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: disp:         0084: 03000400 -> 80000000
mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: disp:         0088: 00000000 -> f0000000

      The key to me seems this (previously written): mars 02 22:01:23 maisondubonheur kernel: nouveau 0000:01:00.0: DRM: [DRM/00000002:sor-0002-0342] [ACQUIRE proto:TMDS head:0 hdmi:1 max_ac_packet:6 rekey:56 scdc:0 hda:0] or:0 link:0 (ret:-22)

      Edited by Paul Dufresne
    • Paul Dufresne
      Paul Dufresne @dufresnep ·

      Some of these messages seems typical for Gigabyte motherboards: https://forum.manjaro.org/t/black-screen-after-suspend-and-update/133614 or https://gist.github.com/falsifian/3940435

    • Paul Dufresne
      Paul Dufresne @dufresnep ·

      'Same' bug seen on https://discussion.fedoraproject.org/t/fedora-wont-boot-since-kernel-6-2/81034/38

    • Karol Herbst
      Karol Herbst @karolherbst ·
      Owner

      mhh yeah, Lyude already has some ideas on what's up here, but I couldn't reproduce this with any of my HDMI cards, so we kinda have to wait until somebody actually figures out what's wrong here.

    • Paul Dufresne
      Paul Dufresne @dufresnep ·

      Just mentioning the link with the error containing: sor term in DRM/00000002:sor-0002-0342 and previous error ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\SOR1)

      Might be worth checking for a BIOS update.

      Edited by Paul Dufresne
    • Karol Herbst
      Karol Herbst @karolherbst ·
      Owner

      Sorry, but this has nothing to do with the system firmware. It's a regression inside nouveau and we already figured out what's causing this.

    • Karol Herbst
      Karol Herbst @karolherbst ·
      Owner

      Update: seems like I am able to reproduce this issue on my GT218, I just had to use a different display...

    • Karol Herbst added widespread label

      added widespread label

    • Karol Herbst
      Karol Herbst @karolherbst ·
      Owner

      uhhh.. this only happens with a HDMI 2.0 display on GPUs not supporting HDMI 2.0 :')

      Everybody mind confirming that you run into this with a HDMI 2.0 capable display?

      Edited by Karol Herbst
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply