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. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/2011854 Title: cmos_interrupt not getting called Status in linux-oracle package in Ubuntu: New Bug description: The ubuntu_ltp_kernel_misc rtc01 test case has exposed a possible regression of the RTC cmos driver on certain Oracle clouds. This was observed on jammy:linux-oracle-5.15.0-1031.37. - VM.DenseIO2.8 - VM.Standard2.1 rtc01 0 TINFO : RTC READ TEST: rtc01 1 TPASS : RTC READ TEST Passed rtc01 0 TINFO : Current RTC date/time is 16-3-2023, 17:36:04. rtc01 0 TINFO : RTC ALARM TEST : rtc01 0 TINFO : Alarm time set to 17:36:09. rtc01 0 TINFO : Waiting 5 seconds for the alarm... rtc01 2 TFAIL : rtc01.c:151: Timed out waiting for the alarm rtc01 0 TINFO : RTC UPDATE INTERRUPTS TEST : rtc01 0 TINFO : Waiting for 5 update interrupts... rtc01 3 TFAIL : rtc01.c:208: Timed out waiting for the update interrupt rtc01 0 TINFO : RTC Tests Done! Notice that we successfully enable RTC_AIE_ON, unlike VM.Standard.A1.Flex-4c.8m which does not support it. I confirmed with bpftrace on -1029 that we see the cmos interrupt (part of ltp read_alarm_test) sudo bpftrace -e 'kprobe:cmos_interrupt { printf("%s\n", probe) }' Attaching 1 probe... kprobe:cmos_interrupt On -1031 no interrupt is detected for both the alarm and update tests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/2011854/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
