* Yinghai Lu <yhlu.kernel@gmail.com> wrote:

quoted text
> +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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/