4GB memory and Intel Dual-Core system

4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi guys,

I installed 4 x 1 GB DDR2 memory in my Intel Dual-Core 2.80GHz system,
but it shows me only 3.3 GB of RAM:

Memory: 3339124k/3398656k available (2029k kernel code, 56232k reserved,
741k data, 184k init)

The BIOS and dmidecode tells me that I have 4 GB of RAM installed and I
don't have any idea where to look for details. What information do you
need to analyze this?

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Roland Dreier]

    Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
    Marcel> installed and I don't have any idea where to look for
    Marcel> details. What information do you need to analyze this?

Look at the e820 dump in your kernel bootlog.  I'll bet you'll see a
big chunk of reserved address space.  Do you have any PCI devices like
video cards that use a lot of PCI address space?

I don't know if EM64T systems (or whatever the right term is) have a
way of remapping some RAM above 4 GB so that you can use all your
memory in a case like this.

 - R.

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Roland,

>     Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
>     Marcel> installed and I don't have any idea where to look for
>     Marcel> details. What information do you need to analyze this?
> 
> Look at the e820 dump in your kernel bootlog.  I'll bet you'll see a
> big chunk of reserved address space.  Do you have any PCI devices like
> video cards that use a lot of PCI address space?

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
 BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
 BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
 BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
 BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
 BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
 BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)

I see the stuff above, but the system doesn't contain any PCI device. I
didn't install a PCI-Express video card, because I still use the onboard
card.

> I don't know if EM64T systems (or whatever the right term is) have a
> way of remapping some RAM above 4 GB so that you can use all your
> memory in a case like this.

The kernel is compiled for x86_64 and the term EM64T is correct. The
important question is now how do I remap that memory. Loosing almost a
full GB of memory wasn't my plan when upgrading to 4 GB.

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Thu, 27 Oct 2005 13:44:19 -0700, Roland Dreier wrote
> Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
>     Marcel> installed and I don't have any idea where to look for
>     Marcel> details. What information do you need to analyze this?
> 
> Look at the e820 dump in your kernel bootlog.  I'll bet you'll see a
> big chunk of reserved address space.  Do you have any PCI devices 
> like video cards that use a lot of PCI address space?
> 
> I don't know if EM64T systems (or whatever the right term is) have a
> way of remapping some RAM above 4 GB so that you can use all your
> memory in a case like this.

I think this always shows this amount of RAM. Windows does the same thing
AFAIK. It's basically some sort of limitation and the motherboard reports an
specific amount of memory.

There is a deeper reason, ask google.

(IA32 does not support all that much RAM, so it shows like 3.xxGB RAM but uses
the rest for System Resources like Video, PCI, bla bla)

EM64T is not really 64Bit so, is still IA32.

.Alejandro

Re: 4GB memory and Intel Dual-Core system

[Roland Dreier]

    > BIOS-provided physical RAM map:
    >  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
    >  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
    >  BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
    >  BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
    >  BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
    >  BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
    >  BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
    >  BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
    >  BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
    >  BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)

If that's the full e820 map, then I guess the question is why did the
BIOS not tell you about any memory above 0xcf700000?

And I have no idea why it wouldn't.  For comparison, here's an AMD64
system I have with 4 GB of RAM.  Notice how it put a big chunk of RAM
above 4G:

 BIOS-e820: 0000000000000000 - 0000000000098800 (usable)
 BIOS-e820: 0000000000098800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000c2000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000bff20000 (usable)
 BIOS-e820: 00000000bff20000 - 00000000bff2a000 (ACPI data)
 BIOS-e820: 00000000bff2a000 - 00000000bff80000 (ACPI NVS)
 BIOS-e820: 00000000bff80000 - 00000000c0000000 (reserved)
 BIOS-e820: 00000000d8800000 - 00000000d8800400 (reserved)
 BIOS-e820: 00000000d8801000 - 00000000d8801400 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

 - R.

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Alejandro,

> > Look at the e820 dump in your kernel bootlog.  I'll bet you'll see a
> > big chunk of reserved address space.  Do you have any PCI devices 
> > like video cards that use a lot of PCI address space?
> > 
> > I don't know if EM64T systems (or whatever the right term is) have a
> > way of remapping some RAM above 4 GB so that you can use all your
> > memory in a case like this.
> 
> I think this always shows this amount of RAM. Windows does the same thing
> AFAIK. It's basically some sort of limitation and the motherboard reports an
> specific amount of memory.
> 
> There is a deeper reason, ask google.
> 
> (IA32 does not support all that much RAM, so it shows like 3.xxGB RAM but uses
> the rest for System Resources like Video, PCI, bla bla)
> 
> EM64T is not really 64Bit so, is still IA32.

the board in this system is a Intel D945GNT and the box tells me the
maximum supported amount of RAM is 4 GB. So there should be a way to
address this amount memory.

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Thu, 27 Oct 2005 22:51:18 +0200, Marcel Holtmann wrote
> Hi Roland,
> 
> >     Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
> >     Marcel> installed and I don't have any idea where to look for
> >     Marcel> details. What information do you need to analyze this?

.....

> 
> The kernel is compiled for x86_64 and the term EM64T is correct. The
> important question is now how do I remap that memory. Loosing almost 
> a full GB of memory wasn't my plan when upgrading to 4 GB.

This is pretty much how it works. Else, purchase an Itanium system. ;-)

EM64T != IA64

.Alejandro

> 
> Regards
> 
> Marcel

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Hi Roland,

>     > BIOS-provided physical RAM map:
>     >  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
>     >  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
>     >  BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
>     >  BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
>     >  BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
>     >  BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
>     >  BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
>     >  BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
>     >  BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
>     >  BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
> 
> If that's the full e820 map, then I guess the question is why did the
> BIOS not tell you about any memory above 0xcf700000?

yes, that's it. Attached is the full dmesg of the last boot.

Regards

Marcel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain; name=dmesg.txt; charset=utf-8, Size: 18097 bytes --]

Bootdata ok (command line is root=/dev/sda3 ro quiet)
Linux version 2.6.14-rc5 (holtmann@blade) (gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)) #2 SMP Thu Oct 27 20:53:15 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
 BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
 BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
 BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
 BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
 BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
 BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
ACPI: RSDP (v000 INTEL                                 ) @ 0x00000000000fe020
ACPI: RSDT (v001 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x00000000cf6fde48
ACPI: FADT (v001 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x00000000cf6fcf10
ACPI: MADT (v001 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x00000000cf6fce10
ACPI: WDDT (v001 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x00000000cf6f7f90
ACPI: MCFG (v001 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x00000000cf6f7f10
ACPI: ASF! (v032 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x00000000cf6fcd10
ACPI: DSDT (v001 INTEL  D945GNT  0x00000412 MSFT 0x01000013) @ 0x0000000000000000
On node 0 totalpages: 848946
  DMA zone: 3999 pages, LIFO batch:1
  Normal zone: 844947 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:1
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at d0000000 (gap: cf700000:30900000)
Checking aperture...
Built 1 zonelists
Kernel command line: root=/dev/sda3 ro quiet
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz PM timer.
time.c: Detected 2800.236 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 3339124k/3398656k available (2029k kernel code, 56232k reserved, 741k data, 184k init)
Calibrating delay using timer specific routine.. 5609.32 BogoMIPS (lpj=11218649)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM1)
mtrr: v2.0 (20020519)
Using local APIC timer interrupts.
Detected 12.500 MHz APIC timer.
softlockup thread 0 started up.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 5600.64 BogoMIPS (lpj=11201286)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU1: Thermal monitoring enabled (TM1)
              Intel(R) Pentium(R) D CPU 2.80GHz stepping 04
APIC error on CPU1: 00(40)
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -7 cycles, maxerr 1449 cycles)
Brought up 2 CPUs
softlockup thread 1 started up.
time.c: Using PIT/TSC based timekeeping.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
PCI: Using MMCONFIG at f0000000
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:00:02.0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 *10 11 12)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 10 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI-DMA: Disabling IOMMU.
pnp: 00:05: ioport range 0x500-0x53f has been reserved
pnp: 00:05: ioport range 0x400-0x47f could not be reserved
pnp: 00:05: ioport range 0x680-0x6ff has been reserved
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: e0200000-e02fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.2
  IO window: disabled.
  MEM window: e0300000-e03fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.3
  IO window: disabled.
  MEM window: e0400000-e04fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: 1000-1fff
  MEM window: e0000000-e00fffff
  PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1c.2 to 64
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1c.3 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Initializing Cryptographic API
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
Allocate Port Service[pcie03]
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
Allocate Port Service[pcie03]
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
Allocate Port Service[pcie03]
vga16fb: initializing
vga16fb: mapped to 0xffff8100000a0000
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: CPU0 (power states: C1[C1])
ACPI: CPU1 (power states: C1[C1])
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
io scheduler noop registered
io scheduler cfq registered
libata version 1.12 loaded.
ata_piix version 1.04
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x20C8 ctl 0x20EE bmdma 0x20A0 irq 185
ata2: SATA max UDMA/133 cmd 0x20C0 ctl 0x20EA bmdma 0x20A8 irq 185
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata1: dev 0 ATA, max UDMA7, 390721968 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ATA: abnormal status 0x7F on port 0x20C7
ata2: disabling port
scsi1 : ata_piix
  Vendor: ATA       Model: SAMSUNG SP2004C   Rev: VM10
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
mice: PS/2 mouse device common for all mice
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.39
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
ReiserFS: sda3: found reiserfs format "3.6" with standard journal
input: AT Translated Set 2 keyboard on isa0060/serio0
ReiserFS: sda3: using ordered data mode
ReiserFS: sda3: journal params: device sda3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda3: checking transaction log (sda3)
ReiserFS: sda3: replayed 37 transactions in 1 seconds
ReiserFS: sda3: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 184k freed
NET: Registered protocol family 1
Adding 3903784k swap on /dev/sda2.  Priority:-1 extents:1 across:3903784k
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
device-mapper: dm-linear: Device lookup failed
device-mapper: error adding target to table
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: sda6: found reiserfs format "3.6" with standard journal
ReiserFS: sda6: using ordered data mode
ReiserFS: sda6: journal params: device sda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda6: checking transaction log (sda6)
ReiserFS: sda6: Using r5 hash to sort names
ReiserFS: sda5: found reiserfs format "3.6" with standard journal
ReiserFS: sda5: using ordered data mode
ReiserFS: sda5: journal params: device sda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda5: checking transaction log (sda5)
ReiserFS: sda5: Using r5 hash to sort names
ReiserFS: sda7: found reiserfs format "3.6" with standard journal
ReiserFS: sda7: using ordered data mode
ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda7: checking transaction log (sda7)
ReiserFS: sda7: Using r5 hash to sort names
agpgart: Detected an Intel 945G Chipset.
agpgart: Detected 7932K stolen memory.
agpgart: AGP aperture is 256M @ 0xd0000000
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 225
PCI: Setting latency timer of device 0000:00:1b.0 to 64
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 233
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 233, io base 0x00002080
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 185, io base 0x00002060
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 177, io base 0x00002040
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 50
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.3: irq 50, io base 0x00002020
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-1: new low speed USB device using uhci_hcd and address 2
usbcore: registered new driver hiddev
input: USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse Optical®] on usb-0000:00:1d.0-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 233
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: irq 233, io mem 0xe01c4000
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
hw_random hardware driver 1.0.0 loaded
usb 1-1: USB disconnect, address 2
e100: Intel(R) PRO/100 Network Driver, 3.4.14-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 20 (level, low) -> IRQ 58
e100: eth0: e100_probe: addr 0xe0000000, irq 58, MAC addr 00:13:20:64:F4:C5
usb 1-1: new low speed USB device using uhci_hcd and address 3
input: USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse Optical®] on usb-0000:00:1d.0-1
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
NET: Registered protocol family 10
Disabled Privacy Extensions on device ffffffff80378d00(lo)
IPv6 over IPv4 tunneling driver
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 50
[drm] Initialized i915 1.1.0 20040405 on minor 0: 
mtrr: base(0xd0020000) is not aligned on a size(0x400000) boundary
eth0: no IPv6 routers present
NET: Registered protocol family 17
device eth0 entered promiscuous mode
device eth0 left promiscuous mode
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.7
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.5
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Thu, 27 Oct 2005 22:57:47 +0200, Marcel Holtmann wrote
> Hi Alejandro,
> 
> the board in this system is a Intel D945GNT and the box tells me the
> maximum supported amount of RAM is 4 GB. So there should be a way to
> address this amount memory.

Marcel,

The board did take the 4GB of RAM and it is finding them, therefore supports
them. It is just not designed to give a full 4GB of RAM to the system, it only
gives 3.4XGB RAM and the rest is really not used, then basically the system
just tries to give the 0.6xGB RAM remaining a task by it being used by "System
Resources"

This isn't really Linux dependant.

.Alejandro

> 
> Regards
> 
> Marcel

Re: 4GB memory and Intel Dual-Core system

[Roland Dreier]

    Marcel> yes, that's it.

OK, I've exhausted my ideas.  I guess you could always try contacting
the vendor....

 - R.

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Alejandro,

> > the board in this system is a Intel D945GNT and the box tells me the
> > maximum supported amount of RAM is 4 GB. So there should be a way to
> > address this amount memory.
> 
> The board did take the 4GB of RAM and it is finding them, therefore supports
> them. It is just not designed to give a full 4GB of RAM to the system, it only
> gives 3.4XGB RAM and the rest is really not used, then basically the system
> just tries to give the 0.6xGB RAM remaining a task by it being used by "System
> Resources"
> 
> This isn't really Linux dependant.

so there is no way to give me back the "lost" memory. Is it possible
that another motherboard might help?

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Roland,

>     Marcel> yes, that's it.
> 
> OK, I've exhausted my ideas.  I guess you could always try contacting
> the vendor....

guess what, this is the CPU and board that I won at the OLS this year ;)

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[linux-os (Dick Johnson)]

On Thu, 27 Oct 2005, Marcel Holtmann wrote:

> Hi guys,
>
> I installed 4 x 1 GB DDR2 memory in my Intel Dual-Core 2.80GHz system,
> but it shows me only 3.3 GB of RAM:
>
> Memory: 3339124k/3398656k available (2029k kernel code, 56232k reserved,
> 741k data, 184k init)
>
> The BIOS and dmidecode tells me that I have 4 GB of RAM installed and I
> don't have any idea where to look for details. What information do you
> need to analyze this?
>
> Regards
>
> Marcel

Hmmm. Do you have a screen card? Trick question. It takes address-
space. How about stuff on the PCI bus? That takes address-space
also. If you look at the boot log, you will probably find that
there is a lot of "reserved" address-space. Since RAM needs
to "share" such address-space, any RAM behind the reserved addresses
will not be accessed.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

Let's see if I can backup my comments.

http://support.intel.com/support/motherboards/server/sb/cs-010458.htm

Hope it clarifies,

.Alejandro

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
> Hi Alejandro,
> 
> > > the board in this system is a Intel D945GNT and the box tells me the
> > > maximum supported amount of RAM is 4 GB. So there should be a way to
> > > address this amount memory.
> > 
> > The board did take the 4GB of RAM and it is finding them, therefore supports
> > them. It is just not designed to give a full 4GB of RAM to the system, it only
> > gives 3.4XGB RAM and the rest is really not used, then basically the system
> > just tries to give the 0.6xGB RAM remaining a task by it being used by "System
> > Resources"
> > 
> > This isn't really Linux dependant.
> 
> so there is no way to give me back the "lost" memory. Is it possible
> that another motherboard might help?

AFAIK, No. AMD and Intel will always do the same thing until we all move to
real IA64.

Unless there is some sort of kernel hack that will do some crazy thing to give
you the power there.

But hey, look at it this way, if you remove 1GB, you will lose the Dual
Channel capability.

.Alejandro

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Alejandro,

> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
> 
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
> 
> Unless there is some sort of kernel hack that will do some crazy thing to give
> you the power there.

do you think that activating NUMA emulation might help?

> But hey, look at it this way, if you remove 1GB, you will lose the Dual
> Channel capability.

I could have bought two 512 MB modules ;)

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Bernd Eckenfels]

In article <1130445194.5416.3.camel@blade> you wrote:
> I installed 4 x 1 GB DDR2 memory in my Intel Dual-Core 2.80GHz system,
> but it shows me only 3.3 GB of RAM:

What Vendor?

Try a BIOS update, some recent BIOSes support remapping, others dont. Look
in BIOS for remapping settings and also try to change the Video mapping
hole.

Gruss
Bernd

Re: 4GB memory and Intel Dual-Core system

[Dave Jones]

On Thu, Oct 27, 2005 at 05:15:50PM -0400, Alejandro Bonilla wrote:
 > On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
 > > Hi Alejandro,
 > > 
 > > > > the board in this system is a Intel D945GNT and the box tells me the
 > > > > maximum supported amount of RAM is 4 GB. So there should be a way to
 > > > > address this amount memory.
 > > > 
 > > > The board did take the 4GB of RAM and it is finding them, therefore supports
 > > > them. It is just not designed to give a full 4GB of RAM to the system, it only
 > > > gives 3.4XGB RAM and the rest is really not used, then basically the system
 > > > just tries to give the 0.6xGB RAM remaining a task by it being used by "System
 > > > Resources"
 > > > 
 > > > This isn't really Linux dependant.
 > > 
 > > so there is no way to give me back the "lost" memory. Is it possible
 > > that another motherboard might help?
 > 
 > AFAIK, No. AMD and Intel will always do the same thing until we all move to
 > real IA64.

Somehow, I doubt AMD see it that way :-)

Some boards at least have a BIOS option to support 'memory hoisting'
to map the 'lost' memory above the 4G address space.

I suspect a lot of the lower-end (and older) boards however don't have
this option, as they were not tested with 4GB.

		Dave

Re: 4GB memory and Intel Dual-Core system

[Vladimir Lazarenko]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

>  > AFAIK, No. AMD and Intel will always do the same thing until we all move to
>  > real IA64.
> 
> Somehow, I doubt AMD see it that way :-)
> 
> Some boards at least have a BIOS option to support 'memory hoisting'
> to map the 'lost' memory above the 4G address space.
> 
> I suspect a lot of the lower-end (and older) boards however don't have
> this option, as they were not tested with 4GB.
> 

I have Tyan k8e which supports memory remapping. Question, however, will 
that work with i686-based kernel? Or do we have to switch to x86_64?

Vlad

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3412 bytes --]

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Dave,

> Some boards at least have a BIOS option to support 'memory hoisting'
> to map the 'lost' memory above the 4G address space.
> 
> I suspect a lot of the lower-end (and older) boards however don't have
> this option, as they were not tested with 4GB.

do you have any information about remapping support of the D945GNT
motherboard from Intel.

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Andi Kleen]

Roland Dreier <rolandd@cisco.com> writes:
> 
> I don't know if EM64T systems (or whatever the right term is) have a
> way of remapping some RAM above 4 GB so that you can use all your
> memory in a case like this.

The lower/middle end non server intel chipsets typically only support
4GB of physical address space in hardware. No memory remapping
possible. So with 4GB RAM you always lose to the memory hole.

-Andi

Re: 4GB memory and Intel Dual-Core system

[Dave Jones]

On Fri, Oct 28, 2005 at 12:11:11AM +0200, Marcel Holtmann wrote:
 > Hi Dave,
 > 
 > > Some boards at least have a BIOS option to support 'memory hoisting'
 > > to map the 'lost' memory above the 4G address space.
 > > 
 > > I suspect a lot of the lower-end (and older) boards however don't have
 > > this option, as they were not tested with 4GB.
 > 
 > do you have any information about remapping support of the D945GNT
 > motherboard from Intel.

I've not come across an EM64T with that much RAM, so I've not had
reason to go looking.. Sorry.

		Dave

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Thu, 27 Oct 2005 18:05:33 -0400, Dave Jones wrote
> On Thu, Oct 27, 2005 at 05:15:50PM -0400, Alejandro Bonilla wrote:
>  > On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
>  > > Hi Alejandro,
>  > > 
>  > > > > the board in this system is a Intel D945GNT and the box 
> tells me the > > > > maximum supported amount of RAM is 4 GB. So 
> there should be a way to > > > > address this amount memory. > > > 
>  > > > The board did take the 4GB of RAM and it is finding them, 
> therefore supports > > > them. It is just not designed to give a 
> full 4GB of RAM to the system, it only > > > gives 3.4XGB RAM and 
> the rest is really not used, then basically the system > > > just 
> tries to give the 0.6xGB RAM remaining a task by it being used by "System
>  > > > Resources"
>  > > > 
>  > > > This isn't really Linux dependant.
>  > > 
>  > > so there is no way to give me back the "lost" memory. Is it possible
>  > > that another motherboard might help?
>  > 
>  > AFAIK, No. AMD and Intel will always do the same thing until we 
> all move to > real IA64.
> 
> Somehow, I doubt AMD see it that way :-)
> 
> Some boards at least have a BIOS option to support 'memory hoisting'
> to map the 'lost' memory above the 4G address space.

True, probably AMD added a "workaround" for this problem, but by nature, this
is what happens.
> 
> I suspect a lot of the lower-end (and older) boards however don't 
> have this option, as they were not tested with 4GB.

Probably no Intel boards have the option. So, it would be that Marcel contact
Intel so they can add a mapping option on the BIOS for this situation. It is
somehow missleading.

.Alejandro

> 
> 		Dave

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Dave,

>  > > Some boards at least have a BIOS option to support 'memory hoisting'
>  > > to map the 'lost' memory above the 4G address space.
>  > > 
>  > > I suspect a lot of the lower-end (and older) boards however don't have
>  > > this option, as they were not tested with 4GB.
>  > 
>  > do you have any information about remapping support of the D945GNT
>  > motherboard from Intel.
> 
> I've not come across an EM64T with that much RAM, so I've not had
> reason to go looking.. Sorry.

am I really the first person trying to use that board with 4 GB of RAM
and an Intel Dual-Core with EM64T :(

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Alejandro,

> > I suspect a lot of the lower-end (and older) boards however don't 
> > have this option, as they were not tested with 4GB.
> 
> Probably no Intel boards have the option. So, it would be that Marcel contact
> Intel so they can add a mapping option on the BIOS for this situation. It is
> somehow missleading.

since Intel gave that board to me, they should really add something ;)

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Fri, 28 Oct 2005 00:17:01 +0200, Marcel Holtmann wrote
> Hi Dave,
> 
> >  > > Some boards at least have a BIOS option to support 'memory hoisting'
> >  > > to map the 'lost' memory above the 4G address space.
> >  > > 
> >  > > I suspect a lot of the lower-end (and older) boards however don't have
> >  > > this option, as they were not tested with 4GB.
> >  > 
> >  > do you have any information about remapping support of the D945GNT
> >  > motherboard from Intel.
> > 
> > I've not come across an EM64T with that much RAM, so I've not had
> > reason to go looking.. Sorry.
> 
> am I really the first person trying to use that board with 4 GB of 
> RAM and an Intel Dual-Core with EM64T :(

Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
_not_ made for 4GB, so, some motherboards manufacturers make a workaround like
Dave said, to Map such RAM. After all, that 0.6GB RAM will be used and
allocated for other resources. This is just how the arch works and I doubt it
will change.

Only thing that you can do is buy a new Mobo which might support Mapping for
the extra RAM.

There isn't really much that you can do.

.Alejandro

Re: 4GB memory and Intel Dual-Core system

[Joe Bob Spamtest]

Marcel Holtmann wrote:
> I could have bought two 512 MB modules ;)

I'll trade you two 512MB modules for two 1GB modules. :)

Re: 4GB memory and Intel Dual-Core system

[Joel Jaeggli]

On Fri, 28 Oct 2005, Marcel Holtmann wrote:

> Hi Dave,
>
>> >> Some boards at least have a BIOS option to support 'memory hoisting'
>> >> to map the 'lost' memory above the 4G address space.
>> >>
>> >> I suspect a lot of the lower-end (and older) boards however don't have
>> >> this option, as they were not tested with 4GB.
>> >
>> > do you have any information about remapping support of the D945GNT
>> > motherboard from Intel.
>>
>> I've not come across an EM64T with that much RAM, so I've not had
>> reason to go looking.. Sorry.
>
> am I really the first person trying to use that board with 4 GB of RAM
> and an Intel Dual-Core with EM64T :(

maybe the first one to not use it to play half-life 2...

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

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: 4GB memory and Intel Dual-Core system

[Bernd Eckenfels]

In article <20051027221756.M55421@linuxwireless.org> you wrote:
> Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
> _not_ made for 4GB

thats wrong.

Gruss
Bernd

Re: 4GB memory and Intel Dual-Core system

[Fawad Lateef]

On 10/28/05, Alejandro Bonilla <abonilla@linuxwireless.org> wrote:
> On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
> > Hi Alejandro,
> >
> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
>

Can you tell me the main differences between IA64 and x86_64 (Opteron)
? because in your one of the previous mail you said IA64 != EM64T and
its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
said that too EM64T is not really 64-bit, its a IA32 .. Can you give
me some link which just tells the difference between IA64 (Itanium)
and AMD64 (Opteron) ?

While googling I found this article
http://www.eweek.com/article2/0,1895,1046390,00.asp but its not
clearing mentioning the difference between Opteron and Itanium !

Although I found this difference in that article :
                     With the Itanium, Intel proposes to examine
programs when they are compiled into their executable form and encode
concurrent operations ahead of time. Intel calls this approach EPIC,
for Explicitly Parallel Instruction Computing, and it is the genuine
difference between the Itanium and AMD's x86-64. EPIC's drawback is
that the core of the Itanium no longer offers an effective
upward-compatible path to existing x86 code; its speed in running that
32-bit code has proved to be disappointing.

So is there any other difference except above ?


--
Fawad Lateef

Re: 4GB memory and Intel Dual-Core system

[Joel Jaeggli]

On Fri, 28 Oct 2005, Fawad Lateef wrote:

> On 10/28/05, Alejandro Bonilla <abonilla@linuxwireless.org> wrote:
>> On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
>>> Hi Alejandro,
>>>
>>> so there is no way to give me back the "lost" memory. Is it possible
>>> that another motherboard might help?
>>
>> AFAIK, No. AMD and Intel will always do the same thing until we all move to
>> real IA64.
>>
>
> Can you tell me the main differences between IA64 and x86_64 (Opteron)

IA64 is itanium - there are a lot of differences but the principle one for 
your perspective is that you don't want to run x86 code on a itanium, it 
has an x86 instruction decoder but you wouldn't want to use it if you 
could avoid it.

> ? because in your one of the previous mail you said IA64 != EM64T and

emt64 getts lumped with amd64 collectivly x86_64. fundamentaly intels 
implementation is compatible with amd's

> its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> said that too EM64T is not really 64-bit, its a IA32 .. Can you give

It is ia32 except with 40 bits of real memory and 48 bits of virtual 
memory and 64 bit registers.

one article that's use for getting a start on the instruction set is here:

http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html


> me some link which just tells the difference between IA64 (Itanium)
> and AMD64 (Opteron) ?

you're not likely to care about ia64, so I think what your'e really 
interested in is ia32 vs x86_64 and intel vs amd in the context of x86_64

> While googling I found this article
> http://www.eweek.com/article2/0,1895,1046390,00.asp but its not
> clearing mentioning the difference between Opteron and Itanium !
>
> Although I found this difference in that article :
>                     With the Itanium, Intel proposes to examine
> programs when they are compiled into their executable form and encode
> concurrent operations ahead of time. Intel calls this approach EPIC,
> for Explicitly Parallel Instruction Computing, and it is the genuine
> difference between the Itanium and AMD's x86-64. EPIC's drawback is
> that the core of the Itanium no longer offers an effective
> upward-compatible path to existing x86 code; its speed in running that
> 32-bit code has proved to be disappointing.
>
> So is there any other difference except above ?
>
>
> --
> Fawad Lateef
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: 4GB memory and Intel Dual-Core system

[Fawad Lateef]

On 10/28/05, Joel Jaeggli <joelja@darkwing.uoregon.edu> wrote:
> On Fri, 28 Oct 2005, Fawad Lateef wrote:
>
> > Can you tell me the main differences between IA64 and x86_64 (Opteron)
>
> IA64 is itanium - there are a lot of differences but the principle one for
> your perspective is that you don't want to run x86 code on a itanium, it
> has an x86 instruction decoder but you wouldn't want to use it if you
> could avoid it.
>

OK

> > ? because in your one of the previous mail you said IA64 != EM64T and
>
> emt64 getts lumped with amd64 collectivly x86_64. fundamentaly intels
> implementation is compatible with amd's
>
> > its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> > said that too EM64T is not really 64-bit, its a IA32 .. Can you give
>
> It is ia32 except with 40 bits of real memory and 48 bits of virtual
> memory and 64 bit registers.
>

And a difference of memory architecture is there tooo. x86_64 in
64-bit mode implements flat memory model but IA32 uses
segmentation/paging. As far as Linux Kernel is concern I know kernel
won't implements segmentation in IA32 so it memory management is
almost compatible with x86_64 except registers/real address /virtual
addresses ...

> one article that's use for getting a start on the instruction set is here:
>
> http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html
>

Thanks, nice link :)

>
> > me some link which just tells the difference between IA64 (Itanium)
> > and AMD64 (Opteron) ?
>
> you're not likely to care about ia64, so I think what your'e really
> interested in is ia32 vs x86_64 and intel vs amd in the context of x86_64
>

Nops, I am not interested in x86_64 context of intel and amd, I rather
wanted a comparison between the intel and amd server processors
architecture (Itanium and Opteron).

Any ways, Thanks


--
Fawad Lateef

Re: 4GB memory and Intel Dual-Core system

[Eric W. Biederman]

"Alejandro Bonilla" <abonilla@linuxwireless.org> writes:

>> so there is no way to give me back the "lost" memory. Is it possible
>> that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.

IA64 inherits this part of the architecture from x86, so no magic fix.
This is a fundamentally a chipset limitation, not an architectural bug.

rev-E amd64 cpus from AMD all have memory hoisting support,
as do all server chipsets from Intel for the last several years.

To avoid this you just need a good chipset and a good BIOS implementation.
Any recent server board should be fine.  Hopefully the desktop boards
will catch up soon.

Eric

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla]

On Fri, 28 Oct 2005 09:29:34 -0600, Eric W. Biederman wrote
> "Alejandro Bonilla" <abonilla@linuxwireless.org> writes:
> 
> >> so there is no way to give me back the "lost" memory. Is it possible
> >> that another motherboard might help?
> >
> > AFAIK, No. AMD and Intel will always do the same thing until we all move to
> > real IA64.
> 
> IA64 inherits this part of the architecture from x86, so no magic 
> fix. This is a fundamentally a chipset limitation, not an 
> architectural bug.

Probably, but if they add a function to support this, then is a Fix, else it
would have been there all the time.

> 
> rev-E amd64 cpus from AMD all have memory hoisting support,
> as do all server chipsets from Intel for the last several years.

Not according to the link I provided since we started the conversation. But
they have done tweaks to start "supporting" all this memory.

> 
> To avoid this you just need a good chipset and a good BIOS implementation.
> Any recent server board should be fine.  Hopefully the desktop boards
> will catch up soon.

I doubt it, Intel is slowly moving to 64bit so applications and OS can catch
up in the future to leave 32bit behind. (Probably)

Anyway, I think Marcel got most of he's doubt answered.

.Alejandro

> 
> Eric

Re: 4GB memory and Intel Dual-Core system

[Joe Bob Spamtest]

Fawad Lateef wrote:
> Can you tell me the main differences between IA64 and x86_64 (Opteron)
> ? because in your one of the previous mail you said IA64 != EM64T and
> its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> said that too EM64T is not really 64-bit, its a IA32 .. Can you give
> me some link which just tells the difference between IA64 (Itanium)
> and AMD64 (Opteron) ?

IA64 (Itanium [Itanic, really -- the architecture IMO is a real 
disappointment IRL for something which on paper looked very impressive]) 
is a true 64 bit CPU. It's a new architecture built from scratch -- as 
different from IA32 as SPARC is. IA64 has a "compatibility mode" which 
allows it to run IA32 code natively, albeit very, very slow. Make no 
mistake -- IA64 is a completely different CPU type and architecture from 
IA32.

x86_64 (both AMD64 and Intel's EM64T offerings) are 64-bit extensions to 
a 32 bit microprocessor. The system architecture stayed basically the 
same. This is different from IA32 in the same ways PPC64 is different 
from PPC32 and SPARC64 is different from SPARC32. Both CPUs use the same 
set of commands as their predecessors, with the inclusion of several 
more instructions and registers (as well as the registers being of 
greater width).

The differences between AMD64 and EM64T are significant as well; however 
from a programming standpoint the differences are almost negligible. THe 
biggest difference (which may have impact on programming principles) is 
AMD64 is a NUMA architecture whereas EM64T still uses the same memory 
model and architecture as the IA32. Quite simply, you gain more from 
AMD64 than you do from EM64T, in my opinion.

Both (really, all three) architectures have their plusses and minuses. 
EM64T is Intel's idea of playing catch-up with the competition (AMD), IMO.

>                      With the Itanium, Intel proposes to examine
> programs when they are compiled into their executable form and encode
> concurrent operations ahead of time. Intel calls this approach EPIC,
> for Explicitly Parallel Instruction Computing, and it is the genuine
> difference between the Itanium and AMD's x86-64. EPIC's drawback is

This is so blatantly simplified it's outright wrong.

EPIC is a very clever, revolutionary design. When I first read the 
Itanium whitepapers some years ago, it seemed like this technology was 
definitely worth taking a look at. Apparently I wasn't the only one who 
thought this: HP dropped PA-RISC for Itanium, SGI dropped MIPS, Compaq 
(at the time its own entity) dropped Alpha... Everyone, it seems, jumped 
on the bandwagon with the exception of Sun, who elected to wait for 
AMD's offering. Turns out though, what looked good on paper turned out 
to be quite a disappointment. The original Itanium, at its release, was 
very disappointing in terms of performance. At the time, the 32-bit 
Pentium III Tualatin could perform the same calculations as Itanium in 
less time -- for a fraction of the cost. And the 32-bit codepath 
compatibility? It was a joke -- some compared it to a sluggish 
Pentium-II 266. HP took the Itanium specification from Intel, used its 
expertise from years with PA-RISC, and redesigned Itanium, to later 
release Itanium II. This offered a great performance increase over the 
previous release, but the 32-bit codepath is still abysmally slow. Even 
the new, improved EPIC still lacks; thus far nobody's compiler -- not 
even Intel's -- can take full advantage or make full use of the features 
in this CPU. Many high-performance applications are still hand-tuned in 
IA64 assembler to take advantage of its offerings.

Hope this helped to clear some things up.

Cheers,
-Kelsey

Re: 4GB memory and Intel Dual-Core system

[Eric W. Biederman]

"Alejandro Bonilla" <abonilla@linuxwireless.org> writes:

> On Fri, 28 Oct 2005 09:29:34 -0600, Eric W. Biederman wrote
>> "Alejandro Bonilla" <abonilla@linuxwireless.org> writes:
>> 
>> >> so there is no way to give me back the "lost" memory. Is it possible
>> >> that another motherboard might help?
>> >
>> > AFAIK, No. AMD and Intel will always do the same thing until we all move to
>> > real IA64.
>> 
>> IA64 inherits this part of the architecture from x86, so no magic 
>> fix. This is a fundamentally a chipset limitation, not an 
>> architectural bug.
>
> Probably, but if they add a function to support this, then is a Fix, else it
> would have been there all the time.

It is an optimization.  Most chipsets have a hole from XXX-4GB where
you can't put memory.  In most configurations the hole is only a couple
of megabytes.  Although with PCI-E I think it is now typically about 512M
because of the memory mapped PCI-E config space.

If you put in more that 4G the memory usually shows up at 4G and keeps going.

With memory hoisting that many recent chipsets implement you can see the
memory that would normally be covered by the mmio hole someplace about
4G, so you don't loose any memory in that situation.

Now that I think about it that explains why memory was missing on the
system with PCI-E the memory mapped PCI-E config space was out there
covering it up.

>> rev-E amd64 cpus from AMD all have memory hoisting support,
>> as do all server chipsets from Intel for the last several years.
>
> Not according to the link I provided since we started the conversation. But
> they have done tweaks to start "supporting" all this memory.

I have been writing BIOS's for the last 5 years, on Intel and on AMD boards.
I know exactly what the situation is for the boards and chipsets I
have been dealing with.  I actually find it mildly surprising that
desktop boards don't handle this yet.

>> To avoid this you just need a good chipset and a good BIOS implementation.
>> Any recent server board should be fine.  Hopefully the desktop boards
>> will catch up soon.
>
> I doubt it, Intel is slowly moving to 64bit so applications and OS can catch
> up in the future to leave 32bit behind. (Probably)

???
What has this to do with 32bit and 64bit.  x86_64 (aka amd64+em64t) is
the 64bit desktop architecture, and that is what I am talking about.

Basically everything is 64bit now, the only question is how well does
the chipset and BIOS support your memory configuration.

Eric

Re: 4GB memory and Intel Dual-Core system

[Lukas Hejtmanek]

Hello,

I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.

Kernel is 2.6.13.4 compiled for x86_64 architecture.

Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical 
memory. Not 40.

# cat /proc/meminfo 
MemTotal:      4075408 kB
MemFree:         23696 kB

# cat /proc/iomem
[...]
dd100000-dd3fffff : PCI Bus #01
  dd100000-dd100fff : 0000:01:00.1
  dd101000-dd101fff : 0000:01:00.3
  dd200000-dd2fffff : PCI Bus #02
    dd200000-dd201fff : 0000:02:02.0
      dd200000-dd200fff : aic79xx
    dd202000-dd203fff : 0000:02:02.1
      dd202000-dd202fff : aic79xx
    dd220000-dd23ffff : 0000:02:03.0
      dd220000-dd23ffff : e1000
    dd240000-dd25ffff : 0000:02:03.1
      dd240000-dd25ffff : e1000
  dd300000-dd3fffff : PCI Bus #03
    dd300000-dd3fffff : 0000:03:04.0
dd400000-deffffff : PCI Bus #06
  dd400000-dd400fff : 0000:06:01.0
  de000000-deffffff : 0000:06:01.0
e0000000-efffffff : reserved
fec00000-fec0ffff : reserved
fee00000-fee00fff : reserved
ff800000-ffbfffff : reserved
fffffc00-ffffffff : reserved
100000000-12fffffff : System RAM

According to /proc/pci it is E7520/E7525 board. It has a number of PCI devices.

-- 
Lukáš Hejtmánek

Re: 4GB memory and Intel Dual-Core system

[Dave Jones]

On Fri, Oct 28, 2005 at 10:58:33PM +0200, Lukas Hejtmanek wrote:
 > Hello,
 > 
 > I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
 > 
 > Kernel is 2.6.13.4 compiled for x86_64 architecture.
 > 
 > Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical 
 > memory. Not 40.

That should be fixed in 2.6.14

		Dave

Re: 4GB memory and Intel Dual-Core system

[Marcel Holtmann]

Hi Dave,

>  > I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
>  > 
>  > Kernel is 2.6.13.4 compiled for x86_64 architecture.
>  > 
>  > Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical 
>  > memory. Not 40.
> 
> That should be fixed in 2.6.14

is this only true for the Xeon series or should it be 40 bits for every
EM64T capable CPU from Intel? I ask, because mine still shows 36 bits
with the latest vanilla from today.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :               Intel(R) Pentium(R) D CPU 2.80GHz
stepping        : 4
cpu MHz         : 2800.229
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
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 syscall lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips        : 5609.23
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

Regards

Marcel

Re: 4GB memory and Intel Dual-Core system

[Dave Jones]

On Sat, Oct 29, 2005 at 01:15:24PM +0200, Marcel Holtmann wrote:
 > Hi Dave,
 > 
 > >  > I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
 > >  > 
 > >  > Kernel is 2.6.13.4 compiled for x86_64 architecture.
 > >  > 
 > >  > Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical 
 > >  > memory. Not 40.
 > > 
 > > That should be fixed in 2.6.14
 > 
 > is this only true for the Xeon series or should it be 40 bits for every
 > EM64T capable CPU from Intel? I ask, because mine still shows 36 bits
 > with the latest vanilla from today.

Actually, I mixed this up a little. 36 bits is 'the norm' for EM64T 
(for right now at least).  However, there were two models that advertised
40 bits, but only actually have 36 bits.

The following patch Andi forwarded never actually made it into 2.6.14.
Definite 2.6.14.1 material IMO.

		Dave

From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Subject: [PATCH] x86_64/i386: Compute correct MTRR mask on early Noconas
Date: Thu, 13 Oct 2005 02:28:26 +0200
Cc: discuss@x86-64.org, Shaohua Li <shaohua.li@intel.com>, davej@redhat.com


Force correct address space size for MTRR on some 64bit Intel Xeons

They report 40bit, but only have 36bits of physical address space.
This caused problems with setting up the correct masks for MTRR,
resulting in incorrect MTRRs.

CPUID workaround for steppings 0F33h(supporting x86) and 0F34h(supporting x86
and EM64T). Detail info can be found at:
http://download.intel.com/design/Xeon/specupdt/30240216.pdf
http://download.intel.com/design/Pentium4/specupdt/30235221.pdf

Signed-off-by: Shaohua Li<shaohua.li@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>

Index: linux/arch/i386/kernel/cpu/mtrr/main.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux/arch/i386/kernel/cpu/mtrr/main.c
@@ -626,6 +626,14 @@ void __init mtrr_bp_init(void)
 		if (cpuid_eax(0x80000000) >= 0x80000008) {
 			u32 phys_addr;
 			phys_addr = cpuid_eax(0x80000008) & 0xff;
+			/* CPUID workaround for Intel 0F33/0F34 CPU */
+			if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+			    boot_cpu_data.x86 == 0xF &&
+			    boot_cpu_data.x86_model == 0x3 &&
+			    (boot_cpu_data.x86_mask == 0x3 ||
+			     boot_cpu_data.x86_mask == 0x4))
+				phys_addr = 36;
+
 			size_or_mask = ~((1 << (phys_addr - PAGE_SHIFT)) - 1);
 			size_and_mask = ~size_or_mask & 0xfff00000;
 		} else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
Index: linux/arch/x86_64/kernel/setup.c
===================================================================
--- linux.orig/arch/x86_64/kernel/setup.c
+++ linux/arch/x86_64/kernel/setup.c
@@ -990,6 +990,11 @@ static void __cpuinit init_intel(struct 
 		unsigned eax = cpuid_eax(0x80000008);
 		c->x86_virt_bits = (eax >> 8) & 0xff;
 		c->x86_phys_bits = eax & 0xff;
+		/* CPUID workaround for Intel 0F34 CPU */
+		if (c->x86_vendor == X86_VENDOR_INTEL &&
+		    c->x86 == 0xF && c->x86_model == 0x3 &&
+		    c->x86_mask == 0x4)
+			c->x86_phys_bits = 36;
 	}
 
 	if (c->x86 == 15)

Re: 4GB memory and Intel Dual-Core system

[Alan Cox]

On Iau, 2005-10-27 at 17:15 -0400, Alejandro Bonilla wrote:
> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
> 
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.

Fortunately you can use a real processor with 4GB of RAM as well as an
IA-64 (if you can find one even!). It is chipset dependant whether RAM
lost to the PCI window can be made to appear over the 4GB boundary with
a PAE capable intel ia32 processor (or clone) with an AMD x86-64
processor (or clone)

It depends entirely on the chipset quality

Re: 4GB memory and Intel Dual-Core system

[Alan Cox]

On Iau, 2005-10-27 at 18:20 -0400, Alejandro Bonilla wrote:
> Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
> _not_ made for 4GB, so, some motherboards manufacturers make a workaround like

Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
mode and has done since the Preventium Pro

Re: 4GB memory and Intel Dual-Core system

[Alejandro Bonilla Beeche]

Alan Cox wrote:

>On Iau, 2005-10-27 at 18:20 -0400, Alejandro Bonilla wrote:
>  
>
>>Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
>>_not_ made for 4GB, so, some motherboards manufacturers make a workaround like
>>    
>>
>
>Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
>mode and has done since the Preventium Pro
>  
>

I guess you are right and wrong. The architecture has the limitation, 
the chipset as well and the OS. According to this document, it is the 
fault of the architecture as well as it requires to support addressing 
which is not available *stock*, only several other providers have added 
such "mapping" to get a better use of the memory.

http://www.intel.com/support/motherboards/server/sb/cs-010458.htm

I really don't want to argue on who knows more or less, just want to 
clarify the fact that IA32 will have this problem normally and that the 
chipsets that go with it also will make this noticeable.

If you don't believe me, contact the guys who built the Arch which I 
think are the ones that made the document?

.Alejandro

Re: 4GB memory and Intel Dual-Core system

[Alan Cox]

On Sul, 2005-10-30 at 20:39 -0700, Alejandro Bonilla Beeche wrote:
> I guess you are right and wrong. The architecture has the limitation, 
> the chipset as well and the OS. According to this document, it is the 
> fault of the architecture as well as it requires to support addressing 
> which is not available *stock*, only several other providers have added 
> such "mapping" to get a better use of the memory.

That document reads like a "don't blame us because we didn't bother to
do remapping". That is an Intel business decision not a hardware limit,
as is shown by other vendors whose hardware can do the remap.

Re: [stable] Re: 4GB memory and Intel Dual-Core system

[Chris Wright]

* Dave Jones (davej@redhat.com) wrote:
> The following patch Andi forwarded never actually made it into 2.6.14.
> Definite 2.6.14.1 material IMO.

Thanks, queued to -stable.  Also, this one is still not upstream.
-chris

Re: 4GB memory and Intel Dual-Core system

[Martin J. Bligh]

--On Sunday, October 30, 2005 22:26:05 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Iau, 2005-10-27 at 18:20 -0400, Alejandro Bonilla wrote:
>> Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
>> _not_ made for 4GB, so, some motherboards manufacturers make a workaround like
> 
> Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
> mode and has done since the Preventium Pro

Indeed ... I have 64GB ia32 boxes ;-)

M.

Re: 4GB memory and Intel Dual-Core system

[thockin]

On Mon, Oct 31, 2005 at 03:03:08PM -0800, Martin J. Bligh wrote:
> > Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
> > mode and has done since the Preventium Pro
> 
> Indeed ... I have 64GB ia32 boxes ;-)

And Intel server chipsets do support remapping.  I've seen boards with 2
GB IO holes remapped above 4 GB.

A 4 GB system reports 6 GB of memory, 4 of which are usable as DRAM.
Intel doesn't document it, but there's a slight performance hit for the
remapped memory, too.

Re: 4GB memory and Intel Dual-Core system

[Lennart Sorensen]

On Thu, Oct 27, 2005 at 05:15:50PM -0400, Alejandro Bonilla wrote:
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.

Many boards DO allow remapping memory past 3GB to the 4GB+ area to make
it accessable.  There should be a BIOS option for remapping memory or
letting software create a memory hole at 3GB.  It is NOT normal to not
allow full access to all the memeory on an amd64/em64t system.  Of
course the bios defaults are often set so as to provide as much ram to a
32bit OS as possible at the expense of doing it properly for a 64bit OS.

And it looks like the world has no intension of ever moving to IA64, and
that's probably for the best.  PowerPC or Alpha or something would make
more sense if you are going to drop x86.

> Unless there is some sort of kernel hack that will do some crazy thing to give
> you the power there.
> 
> But hey, look at it this way, if you remove 1GB, you will lose the Dual
> Channel capability.

Len Sorensen

Re: 4GB memory and Intel Dual-Core system

[Lennart Sorensen]

On Fri, Oct 28, 2005 at 12:09:25AM +0200, Vladimir Lazarenko wrote:
> I have Tyan k8e which supports memory remapping. Question, however, will 
> that work with i686-based kernel? Or do we have to switch to x86_64?

I suspect with PAE it will still work yes.  I haven't tried it of course
(I don't have that much ram).  It will still have the PAE performance
hit on memory access to memory past 4GB just because that's what PAE
does.

Len Sorensen

Re: [discuss] Re: [stable] Re: 4GB memory and Intel Dual-Core system

[Andi Kleen]

On Monday 31 October 2005 22:04, Chris Wright wrote:
> * Dave Jones (davej@redhat.com) wrote:
> > The following patch Andi forwarded never actually made it into 2.6.14.
> > Definite 2.6.14.1 material IMO.
>
> Thanks, queued to -stable.  Also, this one is still not upstream.

Will be soon, but in general I would prefer if you didn't merge anything
into STABLE that wasn't upstream yet. Otherwise we risk code drift again.

Thanks,
-Andi

Re: [discuss] Re: [stable] Re: 4GB memory and Intel Dual-Core system

[Chris Wright]

* Andi Kleen (ak@suse.de) wrote:
> On Monday 31 October 2005 22:04, Chris Wright wrote:
> > * Dave Jones (davej@redhat.com) wrote:
> > > The following patch Andi forwarded never actually made it into 2.6.14.
> > > Definite 2.6.14.1 material IMO.
> >
> > Thanks, queued to -stable.  Also, this one is still not upstream.
> 
> Will be soon, but in general I would prefer if you didn't merge anything
> into STABLE that wasn't upstream yet. Otherwise we risk code drift again.

Absolutely.  I just put it in the queue to keep from losing it, and
that's why I mentioned it's not upstream yet.  I'm happy to drop it if
you want to resend once it's merged.

thanks,
-chris