The core issue is that with f2a7f3238777, the kernel on the affected systems no longer uses hpet for the rtc alarm and update interrupts. This may indicate that their non-hpet implementation is faulty. By removing the ACPI_FADT_LOW_POWER_S0 check from use_acpi_alaram_quirks, the kernel expects to use the acpi alarm by way of use_hpet_alarm().
Other facts:
- this patch has only been applied to Jammy. Kinetic and Focal do not have the latest patches affecting rtc-cmos.
- applying these patches to jammy:linux-gcp work correctly on a g1-small instance. This system is able to use the acpi alarm for both alarm and update interrupts.
I see two options:
1) Revert f2a7f3238777 as a SAUCE patch. The justification for this commit seems to be based on the suspend-to-idle use case, notwithstanding the alarm from S0 use case.
2) Patch in a more specific quirk and get it upstreamed. It seems like the quirk that was removed was hiding a bug on this particular system.
The core issue is that with f2a7f3238777, the kernel on the affected systems no longer uses hpet for the rtc alarm and update interrupts. This may indicate that their non-hpet implementation is faulty. By removing the ACPI_FADT_ LOW_POWER_ S0 check from use_acpi_ alaram_ quirks, the kernel expects to use the acpi alarm by way of use_hpet_alarm().
Other facts:
- this patch has only been applied to Jammy. Kinetic and Focal do not have the latest patches affecting rtc-cmos.
- applying these patches to jammy:linux-gcp work correctly on a g1-small instance. This system is able to use the acpi alarm for both alarm and update interrupts.
I see two options:
1) Revert f2a7f3238777 as a SAUCE patch. The justification for this commit seems to be based on the suspend-to-idle use case, notwithstanding the alarm from S0 use case.
2) Patch in a more specific quirk and get it upstreamed. It seems like the quirk that was removed was hiding a bug on this particular system.