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

[John Hubbard]

On 8/30/26 9:33 PM, John Hubbard wrote:
> 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.
> 

Actually, my existing tests pass with both r570 and r000, but the real
problem was that my test suite did not include unloading nova-core.ko.

With that test added,  I can reproduce your reported failure locally.
Debugging it now.

thanks,
-- 
John Hubbard