Bug 258432 - Resume hangs unless copy_staging enable
Summary: Resume hangs unless copy_staging enable
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Konstantin Belousov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-11 13:36 UTC by Taku YAMAMOTO
Modified: 2021-09-18 11:32 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 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 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 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!