Hi,
I have a Dell Optiplex GX280, a Pentium 4 with an Intel chipset. It has
4G of ram. The problem is I can only see 3.2G, even tho the bios reports
4G.
While using debian 2.6.16-2-686:
thomas@coke:~$ uname -a
Linux coke 2.6.16-2-686 #1 Sat Jul 15 21:59:21 UTC 2006 i686 GNU/Linux
thomas@coke:~$ grep MemTotal /proc/meminfo
MemTotal: 3375484 kB
This is expected as the standard debian kernels don't set
CONFIG_HIGHMEM64G. My understanding is that this needs to be set for the
full 4G to work on i386.
So I downloaded 2.6.18-rc3-git3 and 2.6.18-rc2-mm1 to give them a try. I
used the debian config as a starting point for oldconfig. Then from
menuconfig, "Processor type and featues" -> "High Memory Support" and
selected 64G. I then compiled both, rebooted and got these results:
2.6.18-rc2-mm1 reported MemTotal: 3376192 kB
2.6.18-rc3-git3 reported MemTotal: 3376236 kB
Is there anything I can do to make use of the 800M or so of ram that's
unused? Changing to amd64 or anything else that's sane or better does
not count ;-)
thomas@coke:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 4
cpu MHz : 2992.591
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pni monitor ds_cpl cid xtpr
bogomips : 5990.72
thomas@coke:~$ lspci
00:00.0 Host bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Express Memory Controller Hub (rev 04)
00:01.0 PCI bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Express PCI Express Root Port (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
thomas@coke:~$
Regards
--
Tom
(Please CC me as I'm off the list)
On Tue, 8 Aug 2006 09:24:29 +0100, Thomas Stewart wrote:
> I have a Dell Optiplex GX280, a Pentium 4 with an Intel chipset. It has
> 4G of ram. The problem is I can only see 3.2G, even tho the bios reports
> 4G.
>
> While using debian 2.6.16-2-686:
> thomas@coke:~$ uname -a
> Linux coke 2.6.16-2-686 #1 Sat Jul 15 21:59:21 UTC 2006 i686 GNU/Linux
> thomas@coke:~$ grep MemTotal /proc/meminfo
> MemTotal: 3375484 kB
>
> This is expected as the standard debian kernels don't set
> CONFIG_HIGHMEM64G. My understanding is that this needs to be set for the
> full 4G to work on i386.
>
> So I downloaded 2.6.18-rc3-git3 and 2.6.18-rc2-mm1 to give them a try. I
> used the debian config as a starting point for oldconfig. Then from
> menuconfig, "Processor type and featues" -> "High Memory Support" and
> selected 64G. I then compiled both, rebooted and got these results:
>
> 2.6.18-rc2-mm1 reported MemTotal: 3376192 kB
> 2.6.18-rc3-git3 reported MemTotal: 3376236 kB
Most likely the BIOS is reserving large parts of the [0,4GB[ range for
PCI devices and some for itself. Please post the E820 memory map the
kernel prints near the start of the boot sequence on your machine.
> Is there anything I can do to make use of the 800M or so of ram that's
> unused? Changing to amd64 or anything else that's sane or better does
> not count ;-)
You need a chipset+BIOS that can relocate RAM to above the 4GB boundary.
I don't know how common those are in the 32-bit x86 world.
On Tue, Aug 08, 2006 at 11:13:00AM +0200, Mikael Pettersson wrote:
> Most likely the BIOS is reserving large parts of the [0,4GB[ range for
> PCI devices and some for itself. Please post the E820 memory map the
> kernel prints near the start of the boot sequence on your machine.
Linux version 2.6.16-2-686 (Debian 2.6.16-17) ([email protected]) (gcc version 4.6BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cfe86c00 (usable)
BIOS-e820: 00000000cfe86c00 - 00000000cfe88c00 (ACPI NVS)
BIOS-e820: 00000000cfe88c00 - 00000000cfe8ac00 (ACPI data)
BIOS-e820: 00000000cfe8ac00 - 00000000d0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
2174MB HIGHMEM available.
1152MB LOWMEM available.
Linux version 2.6.18-rc3-git3-ts1 (root@coke) (gcc version 4.0.4 20060507 (prer6BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cfe86c00 (usable)
BIOS-e820: 00000000cfe86c00 - 00000000cfe88c00 (ACPI NVS)
BIOS-e820: 00000000cfe88c00 - 00000000cfe8ac00 (ACPI data)
BIOS-e820: 00000000cfe8ac00 - 00000000d0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
2430MB HIGHMEM available.
896MB LOWMEM available.
Linux version 2.6.18-rc2-mm1-ts1 (root@coke) (gcc version 4.0.4 20060507 (prere6BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 00000000000a0000 end: 000000000001copy_e820_map() type is E820_RAM
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 000000000012copy_e820_map() start: 0000000000100000 size: 00000000cfd86c00 end: 00000000cfe1copy_e820_map() type is E820_RAM
copy_e820_map() start: 00000000cfe86c00 size: 0000000000002000 end: 00000000cfe4copy_e820_map() start: 00000000cfe88c00 size: 0000000000002000 end: 00000000cfe3copy_e820_map() start: 00000000cfe8ac00 size: 0000000000175400 end: 00000000d002copy_e820_map() start: 00000000e0000000 size: 0000000010000000 end: 00000000f002copy_e820_map() start: 00000000fec00000 size: 0000000000100400 end: 00000000fed2copy_e820_map() start: 00000000fed20000 size: 0000000000080000 end: 00000000fed2copy_e820_map() start: 00000000fee00000 size: 0000000000100000 end: 00000000fef2copy_e820_map() start: 00000000ffb00000 size: 0000000000500000 end: 000000010002 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cfe86c00 (usable)
BIOS-e820: 00000000cfe86c00 - 00000000cfe88c00 (ACPI NVS)
BIOS-e820: 00000000cfe88c00 - 00000000cfe8ac00 (ACPI data)
BIOS-e820: 00000000cfe8ac00 - 00000000d0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
2430MB HIGHMEM available.
896MB LOWMEM available.
Regards
--
Tom
Replying to Thomas Stewart:
> Hi,
> I have a Dell Optiplex GX280, a Pentium 4 with an Intel chipset. It has
> 4G of ram. The problem is I can only see 3.2G, even tho the bios reports
> 4G.
Chipset issue. Some Intel chipsets are doing strange things with memory
map. They call this "design flaw" but not offered free replacements
yet, so, for example, on SE7221BK1E you can't use more than 3 gigs.
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
Thomas Stewart wrote:
> Hi,
> I have a Dell Optiplex GX280, a Pentium 4 with an Intel chipset. It has
> 4G of ram. The problem is I can only see 3.2G, even tho the bios reports
> 4G.
There was a thread on this subject a little while ago. Essentially it is
a chipset limitation (i.e. lack of support for memory hole remapping,
memory hoisting, whatever you want to call it) and there's nothing that
can really be done about it. Even a 64-bit kernel will have the same
problem.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
> Replying to Thomas Stewart:
> > Hi,
> > I have a Dell Optiplex GX280, a Pentium 4 with an Intel chipset. It has
> > 4G of ram. The problem is I can only see 3.2G, even tho the bios reports
> > 4G.
> Chipset issue. Some Intel chipsets are doing strange things with memory
> map. They call this "design flaw" but not offered free replacements
> yet, so, for example, on SE7221BK1E you can't use more than 3 gigs.
It is quite funny to read Intel's technical note on this, as they try to
make it seem like they're blaming the operating system. For example:
When the Intel E7221 chipset is populated to its maximum memory capacity of
4 GB (Giga Bytes), the Operating System (OS) may report a significantly
lower amount of available memory.
Yeah, that stupid operating system.
These requirements may reduce the addressable memory space available to and
reported by the Operating System. These memory ranges, while unavailable to
the OS, are still being utilized by subsystems such as I/O, PCI Express and
Integrated Graphics and are critical to the proper functioning of the
server.
Use of Available memory below 4 GB by system resources is not specific to
Intel chipsets, but rather a limitation of existing PC architectures and
current limitations of some 32-bit operating systems. Some 32-bit operating
systems may not be capable of recognizing greater than 2 GB of memory. This
issue potentially impacts any chipset with 4GB maximum memory configuration.
Intel has addressed this from a hardware perspective in future platforms,
anticipating that future Operating Systems will provide greater than 4 GB of
memory support.
Last but not least, their solution.
Corrective Action / Resolution
Intel Server Board SE7221BK1-E system BIOS will be updated to properly
indicate the following information screens augment memory configuration
characteristics for the Intel Server Board SE7221BK1-E and Intel Server
Platform SR1425BK1-E customers.
Total physical memory populated in the system
Total memory dedicated to motherboard resources
Total memory reported as available to the operating system
This information will align to the INT15h E820h standard that BIOS uses to
communicate memory usage to the operating system. This BIOS feature will
clarify the memory subsystem support and usage for the end user.
Are these technical notes supposed to be so funny?
DS
On 8/8/06, David Schwartz <[email protected]> wrote:
>
> > Replying to Thomas Stewart:
>
> > > Hi,
> > > I have a Dell Optiplex GX280, a Pentium 4 with an Intel chipset. It has
> > > 4G of ram. The problem is I can only see 3.2G, even tho the bios reports
> > > 4G.
>
> > Chipset issue. Some Intel chipsets are doing strange things with memory
> > map. They call this "design flaw" but not offered free replacements
> > yet, so, for example, on SE7221BK1E you can't use more than 3 gigs.
>
> It is quite funny to read Intel's technical note on this, as they try to
> make it seem like they're blaming the operating system. For example:
>
> When the Intel E7221 chipset is populated to its maximum memory capacity of
> 4 GB (Giga Bytes), the Operating System (OS) may report a significantly
> lower amount of available memory.
>
> Yeah, that stupid operating system.
>
> These requirements may reduce the addressable memory space available to and
> reported by the Operating System. These memory ranges, while unavailable to
> the OS, are still being utilized by subsystems such as I/O, PCI Express and
> Integrated Graphics and are critical to the proper functioning of the
> server.
>
> Use of Available memory below 4 GB by system resources is not specific to
> Intel chipsets, but rather a limitation of existing PC architectures and
> current limitations of some 32-bit operating systems. Some 32-bit operating
> systems may not be capable of recognizing greater than 2 GB of memory. This
> issue potentially impacts any chipset with 4GB maximum memory configuration.
>
> Intel has addressed this from a hardware perspective in future platforms,
> anticipating that future Operating Systems will provide greater than 4 GB of
> memory support.
>
> Last but not least, their solution.
>
> Corrective Action / Resolution
> Intel Server Board SE7221BK1-E system BIOS will be updated to properly
> indicate the following information screens augment memory configuration
> characteristics for the Intel Server Board SE7221BK1-E and Intel Server
> Platform SR1425BK1-E customers.
> Total physical memory populated in the system
> Total memory dedicated to motherboard resources
> Total memory reported as available to the operating system
> This information will align to the INT15h E820h standard that BIOS uses to
> communicate memory usage to the operating system. This BIOS feature will
> clarify the memory subsystem support and usage for the end user.
>
> Are these technical notes supposed to be so funny?
>
> DS
I guess this is all related to older Intel chipsets, right? I mean the
chipset *75X something I'm going to have in the new box I will get
soonish will support up to 8 GiB. I hope it does not mean that it will
be capped at 7.4GiB although I will only have 4GiB installed for now.
On Wed, 9 Aug 2006 08:51:41 +0200
"gmu 2k6" <[email protected]> wrote:
> > Are these technical notes supposed to be so funny?
> >
> > DS
>
> I guess this is all related to older Intel chipsets, right? I mean the
> chipset *75X something I'm going to have in the new box I will get
> soonish will support up to 8 GiB. I hope it does not mean that it will
> be capped at 7.4GiB although I will only have 4GiB installed for now.
most modern 64 bit x86 systems will relocate this memory hole to somewhere else within the address space (memory hoisting)... You'll probably find the it reappers the first time you buy a system with 1TB of ram...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 8/9/06, Joel Jaeggli <[email protected]> wrote:
> On Wed, 9 Aug 2006 08:51:41 +0200
> "gmu 2k6" <[email protected]> wrote:
>
> > > Are these technical notes supposed to be so funny?
> > >
> > > DS
> >
> > I guess this is all related to older Intel chipsets, right? I mean the
> > chipset *75X something I'm going to have in the new box I will get
> > soonish will support up to 8 GiB. I hope it does not mean that it will
> > be capped at 7.4GiB although I will only have 4GiB installed for now.
>
> most modern 64 bit x86 systems will relocate this memory hole to somewhere else within the address space (memory hoisting)... You'll probably find the it reappers the first time you buy a system with 1TB of ram...
so what does it mean that one of Xeons here shows me the full 4GiB as
total physical memory via `free`?
btw, the box I'm getting will have the 975X chip and include 4GiB RAM
and if I understood the problem correctly even with 3GiB there will be
some memory lost to mapping-issues besides the HI/LO mem
kernel-reserving issue.
this is what I get on ia32 P4 with 3GiB
total used free shared buffers cached
Mem: 3116108 2608196 507912 0 246652 2039708
and this is what I get on ia32 Xeon with 4GiB
total used free shared buffers cached
Mem: 4087660 268828 3818832 0 57168 103568
Hi,
I tried Dell support, but it was unhelpful. I also upgraded the bios to
the latest revision, but that changed nothing. I think I'll just have to
live with it.
Thanks for the comments.
--
Tom
gmu 2k6 wrote:
...
> so what does it mean that one of Xeons here shows me the full 4GiB as
> total physical memory via `free`?
>
> btw, the box I'm getting will have the 975X chip and include 4GiB RAM
> and if I understood the problem correctly even with 3GiB there will be
> some memory lost to mapping-issues besides the HI/LO mem
> kernel-reserving issue.
> this is what I get on ia32 P4 with 3GiB
> total used free shared buffers cached
> Mem: 3116108 2608196 507912 0 246652 2039708
> and this is what I get on ia32 Xeon with 4GiB
> total used free shared buffers cached
> Mem: 4087660 268828 3818832 0 57168 103568
Hi Gmu,
This is a bit divergent from the discussion, but will hopefully provide some
background.
The hardware my employer manufactures asks the BIOS to reserve several
largeish ranges (16M and 16M to 512M), and it's been used in various HPC
projects where machines typically have a lot of memory installed.
From my experience, most pre 750x-P4-Xeon chipsets did not support any kind
of memory remapping, so often the top 0.5-1.5G of ram would be 'lost'. Great
fun.
Since then, this functionality has started appearing, more or less randomly.
I believe it should be present on all later 75xx chipsets (probably the Core
2 Xeon chipsets as well), but implementation depends on the BIOS (ie the
motherboard vendors), and their grasp of what people do with their boards is
often quite limited.
On the P4 boards (and again the Core 2 boards as well), this is probably
even less ordered as they are 'desktop' boards rather than the more costly
'server' boards.
I'm pretty sure the Athlon64 and Opteron CPUs should support this, but they
too depend on BIOS functionality to rearrange the memory tables.
Just out of interest - what chipset does your Xeon system use?
Yours,
-S
--
Simen Thoresen, Dolphin ICS
On 8/10/06, Simen Thoresen <[email protected]> wrote:
> gmu 2k6 wrote:
> ...
> > so what does it mean that one of Xeons here shows me the full 4GiB as
> > total physical memory via `free`?
> >
> > btw, the box I'm getting will have the 975X chip and include 4GiB RAM
> > and if I understood the problem correctly even with 3GiB there will be
> > some memory lost to mapping-issues besides the HI/LO mem
> > kernel-reserving issue.
> > this is what I get on ia32 P4 with 3GiB
> > total used free shared buffers cached
> > Mem: 3116108 2608196 507912 0 246652 2039708
> > and this is what I get on ia32 Xeon with 4GiB
> > total used free shared buffers cached
> > Mem: 4087660 268828 3818832 0 57168 103568
>
> Hi Gmu,
>
> This is a bit divergent from the discussion, but will hopefully provide some
> background.
>
> The hardware my employer manufactures asks the BIOS to reserve several
> largeish ranges (16M and 16M to 512M), and it's been used in various HPC
> projects where machines typically have a lot of memory installed.
>
> From my experience, most pre 750x-P4-Xeon chipsets did not support any kind
> of memory remapping, so often the top 0.5-1.5G of ram would be 'lost'. Great
> fun.
> Since then, this functionality has started appearing, more or less randomly.
> I believe it should be present on all later 75xx chipsets (probably the Core
> 2 Xeon chipsets as well), but implementation depends on the BIOS (ie the
> motherboard vendors), and their grasp of what people do with their boards is
> often quite limited.
>
> On the P4 boards (and again the Core 2 boards as well), this is probably
> even less ordered as they are 'desktop' boards rather than the more costly
> 'server' boards.
>
> I'm pretty sure the Athlon64 and Opteron CPUs should support this, but they
> too depend on BIOS functionality to rearrange the memory tables.
>
> Just out of interest - what chipset does your Xeon system use?
lspci of the P4 32bit desktop with 3GiB
00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller
Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP
Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
UHCI Controller #1 (rev 02)
lspci of the Xeon 32bit HP Proliant Server with 4GiB:
00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c)
00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express
Port A (rev 0c)
00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
UHCI Controller #1 (rev 02)
lspci of the new box with 975X and Core 2 Duo not available yet for
obvious reasons (I don't have the the box yet).
gmu 2k6 wrote:
> On 8/10/06, Simen Thoresen <[email protected]> wrote:
>> gmu 2k6 wrote:
>> ...
>> > so what does it mean that one of Xeons here shows me the full 4GiB as
>> > total physical memory via `free`?
>> >
>> Just out of interest - what chipset does your Xeon system use?
>
> lspci of the P4 32bit desktop with 3GiB
> 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller
> Hub (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP
> Controller (rev 02)
> 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
> UHCI Controller #1 (rev 02)
>
> lspci of the Xeon 32bit HP Proliant Server with 4GiB:
> 00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c)
> 00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express
> Port A (rev 0c)
> 00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c)
> 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
> UHCI Controller #1 (rev 02)
We know the E7520 is able to do the remapping, provided the BIOS does not
mess it up. I have no idea about the E7210 (or the 875P - I was not aware
that they were this closely related), but without checking any docs I'm
assuming a 4G memory ceiling and no remapping capability.
Thank you.
> lspci of the new box with 975X and Core 2 Duo not available yet for
> obvious reasons (I don't have the the box yet).
I'd appreciate if you could send me both lspci and /proc/iomem output when
you get one of these with 4G or more ram installed. Off list, please.
Yours,
-S
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Simen Thoresen, Dolphin ICS