On Thu Jul 2, 2026 at 2:30 AM CEST, David Airlie wrote: > On Thu, Jul 2, 2026 at 10:27 AM Danilo Krummrich <[email protected]> wrote: >> >> (Cc: John) >> >> On Wed Jul 1, 2026 at 8:17 PM CEST, Lyude Paul wrote: >> > It turns out that the only reason our previous fixes looked like they >> > worked for this was because we would occasionally set the Gcoff state to 0 >> > in the normal S3 path, which fixed suspend/resume on desktops - but not on >> > machines using runtime suspend. >> > >> > The proper fix is to just never set this flag. Our current guess for the >> > reasoning behind this is that Gcoff likely coincides with GC6, and not >> > literally power off. >> >> I don't think GcOff coincides with GC6, it should actually be a power off. >> >> From a quick glance in OpenRM, it seems that with bEnteringGcoffState = 1 it >> also saves off buffers flagged as MEMDESC_FLAGS_LOST_ON_SUSPEND. >> >> My guess would be that with bEnteringGcoffState = 1, GSP's resume path >> expects >> certain kernel-driver-allocated buffers to still be in place that nouveau >> didn't >> save off, or rather never had in the first place. >> >> John, do you have some details about this? >> > > In nouveau we have the INST_SR_LOST target, for buffers that aren't > preserved, I wonder did something change between 535 and 570 around > what needs to be kept around.
The r535 code never set bEnteringGcoffState in the first place. In r535 OpenRM seems to do the exact same thing.
