> From: Greg Steuck <gne...@openbsd.org>
> Date: Tue, 13 Aug 2024 21:13:19 -0700
>
> Greg Steuck <gne...@openbsd.org> writes:
>
> >> I suspect around wsdisplay_suspend() and wsdisplay_resume(); I've recently
> >> discovered that the mux aspects are insane.
> >
> > I applied the patches below and added a bunch of tracing to
> > subr_suspend. First zzz:
>
> I also added this:
>
> modified sys/kern/subr_autoconf.c
> @@ -827,8 +827,10 @@ config_suspend(struct device *dev, int act)
> int r;
>
> device_ref(dev);
> - if (ca->ca_activate)
> + if (ca->ca_activate) {
> r = (*ca->ca_activate)(dev, act);
> + printf("config_suspend: %s %d\n", dev->dv_xname, r);
> + }
> else
> r = config_activate_children(dev, act);
>
> Which gives the following joyful traces (failed attemp 2 before
> successful attemp 1). The important bit, I guess, is that
> > config_suspend: amdgpu0 0
> is not printed the second time around which I read as ca->ca_activate
> for amdgpu0 never returned? I can reconfirm with more tracing if
> somebody thinks my conclusion is premature.
Certainly looks like a smoking gun to me.
One thing to look at is amdgpu_acpi_is_s0ix_active() in
dev/pci/drm/amd/amdgpu/amdgpu_acpi.c. That function should return
true, but may be returning false because we don't #define CONFIG_AMD_PMC.
So maybe try what happens if you force that function to return true.
