[Bug 282964] efifb does not reactivate the screen after resuming from S3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282964

            Bug ID: 282964
           Summary: efifb does not reactivate the screen after resuming
                    from S3
           Product: Base System
           Version: 15.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: keivan@motavalli.me

Hello,
I'm trying to troubleshoot some acpi issues on systems I own.
I noticed that all of them (a 7th gen i9 with an rtx 3060 gpu and no onboard
graphics, a laptop running an 6th gen i7 cpu with onboard graphics, a ryzen 3
desktop with only onboard graphics, a 12th gen i5 laptop with onboard graphics
and a secondary nvidia gpu not wired to the screen) present the same problem:

when issuing acpiconf -s 3 from the console, they enter acpi s3, and when
resuming they don't turn the screen back on (it stays not illuminated if
integrated in the laptop, or powered off if external).

all of them are booting in UEFI mode and using efifb as the VT driver:
"VT(efifb): resolution 3440x1440"

all of them are however still responsive and fully usable via SSH while in that
post-resume display off state.

having the kernel resume vector try to reset the screen by setting first
hw.acpi.reset_video=1 does not work.

However, on each of them, installing and using the appropriate driver from
drm-kmod or the nvidia-drm-kmod driver (on the dedicated gpu desktop) solves
the display-off-on-resume issue, both when in a cli environment and when an X11
session is active/in use.

I think the issue might be with how efifb deals with hardware reactivation.
I tried adding some debug printfs in vt and efifb and can confirm the the
kernel suspend/resume hooks get set by vt, and that when suspending and
resuming efifb successfully has vt_suspend() and vt_resume() from vt_core.c
executed without error.
So maybe some hardware init/reset that is necessary on those systems is not
getting done by vt/efifb, while the drm helpers called when other drivers are
in use succeed.

I see that suspend/resume support to efifb was initially added when solving the
#237050 pr, but only signalling Xorg to release/reacquire the display was
considered (with X and the proprietary nvidia driver in use as the use case).

I don't know how to troubleshoot the problem further, but in case additional
output is needed I'd be testing under the i9-7980XE/geforce rtx 3060/asus PRIME
X299-A rev 1 motherboard desktop PC for convenience, since that system is
already running 15-CURRENT

-- 
You are receiving this mail because:
You are the assignee for the bug.