[BUG,2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86

Commit Message

Yinghai Lu June 29, 2009, 11:29 p.m. UTC

Yinghai Lu wrote:
> 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.

Mikael, can you try following patch on your system?

---
 arch/x86/kernel/e820.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

H. Peter Anvin June 30, 2009, 12:27 a.m. UTC | #1

Yinghai Lu wrote:
>  			continue;
> @@ -1409,8 +1409,10 @@ void __init e820_reserve_resources_late(
>  		end = round_up(start, ram_alignment(start));
>  		if (start == end)
>  			continue;
> -		reserve_region_with_split(&iomem_resource, start,
> -						  end - 1, "RAM buffer");
> +		if (end != (resource_size_t)end)
> +			continue;
> +		reserve_region_with_split(&iomem_resource, (resource_size_t)start,
> +					  (resource_size_t)(end - 1), "RAM buffer");
>  	}
>  }
>  

That doesn't quite look right; for one thing it doesn't handle the
(admittedly somewhat unlikely) case of end pointing to the end of the
address space.

Something like:

	if (start > (resource_size_t)end-1)
		continue;

... should work better.

	-hpa

Patch

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1400,8 +1400,8 @@  void __init e820_reserve_resources_late(
 	 * avoid stolen RAM:
 	 */
 	for (i = 0; i < e820.nr_map; i++) {
-		struct e820entry *entry = &e820_saved.map[i];
-		resource_size_t start, end;
+		struct e820entry *entry = &e820.map[i];
+		u64 start, end;
 
 		if (entry->type != E820_RAM)
 			continue;
@@ -1409,8 +1409,10 @@  void __init e820_reserve_resources_late(
 		end = round_up(start, ram_alignment(start));
 		if (start == end)
 			continue;
-		reserve_region_with_split(&iomem_resource, start,
-						  end - 1, "RAM buffer");
+		if (end != (resource_size_t)end)
+			continue;
+		reserve_region_with_split(&iomem_resource, (resource_size_t)start,
+					  (resource_size_t)(end - 1), "RAM buffer");
 	}
 }