HPET+PAT causes "bad page state"

Nevermind, I found the root cause. It is caused by code in hpet.c. There is a HPET device in DSDT which body contains:

    Method (GHPA, 0, Serialized)
    {
        Store (0x00, Local0)
        If (\HPDE)
        {
            Multiply (\HPEA, 0x0100, Local0)
        }

        Return (Local0)
    }
...
    Method (_CRS, 0, Serialized)
    {
        Name (CRES, ResourceTemplate ()
        {
            Memory32Fixed (ReadOnly,
                0xFED00000,         // Address Base
                0x00000400,         // Address Length
                _Y04)
        })
        Store (GHPA (), Local1)
        If (Local1)
        {
            CreateDWordField (CRES, \_SB.PCI0.LPCB.HPET._CRS._Y04._BAS,
HPEB)
            Store (Local1, HPEB)
        }

        Return (CRES)
    }

HPEA seems to be 3ed000. So the base of memory resource is set to 0x3ed00000. The problem is
1) it is not in reserved ranges reported by the BIOS (the modified variant contains only the protection hole at 0-10000):
modified physical RAM map:
modified: 0000000000000000 - 0000000000010000 (reserved)
modified: 0000000000010000 - 000000000009fc00 (usable)
modified: 000000000009fc00 - 00000000000a0000 (reserved)
modified: 00000000000ef000 - 0000000000100000 (reserved)
modified: 0000000000100000 - 00000000af6cf000 (usable)
modified: 00000000af6cf000 - 00000000afdcf000 (reserved)
modified: 00000000afdcf000 - 00000000afecf000 (ACPI NVS)
modified: 00000000afecf000 - 00000000afeff000 (ACPI data)
modified: 00000000afeff000 - 00000000aff00000 (usable)
modified: 00000000e0000000 - 00000000f0000000 (reserved)
modified: 00000000fec00000 - 00000000fec01000 (reserved)
modified: 00000000fec10000 - 00000000fec11000 (reserved)
modified: 00000000fee00000 - 00000000fee01000 (reserved)
modified: 00000000ffe00000 - 0000000100000000 (reserved)
modified: 0000000100000000 - 0000000240000000 (usable)

so allocator treats the page as normal ram page. Hence the warning in the original report.

2) there is only memory resource without any IRQ resources in _CRS method of HPET. Then we do not unmap space in hpet_acpi_add in 'if (!data.hd_address || !data.hd_nirqs)' branch. Technically we cannot do that, the intel HPET specs (1.0a) says (3.2.5.1):
_CRS (
// Report 1K of memory consumed by this Timer Block memory range consumed
// Optional: only used if BIOS allocates Interrupts [1] IRQs consumed
)

[1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as “consumed resources.”

In this particular case, the address reported by the BIOS seems to be bogus anyway, so non-presence of IRQ doesn't mean the "optional" part in point 2). So my question is whether the fix below [*] is enough or you want me to implement the "optional" part and then add a DMI quirk for this machine.

[*] It would probably be more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now.

@@ -1017,6 +1017,8 @@ static int hpet_acpi_add(struct acpi_device *device)
                return -ENODEV;
 
        if (!data.hd_address || !data.hd_nirqs) {
+               if (data.hd_address)
+                       iounmap(data.hd_address);
                printk("%s: no address or irqs in _CRS\n", __func__);
                return -ENODEV;
        }

thanks,

js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html