suspend/resume regression

[Niclas Zeising]

On 05/13/18 18:16, Michael Gmelin wrote:
> 
> 
>> On 13. May 2018, at 11:54, Niclas Zeising <zeising+freebsd at daemonic.se> wrote:
>>
>>> On 05/13/18 09:48, Andriy Gapon wrote:
>>>> On 13/05/2018 05:25, Pete Wright wrote:
>>>> hi there - i have an amd64 laptop that's been running CURRENT for a while using
>>>> both drm-next and drm-stable for graphics. during the past week or so i've run
>>>> into issues with suspend resume...well technically resume has stopped working.
>>>> i've tested a couple configurations and none have allowed my system to resume
>>>> successfully:
>>>>
>>>> - drm-next installed with DMC firmware loaded
>>>> - drm-next installed without DMC firmware loaded (worked previously)
>>>> - drm-stable with DMC
>>>> - drm-stable without DMC
>>>> - no drm modules loaded.
>>>>
>>>> I've also tested these configs with the following sysctl set to 0 and 1:
>>>> hw.acpi.reset_video
>>>>
>>>> at this point i'd like to help find what the regression i'm running into is, so
>>>> any pointers on how i can help? the system seems to boot and i'm pretty sure i
>>>> can ssh into it most times, just not sure what info i should grab to help.
>>>> nothing of interest in messages or dmesg buffer either.
>>> Did you do any OS upgrades what was last working version and what is the current
>>> version (svn revision number)?
>>> Or any other notable changes before resume stopped working...
>>
>> Hi!
>> I'm also seeing issues, not as severe as Pete, but after I resume (which works, with drm-next and DMC firmware), the system becomes sluggish.  It feels like I/O takes more time, and graphics are sluggish (very sientific, I know, but for instance git operations are much slower after a resume).  I know there's been an update to acpica between my system updates, when this started to happen, but I haven't had time to revert that update and test again.  I will try to do that and report back.
> 
> Maybe a stupid question, but did you check the cpu frequency before and after suspend/resume? (sysctl dev.cpu)

As far as I can tell, the frequency remains the same.  I looked at 
dev.cpu.0.freq, if there's any other sysctl to look at as well, please 
let me know.
Regards
-- 
Niclas