Recent bug,  https://crbug.com/803727 , identified a regression where powerd hit its userspace suspend timeout ... 

[0118/210402:WARNING:suspend_delay_controller.cc(205)] Timed out while waiting for suspend request 104136709 readiness confirmation for 1 delay(s): 104136707 (:1.87: chrome)

in this case because lock screen registered a suspend deferral but never responded with its readiness once powerd announced suspend.

Suggestion that power_UiResume may be a good candidate for finding these regressions as it does expand on power_Resume by logging in prior to s2r cycle.

Looks like client/site_tests/desktopui_ScreenLocker has an example for dealing w/ screen lock that can hopefully be adapted.

Should also look at other 'suspend deferrals' (list from Dan ... thanks!)

- screen lock (ash/system/power/power_event_observer.cc)
- display configuration (ash/system/power/power_event_observer.cc)
- reporting suspend events to extensions (chrome/browser/chromeos/power/extension_event_observer.cc)
- unmounting disks (chromeos/disks/suspend_unmount_manager.cc)
- notifying ARC (components/arc/power/arc_power_bridge.cc)
- closing ARC video capture device (media/capture/video/chromeos/video_capture_device_arc_chromeos.cc)

and get coverage of those scenarios as well.

Mengqi can you have a look?