lorenz / asrock-x300-s3-fix

Enabling S3 sleep on a DeskMini X300
MIT License
25 stars 8 forks source link

Patched ACPI tables do not provide S3 Sleep #3

Closed ghost closed 1 year ago

ghost commented 2 years ago

I have very curious case at hand here because even after your fix S3 sleep isn't available. I'am running X300-STX/4750G on Unraid 6.9.2 (based on Slackware 14.2) With the nix-based setup (and your help) I've managed to patch iasl, the acpi tables and to compile acpi_dsdt_override.cpio I was quite lost when it came to prepending the cpio to intramfs in Slackware. Unraid uses Syslinux boot config instead of grub or similar. So I consulted the documentation of syslinux regarding how to prepend a cpio archive to initramfs. And it seems quite easy:

Starting with version 3.71, an initrd can be specified in a separate statement (INITRD) instead of as part of the APPEND statement. This functionally appends "initrd=initrd_file" to the kernel command line.

It supports multiple filenames separated by commas. This is mostly useful for initramfs, which can be composed of multiple separate cpio or cpio.gz archives.

So I copied acpi_dsdt_override.cpio to /boot and changed my syslinux config from initrd=/bzroot to initrd=/acpi_dsdt_override.cpio,/bzroot

Et voila this is what my boot log says: Loading /bzimage... ok Loading /acpi_dsdt_override.cpio... ok Loading /bzroot... ok

I know the documentation says this mechanism is part of the APPEND (and not PREPEND) statement, but since the cpio is loaded before bzroot (-> initramfs) this counts for prepending, right?

The system booted correctly but still no S3 sleep. The status is exactly the same as before acpi table override: cat /sys/power/state says freeze and mem and no this is not real S3 (suspend to memory) since my system seems to resort to S5 when I execute echo -n "mem" > /sys/power/state More interesting is what syslog hast to say:

Jul  7 10:40:33 ElServerino kernel: ACPI: Table Upgrade: install [DSDT-ALASKA-  A M I ]
Jul  7 10:40:33 ElServerino kernel: ACPI: DSDT 0x00000000ADFFA000 005847 (v02 ALASKA A M I    0107200A INTL 20220331)

shouldn't there be something like Physical table override, new table: in the second entry?

Jul  7 10:40:33 ElServerino kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP6._PRW], AE_ALREADY_EXISTS (20200925/dswload2-326)
Jul  7 10:40:33 ElServerino kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20200925/psobject-220)
Jul  7 10:40:33 ElServerino kernel: ACPI: Skipping parse of AML opcode: OpcodeName unavailable (0x0014)
Jul  7 10:40:33 ElServerino kernel: ACPI: 10 ACPI AML tables successfully acquired and loaded
Jul  7 10:40:33 ElServerino kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
Jul  7 10:40:33 ElServerino kernel: ACPI: Interpreter enabled
Jul  7 10:40:33 ElServerino kernel: ACPI: (supports S0 S5)

aaaand still no S3

I dont know what the problem is but it seems like I didn't correctly prepended the patched table to initramf or patching the acpi table went wrong. Also I wonder if it is important to adjust the kernel version referenced in the default.nix to the kernel version of the system (I didn't do that)

Attached you find my acpi_dsdt_override.cpio. Thanks again for your help. acpi_dsdt_override.cpio.zip

lorenz commented 2 years ago

If you use the Nix-based setup and the patch succeeds, the resulting DSDT table is most likely correct.

Logs from my boxes (Upstream Linux 5.15.y):

ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml]
ACPI: Table Upgrade: override [DSDT-ALASKA-  A M I ]
ACPI: DSDT 0x00000000BB233000 Physical table override, new table: 0x00000000BD632000
ACPI: DSDT 0x00000000BD632000 005847 (v02 ALASKA A M I    0107200A INTL 20180427)

From looking around the kernel code which handles this, the UnRAID kernel might not have ACPI_TABLE_UPGRADE not enabled. That's required for replacing physical ACPI tables (like we're doing here).

ghost commented 2 years ago

That may be it. Seems I have to recompile my kernel. Thanks for helping.

lorenz commented 2 years ago

@noclueoncoding Can I close this?

ghost commented 1 year ago

Sorry for not closing myself. I went down the rabbit hole just to find out that the Unraid kernel actually is build with the following configs enabled:

CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y

It seems that wasn't it. And at this point it seems like end of the line for me, I guess. Yes, please close the issue and again thanks for your support.

lorenz commented 1 year ago

Yeah, it seems like UnRAID has a quirk which breaks loading the modified ACPI table. Closing this.