H. Peter Anvin wrote: > [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. always enable 64bit resource for 32bit too? YH -- 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
