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
| ||
|
Date: Sun, 28 Jun 2009 20:29:11 -0600 From: Grant Grundler <grundler@...isc-linux.org> To: Mikael Pettersson <mikpe@...uu.se> Cc: "H. Peter Anvin" <hpa@...or.com>, 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 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 } hth, grant -- 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/
Powered by blists - more mailing lists