lkml.org 
[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2009-06-29 07:07    [W:0.071 / U:3.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site