Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Nov 2010 19:01:34 -0600
From:      Alan Cox <alc@rice.edu>
To:        John Baldwin <jhb@freebsd.org>
Cc:        alc@freebsd.org, freebsd-current@freebsd.org, Sean Bruno <seanbru@yahoo-inc.com>
Subject:   Re: 40 vs 44 bit memory addressing HP DL580/980
Message-ID:  <4CEB126E.2010509@rice.edu>
In-Reply-To: <201011221447.13026.jhb@freebsd.org>
References:  <1290387926.16558.1283.camel@home-yahoo> <201011220759.16082.jhb@freebsd.org> <AANLkTi=-t7TYM7ydtV_KktozsvUHv%2BA%2B=PvAjTn1mDq-@mail.gmail.com> <201011221447.13026.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/22/2010 1:47 PM, John Baldwin wrote:
> On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote:
>> On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin<jhb@freebsd.org>  wrote:
>>
>>> On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote:
>>>> Looks like these HP boxes have the capability to do 44 bit memory
>>>> addressing if configured to do so from the BIOS.
>>>>
>>>> Is anyone interested in any data from that setting?
>>> Does it boot ok? :)  The MTRR code should handle that (there is a CPUID
>>> field that tells the OS how many bits are significant).  Not sure if there
>>> are any places in the pmap that assume 40 bits, but a test boot is
>>> certainly
>>> worth trying.
>>>
>>>
>> Since we don't boot with 40-bit addressing, I can easily predict the
>> outcome.  :-)
>>
>> The trouble with this machine is that the second 128GB of RAM is being
>> placed between 512G and 1T in the physical address space, which is beyond
>> the range of the (current) direct map.  So, we take a page fault on the
>> first access to a page in the second 128GB through the direct map.
> Heh, I guess that is what your earlier patch did?  Once that patch is applied
> I think Sean should just try 44-bit mode if so.
>

Yes.

If 44-bit addressing makes the placement of DRAM in the physical address 
space any sparser, then we'll again have an insufficiently large direct 
map.  Also, I fear that we won't be able to allocate the vm_page_array 
without enabling VM_PHYSSEG_SPARSE, which itself requires a change in 
order to work.

Alan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CEB126E.2010509>