Messages in this thread Patch in this message | | | Date | Sun, 24 Aug 2008 12:29:11 -0700 | From | "Yinghai Lu" <> | Subject | Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression |
| |
On Sun, Aug 24, 2008 at 6:05 AM, David Witbrodt <dawitbro@sbcglobal.net> wrote: > > >> > - Is there any chance I can get it into the stable 2.6.26.X updates? >> > (Who should I ask, or are only developers allowed to lobby for this >> > sort of thing?) >> >> after the patch get into linus tree. Greg will put the patch into 2.6.26.X > > OK, thanks a bunch. > > >> > - Are you worried about the potential problems of a quirk-based approach? >> > What if many more people experience a similar regression once 2.6.26 or >> > later appears in their distribution? I'm sure you don't want to have to >> > write a different quirk for each individual's hardware, and this problem >> > did not arise with the approach used for resource management in 2.6.25. >> >> this patch should be safe. >> >> 2.6.26 is fixing one bug about reserving local apic address and that >> in e820 table. >> and it reveals one bios bug. > > Correction -- it revealed at least two. See the link I posted earlier in > this thread: > > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0808.2/1807.html > > Scroll down to the line that starts with "[blog]" for the link. You can see > the discussion I had encouraging him to come here to help us troubleshoot > if you go to that blog and click "Comments". > > I only mention this as a warning, in case it could lead to a lot of extra > problems for you later. If you're quite sure that everything is OK, then > all I can do is thank you again and keep my fingers crossed for you and the > kernel team that nothing bad happens when 2.6.2[67] hit the major distros.
after discussing with Ingo, we have one more generic way to detect the same situation.
please help to verify the attached patch. ( don't apply previous patch)
YH [PATCH] x86: check hpet with BAR
insert some resources to resource tree forcily, so could avoid kernel update the resources in pci device.
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 + + return 0; +} + /* * Handle resources of PCI devices. If the world were perfect, we could * just allocate all the resource regions and do nothing more. It isn't. @@ -128,6 +153,24 @@ static void __init pcibios_allocate_bus_ pr = pci_find_parent_resource(dev, r); if (!r->start || !pr || request_resource(pr, r) < 0) { + if (check_res_with_valid(dev, r)) { + struct resource *root = NULL; + + /* + * forcibly insert it into the + * resource tree + */ + if (r->flags & IORESOURCE_MEM) + root = &iomem_resource; + else if (r->flags & IORESOURCE_IO) + root = &ioport_resource; + + if (root) { + insert_resource(root, r); + } + continue; + } + dev_err(&dev->dev, "BAR %d: can't " "allocate resource\n", idx); /* | |