Messages in this thread | | | From | Jesse Barnes <> | Subject | Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression | Date | Wed, 27 Aug 2008 15:41:10 -0700 |
| |
On Monday, August 25, 2008 1:00 am Yinghai Lu wrote: > On Mon, Aug 25, 2008 at 12:31 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Yinghai Lu <yhlu.kernel@gmail.com> wrote: > >> this one should work. please apply this one only. > >> > >> YH > >> > >> [PATCH] x86: check hpet with BAR v2 > > > > great. I've cleaned it up a bit (see the final commit below) and queued > > it up in tip/x86/urgent for some testing. But there are a few open > > questions, and an Ack/feedback from Jesse/Linus would be nice as well: > > > > - the forced insertion and the embedded knowledge about iomem_resource > > and ioport_resource looks ugly to me. > > > > - we should also extend this to other platform resource types that we > > know about: ioapic address(es) might be a prime candidate. (local > > APICs are CPU entities and should never show up as PCI devices) The > > mmconfig range is already properly accounted for by the PCI code > > itself, right? > > please check v3 > > > - plus a more highlevel approach would be nice as well i think - making > > sure that the hpet driver runs before any of the PCI code, and > > inserting a special "sticky" resource there which would keep any > > potential followup generic PCI resource that overlaps this resource > > untouched. (with a proper kernel warning emitted as well - such > > situations are likely BIOS bugs.) > > yes, can remove that late_initcall tricky code to insert resource for > lapic and ioapic, and mmconfig etc.
I agree, a higher level way of dealing with resource reservation might be nice. I'm hoping to polish up TJ's PCI allocation code (http://tjworld.net/wiki/Linux/PCIDynamicResourceAllocationManagement) for 2.6.28; it may have some stuff that can help.
Thanks, -- Jesse Barnes, Intel Open Source Technology Center
| |