On Mon, Jun 29, 2009 at 01:12:05PM +0200, Mikael Pettersson wrote:
> 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.
With the e820 change reverted, what does /proc/iomem look like?
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
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
