Re: HPET+PAT causes "bad page state"

[Jiri Slaby <jslaby@suse.cz>]

On 08/16/2010 12:51 PM, Jiri Slaby wrote:
> On 08/16/2010 10:54 AM, Jiri Slaby wrote:
>> Hi,
>>
>> with 2.6.35.1, there is an opensuse user who gets the following BUG:
>> BUG: Bad page state in process md5sum  pfn:3ed00
>> page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
>> page flags: 0x20000000800000(uncached)
>> Pid: 2515, comm: md5sum Not tainted 2.6.35.1-1-vanilla #1
>>
>> I have also a backtrace (from older, non-vanilla kernel):
>> BUG: Bad page state in process md5sum  pfn:3ed00
>> page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
>> page flags: 0x20000001000000(uncached)
>> Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
>> Call Trace:
>>  [<ffffffff81005ca9>] dump_trace+0x79/0x340
>>  [<ffffffff8149e612>] dump_stack+0x69/0x6f
>>  [<ffffffff810df851>] bad_page+0xb1/0x100
>>  [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0
>>  [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640
>>  [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0
>>  [<ffffffff810e35a4>] __do_page_cache_readahead+0x114/0x290
>>  [<ffffffff810e389c>] ra_submit+0x1c/0x30
>>  [<ffffffff810e3c38>] page_cache_async_readahead+0x98/0xe0
>>  [<ffffffff810d95bb>] do_generic_file_read.clone.0+0x25b/0x440
>>  [<ffffffff810daf94>] generic_file_aio_read+0xb4/0x1c0
>>  [<ffffffff8112426f>] do_sync_read+0xbf/0x100
>>  [<ffffffff81124a53>] vfs_read+0xb3/0x190
>>  [<ffffffff81124b7e>] sys_read+0x4e/0x90
>>  [<ffffffff81002ffb>] system_call_fastpath+0x16/0x1b
>>  [<00007f51336f03e0>] 0x7f51336f03e0
>>
>>
>> Obviously if he disables PAT by nopat parameter, it goes away. The page
>> is always the same (0x3ed00000). I asked for pat_memtype_list, so I'll
>> attach that later.
> 
> Here it is, as promised:
> uncached-minus @ 0xafdc4000-0xafdc5000
> uncached-minus @ 0xafe7e000-0xafe7f000
> uncached-minus @ 0xafe7f000-0xafe80000
> uncached-minus @ 0xafe81000-0xafe82000
> uncached-minus @ 0xafe83000-0xafe84000
> uncached-minus @ 0xafeda000-0xafedb000
> uncached-minus @ 0xafedb000-0xafedc000
> uncached-minus @ 0xafedc000-0xafedd000
> uncached-minus @ 0xafedd000-0xafede000
> uncached-minus @ 0xafede000-0xafefa000
> uncached-minus @ 0xafefa000-0xafefb000
> uncached-minus @ 0xafefb000-0xafefc000
> uncached-minus @ 0xafefc000-0xafefd000
> uncached-minus @ 0xafefd000-0xafefe000
> uncached-minus @ 0xc0040000-0xc0140000
> uncached-minus @ 0xc0141000-0xc06c0000
> uncached-minus @ 0xd4100000-0xd4101000
> uncached-minus @ 0xd4103000-0xd4104000
> uncached-minus @ 0xd5200000-0xd5204000
> uncached-minus @ 0xd6400000-0xd6410000
> uncached-minus @ 0xd6410000-0xd6414000
> uncached-minus @ 0xd6500000-0xd6504000
> uncached-minus @ 0xd6504000-0xd6505000
> uncached-minus @ 0xd6505000-0xd6506000
> uncached-minus @ 0xd6506000-0xd6507000
> uncached-minus @ 0xd6507000-0xd6508000
> uncached-minus @ 0xd6508000-0xd6509000
> uncached-minus @ 0xd6509000-0xd650a000
> uncached-minus @ 0xd650a000-0xd650b000
> uncached-minus @ 0xd650b000-0xd650c000
> uncached-minus @ 0xe0000000-0xf0000000
> uncached-minus @ 0xe0088000-0xe0089000
> uncached-minus @ 0xe00c3000-0xe00c4000
> uncached-minus @ 0xfed00000-0xfed01000
> uncached-minus @ 0xfed40000-0xfed45000
> uncached-minus @ 0xfed40000-0xfed41000
> uncached-minus @ 0xfed80000-0xfed81000
> 
>> The original bugreport is at:
>> https://bugzilla.novell.com/show_bug.cgi?id=629908
>>
>> Any idea what's going on?

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.

--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html