linux-kernel - Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A484A8A.9020704@zytor.com>
Date:	Sun, 28 Jun 2009 22:00:58 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Grant Grundler <grundler@...isc-linux.org>
CC:	Mikael Pettersson <mikpe@...uu.se>, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/