Bug 199117

Created attachment 274727 [details]
full dmesg from next boot

please attach the acpidump output for this platform.

Created attachment 275911 [details]
acpidump output

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
        P80D = Zero
        P8XH (Zero, Arg0)
        G1S3 = Ones
        G1S2 = Ones
        G1S = One
        G1E = One
        G0S = Ones
        If ((Arg0 == 0x03))
        {
            If ((DTSE && MPEN))
            {
                TRAP (TRTD, 0x1E)
            }
        }

        If (CondRefOf (TCGM))
        {
            \_SB.PCI0.LPCB.TPM.PTS (Arg0)
        }
    }
_PTS method invokes  \_SB.PCI0.LPCB.TPM.PTS, while  \_SB.PCI0.LPCB.TPM.PTS is not defined anywhere.
This looks like a BIOS bug to me. can you please check if there is any TPM related options in BIOS and see if changing that BIOS setting helps or not?

Thanks for the analysis. Unfortunately, there are no TPM-related options. The only thing I can see is "TPM not detected" entry at the bottom of "Security" screen.

Retrying with kernel-4.16.12-300.fc28.x86_64 (Fedora 28) I get the same error. Is there anything else I can do?

does S3/S4 works on your platform?
if yes, can you please attach the dmesg output after resume from S3/S4?

(In reply to Zhang Rui from comment #6)
> does S3/S4 works on your platform?
> if yes, can you please attach the dmesg output after resume from S3/S4?

The system appears to enter suspend state (fans stop) after running "systemctl suspend", but after I wake it up using the power button, the screen remains blank. That seems to be a separate issue, possibly related to the broken gma500_gfx driver not being loaded because I blacklisted due to https://bugzilla.kernel.org/show_bug.cgi?id=199115 . The system is nevertheless otherwise functional (e.g. Ctrl+Alt+Del from the console reboots it gracefully) and I'm attaching the dmesg from the session.

Created attachment 276881 [details]
dmesg from suspend and resume session

Still occurring with Fedora 29 kernel-4.19.2-300.fc29.x86_64.

Still reproducible with Fedora 29 kernel-4.19.10-300.fc29.x86_64.

With kernel-4.19.13-300.fc29.x86_64 I get the following messages:

[ 520.872566] ACPI: Preparing to enter system sleep state S5
[ 520.877255] ACPI Error:
[ 520.877259] No handler or method for GPE 0500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000053F (\GB
[ 520.877262] No handler or method for GPE 00, disabling event (20180810/evgpe-835)
[ 520.881642] Could not resolve [\_SB.PCI0.LPCB.TPM.PTS], AE_NOT_FOUND (20180810/psargs-330)
[ 520.895000] ACPI Error: Method parse/execution failed \_PTS, AE_NOT_FOUND (20180810/psparse-516)
[ 520.899532] reboot: Power down

4.20.15-200.fc29.x86_64:
[  87.817882] ACPI: Preparing to enter system sleep state S5
[  87.822587] ACPI Error: No handler or method for GPE 00, disabling event
[  87.822591] ACPI BIOS Error (bug):
[  87.822596]  (20181003/evgpe-835)
[  87.827644] Could not resolve [\_SB.PCI0.LPCB.TPM.PTS], AE_NOT_FOUND (20180810/psargs-330)
[  87.841262] ACPI Error: Method parse/execution failed \_PTS, AE_NOT_FOUND (20180810/psparse-516)
[  87.845857] reboot: Power down

Is there anything I can do to make this board power down correctly?

5.0.5-200.fc29.x86_64:

ACPI: Preparing to enter system sleep state S5
ACPI Error:
ACPI Error:
Could not resolve [\_SB.PCI0.LPCB.TPM.PTS], AE_NOT_FOUND
No handler or method for GPE 00, disabling event (20181213/evgpe-835)
 (20180810/psargs-330)
ACPI Error: Method parse/execution failed \_PTS, AE_NOT_FOUND (20181213/psparse-531)
reboot: Power down

So, for the record, I was told[0] to flash a different UEFI firmware[1] (seems to be the same as [2]) by tech support and with that firmware the bug is gone. They won't recommend it, because it's for the "Windows NAS" model (W5000+)[3], but it works for me and the hardware specs seem to be the same as the N5550[4].

[0] https://thecus.kayako.com/Tickets/Ticket/View/38798
[1] https://www.dropbox.com/s/85c4yeqyefj2yr3/WCDV_05.zip?dl=1
[2] http://www.thecus.com/Downloads/BIOS/WCDV_05.zip
[3] http://wss.thecus.com/product_W5000.php
[4] http://www.thecus.com/product.php?PROD_ID=76

Good to know.
so this indeed seems like a BIOS problem and you're luck to have this fixed by BIOS upgrade. :)
Bug closed.