H. Peter Anvin writes:
> Grant Grundler wrote:
> > On Sat, Jun 27, 2009 at 11:45:24AM +0200, Mikael Pettersson wrote:
> > ...
> >> fff00000-fffffffe : pnp 00:09
> >> 100000000-1ffffffff : System RAM
> >> 200000000-ffffffffffffffff : RAM buffer
> >>
> >> With 2.6.30 things look similar, except 2.6.30 does not show the
> >> last "200000000-ffffffffffffffff : RAM buffer" line.
> >
> > BIOS e280 table didn't report that line.
> > I expect it's created by arch/x86/kernel/e820.c:
> > 1398 /*
> > 1399 * Try to bump up RAM regions to reasonable boundaries to
> > 1400 * avoid stolen RAM:
> > 1401 */
> > 1402 for (i = 0; i < e820.nr_map; i++) {
> > 1403 struct e820entry *entry = &e820_saved.map[i];
> > 1404 resource_size_t start, end;
> > 1405
> > 1406 if (entry->type != E820_RAM)
> > 1407 continue;
> > 1408 start = entry->addr + entry->size;
> > 1409 end = round_up(start, ram_alignment(start));
> > 1410 if (start == end)
> > 1411 continue;
> > 1412 reserve_region_with_split(&iomem_resource, start,
> > 1413 end - 1, "RAM buffer");
> > 1414 }
> >
>
> OK, this seems more than a wee bit strange, to say the least. We
> shouldn't be reserving the entire address space; this is legitimate I/O
> space.
>
> However, the reservation suddenly being improper for the root resource
> would definitely make things unhappy...
Reverting the two e820 changes in 2.6.31-rc1,
5d423ccd7ba4285f1084e91b26805e1d0ae978ed and then
45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90,
but keeping the iomem_resource.end cap change, makes 2.6.31-rc1
work on my HIGHMEM64G machine.
Seems the e820 and the iomem_resource.end changes are Ok in
isolation but break when combined.
/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
