Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Apr 2019 15:19:10 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 237050] [PATCH] vt efifb back-end does not send display release / re-acquire signals on suspend / resume
Message-ID:  <bug-237050-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237050

            Bug ID: 237050
           Summary: [PATCH] vt efifb back-end does not send display
                    release / re-acquire signals on suspend / resume
           Product: Base System
           Version: 11.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: ekurzinger@nvidia.com

Using the latest NVIDIA driver, upon resuming from suspend while X is runni=
ng
the display will remain blank. Additionally, and OpenGL applications that w=
ere
running will trigger a number of error messages from the NVIDIA driver
resembling the following:

NVRM: GPU at PCI:0000:05:00: GPU-e0851a46-0a85-f806-1e95-94e61ad45653
NVRM: GPU Board Serial Number: 0331118033409
NVRM: Xid (PCI:0000:05:00): 13, Graphics SM Warp Exception on (GPC 0, TPC 1=
):
Illegal Instruction Encoding
NVRM: Xid (PCI:0000:05:00): 13, Graphics Exception: ESR 0x504e48=3D0x3f0009
0x504e50=3D0x0 0x504e44=3D0xd3eff2 0x504e4c=3D0x17f
NVRM: Xid (PCI:0000:05:00): 13, Graphics SM Warp Exception on (GPC 0, TPC 2=
):
Illegal Instruction Encoding
NVRM: Xid (PCI:0000:05:00): 13, Graphics Exception: ESR 0x505648=3D0x3f0009
0x505650=3D0x0 0x505644=3D0xd3eff2 0x50564c=3D0x17f

This is because the efifb back-end for vt will not signal the X server to
release the display before suspending (or to re-acquire it after resuming)
resulting in important code in the NVIDIA driver responsible for smoothly
shutting down and re-initializing the GPU not running. Since the NVIDIA dri=
ver
doesn't currently support framebuffer devices, vt is forced to fall back to
this efifb back-end, unlike on Intel hardware, for instance, where it will
instead use the fb back-end that does correctly implement the display hand-=
off
logic. The following patch adds vd_suspend and vd_resume members to the efi=
fb
back-end's vt_driver struct. These simply call the vt_suspend and vt_resume
functions from vt_core.c (similar to the behavior of the fb back-end). This
ensures the X server is properly able to re-initialize the display and prev=
ents
the above errors from 3D applications.

--- sys/dev/vt/hw/efifb/efifb.c (revision 345767)
+++ sys/dev/vt/hw/efifb/efifb.c (working copy)
@@ -66,6 +66,8 @@
        .vd_fb_mmap =3D vt_fb_mmap,
        /* Better than VGA, but still generic driver. */
        .vd_priority =3D VD_PRIORITY_GENERIC + 1,
+       .vd_suspend =3D vt_suspend,
+       .vd_resume =3D vt_resume,
 };

 static struct fb_info local_info;

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237050-227>