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. Dave.
