lkml.org 
[lkml]   [2008]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression
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


\
 
 \ /
  Last update: 2008-08-25 08:43    [W:0.082 / U:5.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site