linux-kernel - Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47473AA8.2050908@rtr.ca>
Date:	Fri, 23 Nov 2007 15:40:08 -0500
From:	Mark Lord <lkml@....ca>
To:	"Morrison, Tom" <tmorrison@...irix.com>
Cc:	Mark Lord <liml@....ca>, Robert Hancock <hancockr@...w.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	ide <linux-ide@...r.kernel.org>, Jeff Garzik <jeff@...zik.org>,
	Tejun Heo <htejun@...il.com>
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

Mark wrote:
> Yeah, I kind of had your reports in mind when I asked that.  :)
> 
> On a related note, I now have lots of Marvell (sata_mv) hardware here,
> and an Intel CPU/chipset box with physical RAM above the 4GB boundary.

Morrison, Tom wrote:
> Yes, I believe that - otherwise, this problem would have
> been a crisis a LONG time ago...:-)
>  
> But I do have some more questions in relationship to how 
> things are mapped in your environment. I have a flat memory 
> map (i.e.: the full 0x0 -- 0x1_0000_0000 is passed to the 32bit 
> Linux kernel without any 'holes' and/or reserved areas).
>  
> Does your Intel memory map have this same type of flat memory 
> model (and thus allow use of the FULL lower 4Gig) - or does it 
> reserve areas of lower 4Gig for devices and such - if not - where 
> are these reserved areas - and how do the relate to the I/O memory
> map for the device?
>  
> In other words, I would be very interested in seeing the memory 
> map & the PCI memory mapping to see if any overlap/correspond 
> to reserve areas of lower 4 Gig (in a linux 32bit mode)...
...

I believe that only 2GB or so of the 4GB RAM appears below the 4GB boundary.
The rest is accessed above 4GB, using Intel's 36-bit PAE functionality.

I think what you want to see is /proc/mtrr, annotated below by me:

reg00: base=0x080000000 (2048MB), size=2048MB: uncachable, count=1  I/O space
reg01: base=0x000000000 (   0MB), size=4096MB: write-back, count=1  first 2GB of RAM + I/O space
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1  third GB of RAM
reg03: base=0x140000000 (5120MB), size= 512MB: write-back, count=1  portion of 4th GB of RAM
reg04: base=0x160000000 (5632MB), size= 256MB: write-back, count=1  portion of 4th GB of RAM
reg05: base=0x170000000 (5888MB), size= 128MB: write-back, count=1  portion of 4th GB of RAM
reg06: base=0x178000000 (6016MB), size=  64MB: write-back, count=1  portion of 4th GB of RAM
reg07: base=0x0af800000 (2808MB), size=   8MB: uncachable, count=1  (?) dunno

>From that, the visible RAM should be 2048 + 1024 + 512 + 256 + 128 + 64 = 3968MB.
In /proc/meminfo, it reports MemTotal of 4067260kB, which divided by 1024 gives 3971MB.

The BIOS reports 4024MB.

But the MTRR values above do make it rather clear that nearly half the RAM
requires 33-bit physical addressing for access.

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/