On Tue, Aug 19, 2025 at 01:20:47PM +1000, Jonathan Gray wrote:
> On Fri, Jul 18, 2025 at 08:11:31PM +1000, Jonathan Gray wrote:
> > On Sat, Jun 21, 2025 at 07:00:56PM +0200, Matthieu Herrb wrote:
> > > On Wed, Jun 04, 2025 at 08:39:19AM +0100, Laurence Tratt wrote:
> > > > As of somewhere in the last 10-14 days or so, my amd64 machine has
> > > > stopped
> > > > reliably suspending (for reference: it's reliably suspended for the past
> > > > 9-10 months). Unfortunately I haven't worked out *what* the sequence of
> > > > events that causes this is, so bisecting has proven impossible (I
> > > > tried...). When `zzz` is unsuccessful, X disappears, the machine drops
> > > > to
> > > > the console (i.e. displaying "Login:" or whatever was there last), and
> > > > then
> > > > is stuck there indefinitely: it doesn't get as far as "Syncing disks".
> > > > The
> > > > machine's fans spin up after a while, so presumably something is stuck
> > > > in a
> > > > busy loop.
> > >
> > > Hi,
> > >
> > > I'm seeing something similar on my X395 since some weeks. I *think*
> > > failure to suspend happens only after I've played a few large (HD) video
> > > with mpv, maybe in chrome too. I've not tried to figure out a
> > > reproducer.
> > >
> > > When it happens, and the machine sits a the login prompt, I can still
> > > interact with it for a couple of minutes before it freezes: type
> > > commands, enter ddb,... I cannot switch back to X (either instant
> > > freeze or panic) nor retry zzz. halt -p sometimes works, sometimes
> > > unlock the pending supend (so the machine suspends, and powers itself
> > > off shortly after resume).
> > >
> > > Unfortunatly I've no idea what kind of resources to look for that
> > > would be blocking the suspend path. Any clues of stuff I can run on
> > > the console or in ddb next time this happens ?
> >
> > I suggested Laurence try a revert of 6.12.31's
> > 'Revert "drm/amd: Stop evicting resources on APUs in suspend"'
> > And after a week or so of testing he hasn't had a problem.
> >
> > Perhaps it helps in your case as well? A T495 with the same
> > APU as the X395 (Picasso) suspends and resumes fine without this.
>
> This patch should be equivalent to reverting the revert.
> It is contained to a function that does not exist in linux.
>
> Laurence has been running with a diff close to this.
This seems to fix the issue for me too. I've not had an issue
suspending since I applied the patch. I'm not 100% it's totally gone
but I've done some stressing of the machine, playing hi-res videos,
loading lots of tabs in firefox and chrome (things that used to
trigger the issue) without reproducing the problem on suspend.
>
> Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c,v
> diff -u -p -r1.63 amdgpu_drv.c
> --- sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c 5 Jul 2025 23:44:49 -0000
> 1.63
> +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c 19 Aug 2025 03:10:58 -0000
> @@ -3888,6 +3888,14 @@ amdgpu_activate(struct device *self, int
> switch (act) {
> case DVACT_QUIESCE:
> rv = config_activate_children(self, act);
> +
> + if (acpi_softc && acpi_softc->sc_state != ACPI_STATE_S4) {
> + if (amdgpu_acpi_is_s0ix_active(adev))
> + adev->in_s0ix = true;
> + else if (amdgpu_acpi_is_s3_active(adev))
> + adev->in_s3 = true;
> + }
> +
> amdgpu_pmops_prepare(self);
> if (acpi_softc && acpi_softc->sc_state == ACPI_STATE_S4) {
> adev->in_s4 = true;
>
--
Matthieu Herrb
