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...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
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
