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

[Ingo Molnar <mingo@elte.hu>]

* 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.

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.)

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.

This approach would be even more generic and would allow a robust 
insertion of maybe-PCI addresses into the resource tree.

	Ingo