[Add Cc: Yinghai] Mikael Pettersson wrote: > > > > > > > > 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... > > > > > > Reverting the two e820 changes in 2.6.31-rc1, > > > 5d423ccd7ba4285f1084e91b26805e1d0ae978ed and then > > > 45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90, > > > but keeping the iomem_resource.end cap change, makes 2.6.31-rc1 > > > work on my HIGHMEM64G machine. > > > > > > Seems the e820 and the iomem_resource.end changes are Ok in > > > isolation but break when combined. > > > > With the e820 change reverted, what does /proc/iomem look like? > OK. This is starting to make sense. I suspect this is a similar issue as 3b0fde0fac19c180317eb0601b3504083f4b9bf5 addresses, which is that the e820 code assumes -- and I don't see any exception to that in 45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90 -- that iomem_resource covers the entire 64-bit address space that e820 knows. I wonder what happens with "interestingly shaped" memory above 4 GB if resource_size_t is 32 bits with that code. In terms of address space assignment, an alternate implementation of the address space cap is to mark it reserved; that would unfortunately result in an ugly turd at the end of /proc/iomem, but that can be addressed if need be, too. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
