Messages in this thread | | | Date | Sun, 28 Jun 2009 22:00:58 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86 |
| |
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.
| |