On 3/5/25 6:59 AM, Mario Limonciello wrote:
On 3/4/2025 23:24, samasth.norway.ananda@xxxxxxxxxx wrote:
On 3/4/25 7:00 AM, Mario Limonciello wrote:
On 3/3/2025 17:48, samasth.norway.ananda@xxxxxxxxxx wrote:
Hi,
We recently observed that the LTP rtc01 RTC alarm test fails on
intel based VM's. This seems to be observed after the commit
6492fed7d8c95f53b0b804ef541324d924d95d41 - ("rtc: rtc-cmos: Do not
check ACPI_FADT_LOW_POWER_S0")
I noticed that the use_acpi_alarm was set to "N" before the commit,
now it is set as "Y"
# cat /sys/module/rtc_cmos/parameters/use_acpi_alarm
Y
#./runltp -d /tmpdir -s rtc01
<<<test_output>>>
incrementing stop
rtc01 0 TINFO : RTC READ TEST:
rtc01 1 TPASS : RTC READ TEST Passed
rtc01 0 TINFO : Current RTC date/time is 3-3-2025, 21:02:20.
rtc01 0 TINFO : RTC ALARM TEST :
rtc01 0 TINFO : Alarm time set to 21:02:25.
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!
I believe that the hypervisor may not fully support ACPI or may
implement it differently than physical hardware. ACPI wake-up events
may not be properly supported or may be emulated differently in the
VM, causing alarms to not trigger correctly or time out.
On AMD all instances the use_acpi_alarm is set to "N" so no issue seen.
On intel Bare metal instances the use_acpi_alarm is set to "Y" but
no issue seen.
But, on intel VM's the use_acpi_alarm is set to "Y" and the issue is
seen.
I even check with
# acpidump > acpidump.txt
# grep "FADT" acpidump.txt
no output from above saying that ACPI_FADT_LOW_POWER_S0 is not set.
Is it possible to know we can address this issue? Should we make
changes in the LTP test itself? or in the kernel?
I'm a bit surprised it didn't also affect AMD; but maybe that's
because of the specific date of the "BIOS" for the VM.
To me this sounds like a hypervisor bug though. Could you add a
condition to detect this hypervisor and exclude it (and also report
it to the vendor for the hypervisor "BIOS")?
It's not affecting AMD because of the first check as below in the
use_acpi_alarm_quirks() function.
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
return;
In AMD systems we return control right here and the use_acpi_alarm is
never set to true. But for intel the above condition wont pass.
What kernel are you working from?
Take a look at 6.14-rc5 and I see the AMD ones should apply as well.
Apologies. I should have mentioned earlier. I was using 5.15 kernel
which doesn't seem to have the commit
3d762e21d56370 - ("rtc: cmos: Use ACPI alarm for non-Intel x86 systems too")
On the latest 6.14-rc5 I see the issue on both Intel and AMD instances.
Both of them have use_acpi_alarm set to "Y"
https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/
v6.14-rc5/drivers/rtc/rtc-cmos.c*L813__;Iw!!ACWV5N9M2RV99hQ!
MSCvhczv2vkH0AFfUN6OgIpOEISmEW9BVob2fU7MLnPVbY6-
v3bgHGVojTh0KyfAoZzOUY1_AHlggpu1JtmiI2u7WQQP_UQDZg$
I added a check to find the hypervisor
cpuid(1, &eax, &ebx, &ecx, &edx);
if (ebx == 0x756e6547 && ecx == 0x6c65746e && edx == 0x49656e69)
hypervisor_name = "KVM";
I was able to detect the Hypervisor to be KVM. Do you think that the
issue is due to KVM?
Thanks,
Samasth.
What BIOS image is loaded by KVM? I'd say it's more likely an issue
with that BIOS image.
I see this in dmesg so think it's using UEFI.
[ 0.000000] efi: EFI v2.7 by EDK II
Also this folder exists -
# ls /sys/firmware/efi
config_table efivars fw_platform_size fw_vendor mok-variables
runtime runtime-map systab
