Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression

["Yinghai Lu" <yhlu.kernel@gmail.com>]

On Sun, Aug 24, 2008 at 11:27 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>> [PATCH] x86: check hpet with BAR v2
>>
>> insert some resources to resource tree forcily, so could avoid kernel update the
>> resources in pci device.
>>
>> should check in device too.
>>
>> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>>
>> ---
>>  arch/x86/pci/i386.c |   43 +++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>
>> Index: linux-2.6/arch/x86/pci/i386.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/pci/i386.c
>> +++ linux-2.6/arch/x86/pci/i386.c
>> @@ -33,6 +33,7 @@
>>  #include <linux/bootmem.h>
>>
>>  #include <asm/pat.h>
>> +#include <asm/hpet.h>
>>
>>  #include "pci.h"
>>
>> @@ -77,6 +78,30 @@ pcibios_align_resource(void *data, struc
>>  }
>>  EXPORT_SYMBOL(pcibios_align_resource);
>>
>> +static int check_res_with_valid(struct pci_dev *dev, struct resource *res)
>> +{
>> +     unsigned long base;
>> +     unsigned long size;
>> +
>> +     base = res->start;
>> +     size = (res->start == 0 && res->end == res->start) ? 0 :
>> +              (res->end - res->start + 1);
>> +
>> +     if (!base || !size)
>> +             return 0;
>> +
>> +#ifdef CONFIG_HPET_TIMER
>> +     /* for hpet */
>> +     if (base == hpet_address && (res->flags & IORESOURCE_MEM)) {
>> +             dev_info(&dev->dev, "BAR has HPET at %08lx-%08lx\n",
>> +                              base, base + size - 1);
>> +             return 1;
>> +     }
>> +#endif
>
> i think the warning should be more prominent and should also generate a
> stack trace for the kerneloops client to pick up. A WARN() printout
> would be perfect here.

dev_warn or WARN_ON?

>
> Also, we should do subsequent commits as well enumerating all the other
> 'magic' non-PCI-enumerated bus memory resources that matter on a PC
> platform: lapic address and io-apic address(es). Perhaps even the ACPI
> NVS and ACPI data areas that are enumerated in e820.
>
> (the lapic address will likely never be present in a PCI device - but
> maybe the IO-APIC address can be present in theory - so lets protect
> it.)

yes. other than default io_apic addr.
mmconf ?

>
> Another suggestion: perhaps this all should be done as a new, "sticky"
> resource type flag [defined in include/linux/ioport.h and implemented in
> kernel/resource.c], which would be inserted by the hpet driver, and
> which would be listened to by pcibios_allocate_resources()
> automatically. If the resource manager later on finds a generic-looking,
> unclaimed PCI device whose BAR matches on it, then the new semantics
> would mean that the device's BAR will not be touched.

pcibios_allocate_resources() consult resource_manager before
request_resource(pr, r)...

YH