[6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3926 bytes --]

I have a Thinkpad P1 Gen6 with combined Intel + NVIDIA graphics:

00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris Xe Graphics] [8086:a7a0] (rev 04)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD107GLM [RTX 2000 Ada Generation Laptop GPU] [10de:28b8] (rev a1)

There's supposed to be USB-C display support but that's never worked
and I have no idea how to even start debugging it.

It does have an HDMI port in the laptop itself, which does sometimes
work. I've grown accustomed to having to reboot the laptop to get it to
output to that port, like it's the 1990s again.

When I updated from 6.13.4 to 6.13.6 even *that* stopped working
because the laptop doesn't even reboot so I have to power cycle it.
This time at least I have some way to start debugging it; there's a
backtrace on screen.

Image to text below; full images at 
 http://david.woodhou.se/PXL_20250326_092807612.MP.jpg
 http://david.woodhou.se/PXL_20250326_092800399.MP.jpg
 http://david.woodhou.se/PXL_20250313_153455231.MP.jpg


[608593.5728743 CPU: 15 UID: 626640614 PID: 17529 Comm: WebKitWebProces Taint
[608593.576062] Tainted: [W]=WARN
C608593.579235] Hardware name: LENOVO 21FVS16V08/21FVS16V80, BIOS N3ZET45W (1.
[608593.582441] RIP: 0010:r535_gsp_msgq_wait+0x1c4/0x1f0 [nouveau]
[608593.585775] Code: 8b 45 cc 31 d2 05 2f 10 00 00 Od ff Of 00 00 48 c1 e8 Bc
[608593.589119] RSP: 0018: ffffb169c23e7818 EFLAGS: 00010246
[608593.592450] RAX: 0000000000000000 RBX: 0000000000000028 RCX: 0000000000000
[608593.595812] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000
[608593.599162] RBP: ffffb169c23e7858 R08: 000-----------00 R09: 000000
[608593.602505] R10: 00000-0000-00-00 R11: 000-----------00 R12: 00000000
[608593.605829] R13: ffff9b2fa3362000 R14: ffffb169c23e7878 R15: 00000000000000
[608593.609167] FS: 0000752bd596fbc0(0000) GS: ffff9b463f580000(0000) kn1GS:000
[608593.612510] CS: 0010 DS: 0000 ES: 0000 CRO: 0000000080050033
[608593.615870] CR2: 00007ea21329a7b4 CR3: 00000002b2782005 CR4: 0000000000f72e1
[608593.619235] PKRU: 55555554
[608593.622604] Call Trace:
[608593.625968] <TASK>
[608593.629323] ? show_regs+0x6c/0x80
[608593.632693] ?__warn+0x8d/0x150
[608593.636055] ? r535_gsp_msgq_wait+0x1c4/0x1f0 [nouveau]
[608593.639533] ? report_bug+0x182/0x1b0
[608593.642908] ? handle_bug+0x6e/0xb0
[608593.646279] ? exc_invalid_op+0x18/0x80
[608593.649640] ?asm_exc_invalid_op+0x1b/0x20
[608593.652991] ? r535_gsp_msgq_wait+0x1c4/0x1f0 [nouveau]
[608593.656476] ? r535_gsp_msgq_wait+0x8a/0x1f0 [nouveau]
[608593.659943] r535_gsp_msg_recv+0x51/0x280 [nouveau]
[608593.663419] r535_gsp_rpc_send+0x1c9/0x2d0 [nouveau]
[688593.666895]
[608593.670362] ? __kvmalloc_node_noprof+0x24/0x100
r535_gsp_rpc_push+0x156/0x160 [nouveau]
[608593.673731] r535_gsp_rpc_rm_free+0x76/0xe0 [nouveau]
[608593.677217] r535_gr_obj_dtor+0x2b/0x40 [nouveau]
[608593.680696] nvkm_object_dtor+0xb9/0x1b0 [nouveau]
[608593.684088]
[608593.687417]
[608593.690741] nvkm_object_del+0x2b/0xc0 [nouveau]
nvkm_oproxy_dtor+0x30/0x60 [nouveau]
nvkm_object_dtor+0xb9/0x1b0 [nouveau]
[608593.694053] nvkm_object_del+0x2b/0xc0 [nouveau]
[608593.697366]
[608593.700661]
[608593.703958] nvkm_object_dtor+0x66/0x1b0 [nouveau]
nvkm_object_del+0x2b/0xc0 [nouveau]
nvkm_ioctl_del+0x38/0xb0 [nouveau]
[608593.707237] nvkm_ioctl+0x103/0x240 [nouveau]
[608593.710514] nvkm_client_ioctl+0xe/0x20 [nouveau]
[do_syscall_64+0x7e/0x170
[608593.751404]
nvif_object_dtor+0x78/0xb0 [nouveau]
nouveau_channel_del+0x8b/0x110 [nouveau]
nouveau_abi16_chan_fini.isra.0+0x143/0x1d0 [nouveau]
nouveau_abi16_fini+0x8d/0xd0 [nouveau]
nouveau_drm_postclose+0xa9/0x140 [nouveau]
drm_file_free+0x1e5/0x270
drm_release+0xb1/0x130
__fput+0xe5/0x2d0
_fput_sync+0x59/0x80
x64_sys_call+0x1a2d/0x2650
__x64_sys_close+0x3d/0x90
?__handle_mm_fault+AxAn
[608593.7542781
3

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Mon, 2025-04-07 at 16:28 +0100, David Woodhouse wrote:
> [608593.5728743 CPU: 15 UID: 626640614 PID: 17529 Comm: WebKitWebProces
> Taint
> [608593.576062] Tainted: [W]=WARN

What does this mean?  

> C608593.579235] Hardware name: LENOVO 21FVS16V08/21FVS16V80, BIOS N3ZET45W
> (1.
> [608593.582441] RIP: 0010:r535_gsp_msgq_wait+0x1c4/0x1f0 [nouveau]

Can you add a bunch of printks to r535_gsp_msgq_wait() to help narrow down
which specific WARN this is?  Or maybe use addr2line?

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Mon, 2025-04-07 at 16:28 +0000, Timur Tabi wrote:
> On Mon, 2025-04-07 at 16:28 +0100, David Woodhouse wrote:
> > [608593.5728743 CPU: 15 UID: 626640614 PID: 17529 Comm: WebKitWebProces
> > Taint
> > [608593.576062] Tainted: [W]=WARN
> 
> What does this mean?  

That the kernel is 'tainted' because it's already emitted a warning?

> > C608593.579235] Hardware name: LENOVO 21FVS16V08/21FVS16V80, BIOS N3ZET45W
> > (1.
> > [608593.582441] RIP: 0010:r535_gsp_msgq_wait+0x1c4/0x1f0 [nouveau]
> 
> Can you add a bunch of printks to r535_gsp_msgq_wait() to help narrow down
> which specific WARN this is?  Or maybe use addr2line?

Not exactly the same build (I'm on 6.14 now) but:

(gdb) list *(r535_gsp_msgq_wait+0x1c4)
0xd24 is in r535_gsp_msgq_wait (drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:117).
112				break;
113	
114			usleep_range(1, 2);
115		} while (--(*ptime));
116	
117		if (WARN_ON(!*ptime))
118			return ERR_PTR(-ETIMEDOUT);
119	
120		mqe = (void *)((u8 *)gsp->shm.msgq.ptr + 0x1000 + rptr * 0x1000);
121	

It doesn't seem to happen with 6.14, but maybe it's only when the HDMI
has stopped working, and that hasn't happened yet with 6.14. I booted
back into 6.13.6 to test that again, and it also managed to reboot if I
did so *before* the HDMI output was unhappy.

Any clues on how to debug the USB-C output, and where to report that? 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Mon, 2025-04-07 at 18:01 +0100, David Woodhouse wrote:

> > 
> 
> Not exactly the same build (I'm on 6.14 now) but:
> 
> (gdb) list *(r535_gsp_msgq_wait+0x1c4)
> 0xd24 is in r535_gsp_msgq_wait
> (drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:117).
> 112				break;
> 113	
> 114			usleep_range(1, 2);
> 115		} while (--(*ptime));
> 116	
> 117		if (WARN_ON(!*ptime))
> 118			return ERR_PTR(-ETIMEDOUT);

This tells me that GSP-RM has crashed, which explains a lot of the behavior
you're seeing.

What I need now are the GSP-RM logs.  In your /etc/modprobe.d, see if there
is a file with "options nouveau".  If there isn't, create one, and then add
the "keep-gsp-logging=1" parameter, so it looks something like this:

	options nouveau keep-gsp-logging=1

Reboot and then tell me if you see anything like this:

# ls -lR /sys/kernel/debug/nouveau/                                        
/sys/kernel/debug/nouveau/:                                                
total 0                                                                    
drwxr-xr-x 2 root root 0 Apr  7 12:06 0000:65:00.0                         
                                                                                                                                                                                                                                                                                                            
'/sys/kernel/debug/nouveau/0000:65:00.0':                                  
total 0                                                                    
-r--r--r-- 1 root root 65536 Apr  7 12:06 loginit                          
-r--r--r-- 1 root root 65536 Apr  7 12:06 logintr                          
-r--r--r-- 1 root root  4096 Apr  7 12:06 logpmu                           
-r--r--r-- 1 root root 65536 Apr  7 12:06 logrm                            

If you do, I need the contents of these files.  So e.g.:

cp /sys/kernel/debug/nouveau/0000:65:00.0/loginit loginit
cp /sys/kernel/debug/nouveau/0000:65:00.0/logrm logrm
cp /sys/kernel/debug/nouveau/0000:65:00.0/logpmu logpmu
cp /sys/kernel/debug/nouveau/0000:65:00.0/logintr logintr

You may only see some of these files, that's okay.

Zip them up and email them to me.


> Any clues on how to debug the USB-C output, and where to report that? 

No, I can't help with that.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Mon, 2025-04-07 at 17:14 +0000, Timur Tabi wrote:
> What I need now are the GSP-RM logs.  In your /etc/modprobe.d, see if
> there
> is a file with "options nouveau".  If there isn't, create one, and then
> add
> the "keep-gsp-logging=1" parameter, so it looks something like this:
> 
> 	options nouveau keep-gsp-logging=1
> 
> Reboot and then tell me if you see anything like this:

Ugh, I just noticed that this feature is probably not in 6.13.  It was added
in 6.14, so unless you're willing to upgrade to 6.14, this might be a dead
end.  Sorry.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Mon, 2025-04-07 at 18:30 +0000, Timur Tabi wrote:
> On Mon, 2025-04-07 at 17:14 +0000, Timur Tabi wrote:
> > What I need now are the GSP-RM logs.  In your /etc/modprobe.d, see if
> > there
> > is a file with "options nouveau".  If there isn't, create one, and then
> > add
> > the "keep-gsp-logging=1" parameter, so it looks something like this:
> > 
> > 	options nouveau keep-gsp-logging=1
> > 
> > Reboot and then tell me if you see anything like this:
> 
> Ugh, I just noticed that this feature is probably not in 6.13.  It was added
> in 6.14, so unless you're willing to upgrade to 6.14, this might be a dead
> end.  Sorry.

I'd already upgraded to 6.14, and have just rebooted into 6.14.1 with
that option enabled. I now have the four files in debugfs of which you
spoke, but I'm assuming you don't actually want them until something
*interesting* happens, like the onboard HDMI failing to connect and/or
the GSP-RM crashing again?

> > Any clues on how to debug the USB-C output, and where to report that?
> 
> No, I can't help with that.

At this point I have no clue even where to start.

I don't know what is responsible for establishing that there's
something connected to that USB-C which is capable of DisplayPort, and
how that's supposed to be visible to the nouveau driver...


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Mon, 2025-04-07 at 19:39 +0100, David Woodhouse wrote:
> I'd already upgraded to 6.14, and have just rebooted into 6.14.1 with
> that option enabled. I now have the four files in debugfs of which you
> spoke, but I'm assuming you don't actually want them until something
> *interesting* happens, like the onboard HDMI failing to connect and/or
> the GSP-RM crashing again?

Yes, but you could send them to me now so that I can make sure that they are
actually working.  

> > > Any clues on how to debug the USB-C output, and where to report that?
> > 
> > No, I can't help with that.
> 
> At this point I have no clue even where to start.
> 
> I don't know what is responsible for establishing that there's
> something connected to that USB-C which is capable of DisplayPort, and
> how that's supposed to be visible to the nouveau driver...

Have you tried the proprietary driver?  With Ada GPUs like yours, Nouveau
just uses GSP-RM to do most of the GPU work.  GSP-RM is just the Nvidia
proprietary driver ported to RISC-V, and Nouveau basically does the same
thing that our open source driver driver does.

If the proprietary driver works just fine, then we know that it's a
bug/limitation in how Nouveau talks to GSP-RM.  One of the Nouveau devs can
help with that.

If the proprietary driver does not work, then that's a bug that can be
reported to Nvidia that Nvidia has to fix.  Once that fixes makes it to GSP-
RM, then in theory Nouveau can be updated to use it.  

Please note that an update for Nouveau that moves it to the r570 driver is
in development, and that might fix your issue.  If you want to beta test
that, let me know, but you'll have to build a new kernel.  However, please
try the proprietary driver first.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

On Mon, 2025-04-07 at 18:47 +0000, Timur Tabi wrote:
> On Mon, 2025-04-07 at 19:39 +0100, David Woodhouse wrote:
> > I'd already upgraded to 6.14, and have just rebooted into 6.14.1 with
> > that option enabled. I now have the four files in debugfs of which you
> > spoke, but I'm assuming you don't actually want them until something
> > *interesting* happens, like the onboard HDMI failing to connect and/or
> > the GSP-RM crashing again?
> 
> Yes, but you could send them to me now so that I can make sure that they are
> actually working. 

Sent; thanks.

> > > > Any clues on how to debug the USB-C output, and where to report that?
> > > 
> > > No, I can't help with that.
> > 
> > At this point I have no clue even where to start.
> > 
> > I don't know what is responsible for establishing that there's
> > something connected to that USB-C which is capable of DisplayPort, and
> > how that's supposed to be visible to the nouveau driver...
> 
> Have you tried the proprietary driver?  With Ada GPUs like yours, Nouveau
> just uses GSP-RM to do most of the GPU work.  GSP-RM is just the Nvidia
> proprietary driver ported to RISC-V, and Nouveau basically does the same
> thing that our open source driver driver does.

I'll test it; thanks.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Mon, 2025-04-07 at 18:47 +0000, Timur Tabi wrote:
> 
> Have you tried the proprietary driver?  With Ada GPUs like yours, Nouveau
> just uses GSP-RM to do most of the GPU work.  GSP-RM is just the Nvidia
> proprietary driver ported to RISC-V, and Nouveau basically does the same
> thing that our open source driver driver does.

Yes. The proprietary driver (570.133.07) did manage to light up the
external monitor over USB-C/DP.

It was utterly unusable, as I couldn't make it do 100% scaling on the
external screen and 200% on the high-DPI laptop screen, and my attempts
to do so (just using the GNOME control panel) ended up with weird
effects and wrong scaling and the mouse pointer not really taking
effect in the place I thought it was pointing... but setting that
aside, yes. The display *did* light up.

> If the proprietary driver works just fine, then we know that it's a
> bug/limitation in how Nouveau talks to GSP-RM.  One of the Nouveau devs can
> help with that.

Is the first step there to try beta testing the r570 update?

> If the proprietary driver does not work, then that's a bug that can be
> reported to Nvidia that Nvidia has to fix.  Once that fixes makes it to GSP-
> RM, then in theory Nouveau can be updated to use it.  
> 
> Please note that an update for Nouveau that moves it to the r570 driver is
> in development, and that might fix your issue.  If you want to beta test
> that, let me know, but you'll have to build a new kernel.  However, please
> try the proprietary driver first.

Thanks!

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Mon, 2025-04-07 at 20:41 +0100, David Woodhouse wrote:
> Yes. The proprietary driver (570.133.07) did manage to light up the
> external monitor over USB-C/DP.
> 
> It was utterly unusable, as I couldn't make it do 100% scaling on the
> external screen and 200% on the high-DPI laptop screen, and my attempts
> to do so (just using the GNOME control panel) ended up with weird
> effects and wrong scaling and the mouse pointer not really taking
> effect in the place I thought it was pointing... but setting that
> aside, yes. The display *did* light up.

I don't know anything about capabilities of our driver w.r.t. scaling, but
what happens if you try to keep everything at 100%?

It's possible what you're trying to do is just not supported by GNOME,
Wayland, Xorg, and/or our driver.  

> > If the proprietary driver works just fine, then we know that it's a
> > bug/limitation in how Nouveau talks to GSP-RM.  One of the Nouveau devs
> > can
> > help with that.
> 
> Is the first step there to try beta testing the r570 update?

So here's the problem.  If the proprietary driver doesn't work, then there's
no hope for Nouveau working.  That's because the GSP-RM firmware that
Nouveau depends on *is* the Nvidia proprietary driver.

I hate to say this, but you're going to have to work with your laptop vendor
and/or Nvidia support to get the proprietary driver working first.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

On 7 April 2025 20:51:50 BST, Timur Tabi <ttabi@nvidia.com> wrote:
>On Mon, 2025-04-07 at 20:41 +0100, David Woodhouse wrote:
>> Yes. The proprietary driver (570.133.07) did manage to light up the
>> external monitor over USB-C/DP.
>> 
>> It was utterly unusable, as I couldn't make it do 100% scaling on the
>> external screen and 200% on the high-DPI laptop screen, and my attempts
>> to do so (just using the GNOME control panel) ended up with weird
>> effects and wrong scaling and the mouse pointer not really taking
>> effect in the place I thought it was pointing... but setting that
>> aside, yes. The display *did* light up.
>
>I don't know anything about capabilities of our driver w.r.t. scaling, but
>what happens if you try to keep everything at 100%?
>
>It's possible what you're trying to do is just not supported by GNOME,
>Wayland, Xorg, and/or our driver.  
>
>> > If the proprietary driver works just fine, then we know that it's a
>> > bug/limitation in how Nouveau talks to GSP-RM.  One of the Nouveau devs
>> > can
>> > help with that.
>> 
>> Is the first step there to try beta testing the r570 update?
>
>So here's the problem.  If the proprietary driver doesn't work, then there's
>no hope for Nouveau working.  That's because the GSP-RM firmware that
>Nouveau depends on *is* the Nvidia proprietary driver.
>
>I hate to say this, but you're going to have to work with your laptop vendor
>and/or Nvidia support to get the proprietary driver working first.

It *was* working, as long as I could tolerate it being scaled to 200% like the internal display. It *did* light up the external display just fine.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Mon, 2025-04-07 at 21:09 +0100, David Woodhouse wrote:
> It *was* working, as long as I could tolerate it being scaled to 200% like
> the internal display. It *did* light up the external display just fine.

Ok, the only thing I can think of is to do a bisect between 6.13.4 and
6.13.6 to determine the commit that broke it.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Tue, 2025-04-08 at 15:59 +0000, Timur Tabi wrote:
> On Mon, 2025-04-07 at 21:09 +0100, David Woodhouse wrote:
> > It *was* working, as long as I could tolerate it being scaled to 200% like
> > the internal display. It *did* light up the external display just fine.
> 
> Ok, the only thing I can think of is to do a bisect between 6.13.4 and
> 6.13.6 to determine the commit that broke it.

I meant, the proprietary driver was working. It messed up when I asked
it to scale the displays, but that's a separate issue. It *did* light
up the external DP display on the USB-C port.

If I set the BIOS to use the external display at boot time, that works
and Linux starts booting using the USB-C monitor — until nouveau inits,
at which point it stops working. Is it useful to provide the logfiles
from debugfs and drm.debug=0x100 logs from such a boot?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Tue, 2025-04-08 at 17:21 +0100, David Woodhouse wrote:
> If I set the BIOS to use the external display at boot time, that works
> and Linux starts booting using the USB-C monitor — until nouveau inits,
> at which point it stops working. Is it useful to provide the logfiles
> from debugfs and drm.debug=0x100 logs from such a boot?

I can take a look at the logs and see if there's any error message.  But if
I don't see anything, then I suspect that it's just a Nouveau limitation.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Tue, 2025-04-08 at 16:30 +0000, Timur Tabi wrote:
> On Tue, 2025-04-08 at 17:21 +0100, David Woodhouse wrote:
> > If I set the BIOS to use the external display at boot time, that works
> > and Linux starts booting using the USB-C monitor — until nouveau inits,
> > at which point it stops working. Is it useful to provide the logfiles
> > from debugfs and drm.debug=0x100 logs from such a boot?
> 
> I can take a look at the logs and see if there's any error message.  But if
> I don't see anything, then I suspect that it's just a Nouveau limitation.

ISTR you said that if the proprietary driver does manage to use that
port, then we could at least look at why nouveau doesn't?

Could it even already be fixed in the r570-based update to nouveau?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[Timur Tabi]

On Tue, 2025-04-08 at 17:42 +0100, David Woodhouse wrote:
> ISTR you said that if the proprietary driver does manage to use that
> port, then we could at least look at why nouveau doesn't?

Yes, but that is beyond my knowledge of Nouveau and GPU drivers.

> Could it even already be fixed in the r570-based update to nouveau?

I doubt it.  Let me look at the logs, and if I don't see anything, I'll give
you instructions on how to beta test r570.

Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Tue, 2025-04-08 at 16:46 +0000, Timur Tabi wrote:
> On Tue, 2025-04-08 at 17:42 +0100, David Woodhouse wrote:
> > ISTR you said that if the proprietary driver does manage to use that
> > port, then we could at least look at why nouveau doesn't?
> 
> Yes, but that is beyond my knowledge of Nouveau and GPU drivers.
> 
> > Could it even already be fixed in the r570-based update to nouveau?
> 
> I doubt it.  Let me look at the logs, and if I don't see anything, I'll give
> you instructions on how to beta test r570.

Thanks. Attached to https://gitlab.freedesktop.org/drm/nouveau/-/issues/423

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]