From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Yinghai Lu" <yhlu.kernel@gmail.com>
Cc: "Ingo Molnar" <mingo@elte.hu>,
"David Witbrodt" <dawitbro@sbcglobal.net>,
"Linux-kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression
Date: Wed, 27 Aug 2008 16:42:25 -0700 [thread overview]
Message-ID: <200808271642.26486.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <86802c440808271623oc1ed5f1n8519fa7be9d1e301@mail.gmail.com>
On Wednesday, August 27, 2008 4:23 pm Yinghai Lu wrote:
> On Wed, Aug 27, 2008 at 3:41 PM, Jesse Barnes <jbarnes@virtuousgeek.org>
wrote:
> > 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
> >> >
> >> > - 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.
>
> 1. insert the lapic, ioapic, mmconf mmio address into resource tree at
> first... 2. later when we fail to request_resource for one BAR res of pci
> dev, call check_resource(.., res) to see if could find some res with the
> same range and the sticky flag.
> if so will insert BAR resource for the device forcibly.
>
> that should be for 2.6.28.
>
> > 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.
>
> not sure. actually we should rely on BIOS to allocate ioport/mmio for
> us. and only do some minor adjust to BAR
> that is obvious wrong. so have list for gap seems overkilling.
> for Hotplug, the acpi code in dst should (pre)allocate the resource
> for new insert devices.
For just reservations that may be true, but we definitely want more space
available for PCI device allocations. As for ACPI allocations, maybe, but we
have to make sure not to stomp on that space in the first place...
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2008-08-27 23:42 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-25 2:00 HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression David Witbrodt
2008-08-25 2:37 ` Yinghai Lu
2008-08-25 4:41 ` Yinghai Lu
2008-08-25 6:27 ` Ingo Molnar
2008-08-25 6:40 ` Yinghai Lu
2008-08-25 7:31 ` Ingo Molnar
2008-08-25 8:00 ` Yinghai Lu
2008-08-27 22:41 ` Jesse Barnes
2008-08-27 23:23 ` Yinghai Lu
2008-08-27 23:42 ` Jesse Barnes [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-26 15:25 David Witbrodt
2008-08-26 12:58 David Witbrodt
2008-08-26 13:28 ` Ingo Molnar
2008-08-25 13:39 David Witbrodt
2008-08-25 17:24 ` Yinghai Lu
2008-08-25 17:28 ` Yinghai Lu
2008-08-25 3:06 David Witbrodt
2008-08-24 13:05 David Witbrodt
2008-08-24 19:29 ` Yinghai Lu
2008-08-24 22:48 ` Yinghai Lu
2008-08-24 2:39 David Witbrodt
2008-08-24 3:44 ` Yinghai Lu
2008-08-23 23:42 David Witbrodt
2008-08-24 2:05 ` Yinghai Lu
2008-08-23 19:47 David Witbrodt
2008-08-23 20:12 ` Yinghai Lu
2008-08-23 20:51 ` Yinghai Lu
2008-08-23 19:29 David Witbrodt
2008-08-23 18:26 Rufus & Azrael
2008-08-23 19:17 ` Yinghai Lu
2008-08-23 19:40 ` Rufus & Azrael
2008-08-23 20:10 ` Yinghai Lu
2008-08-23 20:15 ` Rufus & Azrael
2008-08-23 20:28 ` Yinghai Lu
2008-08-23 20:33 ` Rufus & Azrael
2008-08-23 20:35 ` Yinghai Lu
2008-08-23 20:36 ` Rufus & Azrael
2008-08-23 20:45 ` Yinghai Lu
2008-08-23 21:05 ` Yinghai Lu
2008-08-28 22:52 ` Jordan Crouse
2008-09-12 17:39 ` Andreas Herrmann
2008-09-12 17:45 ` Jordan Crouse
2008-09-14 16:25 ` Ingo Molnar
2008-08-23 16:44 David Witbrodt
2008-08-23 16:32 David Witbrodt
2008-08-23 15:42 David Witbrodt
2008-08-23 15:55 ` Ingo Molnar
2008-08-23 11:58 David Witbrodt
2008-08-23 13:36 ` Ingo Molnar
2008-08-23 15:03 ` Ingo Molnar
2008-08-23 17:51 ` Yinghai Lu
2008-08-23 11:42 David Witbrodt
2008-08-23 2:25 David Witbrodt
2008-08-23 5:41 ` Yinghai Lu
2008-08-23 6:56 ` Yinghai Lu
2008-08-22 1:24 David Witbrodt
2008-08-21 16:53 David Witbrodt
2008-08-21 17:57 ` Yinghai Lu
2008-08-21 14:09 David Witbrodt
2008-08-21 15:33 ` Yinghai Lu
2008-08-21 13:33 David Witbrodt
2008-08-21 4:07 David Witbrodt
2008-08-21 6:42 ` Yinghai Lu
2008-08-21 7:04 ` Ilpo Järvinen
2008-08-21 2:48 David Witbrodt
2008-08-20 17:42 David Witbrodt
2008-08-20 17:58 ` Yinghai Lu
2008-08-21 2:02 ` Yinghai Lu
2008-08-20 16:44 David Witbrodt
2008-08-20 14:32 David Witbrodt
2008-08-20 14:49 ` Ingo Molnar
2008-08-20 14:08 David Witbrodt
2008-08-20 4:51 David Witbrodt
2008-08-20 5:21 ` Yinghai Lu
2008-08-20 7:51 ` Bill Fink
2008-08-20 8:02 ` Yinghai Lu
2008-08-20 9:15 ` Ingo Molnar
2008-08-20 9:31 ` Yinghai Lu
2008-08-20 9:36 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200808271642.26486.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=dawitbro@sbcglobal.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox