hpet_acpi_add: no address or irqs in _CRS


Apr 8, 2023
I see this in my journalctl should I care about this warning or ignore it? Seems like its disabling HPET?

root@HOME-SERVER:~# dmesg | grep -i hpet
[ 0.005064] ACPI: HPET 0x00000000582FC000 000038 (v01 ALASKA A M I 01072009 AMI 01000013)
[ 0.005106] ACPI: Reserving HPET table memory at [mem 0x582fc000-0x582fc037]
[ 0.067534] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.158209] hpet: HPET dysfunctional in PC10. Force disabled.
[ 0.158223] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[ 0.432406] hpet_acpi_add: no address or irqs in _CRS
telling from the following comment in the kernel, I guess you can ignore it
 * Check whether the system supports PC10. If so force disable HPET as that
 * stops counting in PC10. This check is overbroad as it does not take any
 * of the following into account:
 *  - ACPI tables
 *  - Enablement of intel_idle
 *  - Command line arguments which limit intel_idle C-state support
 * That's perfectly fine. HPET is a piece of hardware designed by committee
 * and the only reasons why it is still in use on modern systems is the
 * fact that it is impossible to reliably query TSC and CPU frequency via
 * CPUID or firmware.
 * If HPET is functional it is useful for calibrating TSC, but this can be
 * done via PMTIMER as well which seems to be the last remaining timer on
 * X86/INTEL platforms that has not been completely wreckaged by feature
 * creep.
 * In theory HPET support should be removed altogether, but there are older
 * systems out there which depend on it because TSC and APIC timer are
 * dysfunctional in deeper C-states.
 * It's only 20 years now that hardware people have been asked to provide
 * reliable and discoverable facilities which can be used for timekeeping
 * and per CPU timer interrupts.
 * The probability that this problem is going to be solved in the
 * forseeable future is close to zero, so the kernel has to be cluttered
 * with heuristics to keep up with the ever growing amount of hardware and
 * firmware trainwrecks. Hopefully some day hardware people will understand
 * that the approach of "This can be fixed in software" is not sustainable.
 * Hope dies last...
static bool __init hpet_is_pc10_damaged(void)
    unsigned long long pcfg;

    /* Check whether PC10 substates are supported */
    if (!mwait_pc10_supported())
        return false;

    /* Check whether PC10 is enabled in PKG C-state limit */
    rdmsrl(MSR_PKG_CST_CONFIG_CONTROL, pcfg);
    if ((pcfg & 0xF) < 8)
        return false;

    if (hpet_force_user) {
        pr_warn("HPET force enabled via command line, but dysfunctional in PC10.\n");
        return false;

    pr_info("HPET dysfunctional in PC10. Force disabled.\n");
    boot_hpet_disable = true;
    return true;
  • Like
Reactions: xokia


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!