lkml.org 
[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86
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


\
 
 \ /
  Last update: 2009-06-30 00:51    [W:0.075 / U:1.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site