Re: [PATCH v2 09/15] gpu: nova-core: match GSP RPC replies by sequence, not just function

[John Hubbard]

On 8/30/26 6:09 PM, Alexandre Courbot wrote:
> On Sat Aug 29, 2026 at 10:33 AM JST, John Hubbard wrote:
...
> So I am particularly looking at patches 8-11 at first, because it looks
> like they can be merged ahead of the rest and are useful on their own,
> but I am hitting an error with this one when unloading the driver:
>
> modprobe -r nova-core
> [ 3333.123171] nova-core 0000:08:00.0: GSP RPC: send: seq# 3, function=UnloadingGuestDriver, length=0x58
> [ 3333.148123] nova-core 0000:08:00.0: GSP RPC: receive: seq# 0, function=Ok(GspPostNoCat), length=0x50c
> [ 3333.169449] nova-core 0000:08:00.0: GSP RPC: receive: seq# 0, function=Ok(UcodeLibOsPrint), length=0x78
> [ 3333.323550] nova-core 0000:08:00.0: GSP RPC: receive: seq# 0, function=Ok(UnloadingGuestDriver), length=0x50
> [ 3333.323551] nova-core 0000:08:00.0: GSP RPC: dropping stale UnloadingGuestDriver reply (seq 0, awaiting Some(3))
> [ 3338.124152] nova-core 0000:08:00.0: GSP shutdown failed: ETIMEDOUT
> [ 3338.161317] nova-core 0000:08:00.0: failed to unload GSP: ETIMEDOUT
>
> It looks like the GSP sends the UnloadingGuestDriver response with a
> sequence of 0... From what I can gather from OpenRM, 570.144 doesn't
> match the sequence number, only the function. Maybe this needs to be
> part of the r000 series instead, if that behavior is only expected
> there?

That sounds likely correct. In order to test this, I thought I was
being smart by using the r000 as a base, but of course that seems
to have led to this test hole. Let me go fix it up.

thanks,
--
John Hubbard