Bug 258432

Summary: Resume hangs unless copy_staging enable
Product: Base System Reporter: Taku YAMAMOTO <taku>
Component: kernAssignee: Konstantin Belousov <kib>
Status: Closed FIXED    
Severity: Affects Some People CC: emaste, grahamperrin, kib
Priority: ---    
Version: CURRENT   
Hardware: amd64   
OS: Any   

Description Taku YAMAMOTO 2021-09-11 13:36:06 UTC 
current as of bb61ccd530b76ab8a3945b1eccf7fa3c38647312 hangs during resume on amd64.

If I issue the loader command `copy_staging enable` either manually or in /boot/loader.rc.local, the resume works again.

da2f833f7a0bef3cde7d5fc2a05e4646e873567f : OK
bb61ccd530b76ab8a3945b1eccf7fa3c38647312 : hangs
bb61ccd530b76ab8a3945b1eccf7fa3c38647312 + copy_staging : OK

I suspect f75caed644a5c8c342a1ea5e7a6d5251f82ed0b1 (amd64 UEFI loader: stop copying staging area to 2M physical) breaks some assumptions that sys/amd64/acpica/acpi_wakecode.S implicitly relies.
Comment 1 Konstantin Belousov freebsd_committer freebsd_triage 2021-09-11 18:42:33 UTC 
Please try https://reviews.freebsd.org/D31916
Comment 2 Taku YAMAMOTO 2021-09-12 09:44:41 UTC 
(In reply to Konstantin Belousov from comment #1)
I'll give it a try.

Thanks in advance!
Comment 3 Taku YAMAMOTO 2021-09-12 12:29:21 UTC 
Unfortunately, things get worse if D31916 is applied:
resume hangs regardless of copy_staging.

FYI, kernphys is 0xb3c00000 on my machine if copy_staging auto.
Comment 4 Konstantin Belousov freebsd_committer freebsd_triage 2021-09-12 16:19:28 UTC 
Try updated D31916.94994 diff please.  I forgot to populate kernel mappings into
wakeup trampoline page table.
Comment 5 Taku YAMAMOTO 2021-09-12 17:44:20 UTC 
(In reply to Konstantin Belousov from comment #4)

The diff D31916.94994 works like a charm!

I successfully tested suspend/resume cycles several times in a row in the single user mode without copy_staging.

I'll experiment further with the multi user mode + Xorg + drm + modesetting + glamor.

Thanks a lot!
Comment 6 commit-hook freebsd_committer freebsd_triage 2021-09-13 16:56:31 UTC 
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=db2ba218d9fe6a541a4f537a641cce95f952fd98

commit db2ba218d9fe6a541a4f537a641cce95f952fd98
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2021-09-11 18:36:38 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2021-09-13 16:52:13 +0000

    amd64 acpi_wakeup: map 1:1 whole low 4G for the trampoline page table

    This is required since kernel text might be physically located
    anywhere below 4G.

    PR:     258432
    Reported by:    Taku YAMAMOTO <taku@tackymt.homeip.net>
    Reviewed by:    markj
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week
    Differential revision:  https://reviews.freebsd.org/D31916

 sys/x86/acpica/acpi_wakeup.c | 77 +++++++++++++++++++++++++++-----------------
 1 file changed, 48 insertions(+), 29 deletions(-)
Comment 7 Taku YAMAMOTO 2021-09-18 11:32:47 UTC 
(In reply to commit-hook from comment #6)

I confirmed that the current as of fd0765933c3ccb059ad7456e657b2e8ed22f58b0 did suspend/resume reliably.

(Including 1c56781cc915d1d2957e5b53717513193476d777 "amd64 wakeup: rework trampoline page allocation", of course!)

Thanks a lot for your work!
Comment 8 commit-hook freebsd_committer freebsd_triage 2021-09-20 00:48:53 UTC 
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=1a377b8415faae300cc325f870148ed112422ce6

commit 1a377b8415faae300cc325f870148ed112422ce6
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2021-09-11 18:36:38 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2021-09-20 00:47:20 +0000

    amd64 acpi_wakeup: map 1:1 whole low 4G for the trampoline page table

    PR:     258432

    (cherry picked from commit db2ba218d9fe6a541a4f537a641cce95f952fd98)

 sys/x86/acpica/acpi_wakeup.c | 77 +++++++++++++++++++++++++++-----------------
 1 file changed, 48 insertions(+), 29 deletions(-)