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<j...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
