> From: Greg Steuck
> Date: Tue, 13 Aug 2024 21:13:19 -0700
>
> Greg Steuck 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_sus
Mark Kettenis writes:
> 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 happen
Greg Steuck writes:
> The patch below doesn't seem to have any effect. I still see the same
> unfinished sleep the second time around. The last dmesg entry then
> is still
>> config_suspend: wsdisplay0 0
>
> I'll try to run other experiments with not having started X at all.
Not having run X doe
for in_s0ix to be set the activate function needs to
call the pmops wrappers
that may help
amdgpu_pm_ops contains other function pointers that may
also be of interest
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c
===
RCS file: /cvs
Jonathan Gray writes:
> for in_s0ix to be set the activate function needs to
> call the pmops wrappers
>
> that may help
>
> amdgpu_pm_ops contains other function pointers that may
> also be of interest
Applying this (and undoing the return true stampede) gets me into a
state where I can reliabl
