Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bitx86

[H. Peter Anvin]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/