[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080828211647.GA32431@elte.hu>
Date: Thu, 28 Aug 2008 23:16:47 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Yinghai Lu <yhlu.kernel@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
David Witbrodt <dawitbro@...global.net>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: split e820 reserved entries record to late v2
* Yinghai Lu <yhlu.kernel@...il.com> wrote:
> +void __init e820_reserve_resources_late(void)
> +{
> + int i;
> + struct resource *res;
> +
> + res = e820_res;
> + for (i = 0; i < e820.nr_map; i++) {
> + if (e820.map[i].type == E820_RESERVED && res->start >= (1ULL<<20))
> + insert_resource(&iomem_resource, res);
> + res++;
> + }
> +}
Here we have the problem of overlap i outlined earlier: if there's a
partial overlap at this stage (as i think it can happen in the hpet case
on David's box), we wont insert the E820_RESERVED resource.
The hpet hang will be solved, because we dont reprogram the BAR, but we
now keep the formerly e820-reserved area as 'free' - which the PCI code
could allocate new resources into - which could cause other problems
(hangs, non-working devices, etc.) down the line.
Which most likely wont happen currently in practice (there's enough free
space elsewhere), but it's still a not truly 'free' area and it would be
nice to have a complete and correct picture, based on all sources of
information we have.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists