LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Laptop and Netbook (https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/)
-   -   Debian "Wheezy" amd64 high RAM not visible. (https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/debian-wheezy-amd64-high-ram-not-visible-4175481218/)

sevs 10-17-2013 05:34 PM

Debian "Wheezy" amd64 high RAM not visible.
 
Greetings to all who read this.

I've got a Lenovo B575e laptop. It has AMD E2-2000 CPU inside and a single stick of 4GB RAM.
I've installed Debian "Wheezy" with amd64 architecture.
The problem is that highest (the fourth, to be more accurate) gigabyte of the address space is not addressed to the RAM but to devices. I know there should be "memory remap"-like named option in the BIOS setup but it is a laptop you see. The laptop's BIOS setup does not allow many settings to be changed by the end user.

So, the 'cpuid' command says (at the last line of its output):
Code:

Maximum linear address: 48; maximum phys address 36
And 'cat /proc/cpuinfo' says:
Code:

address sizes        : 36 bits physical, 48 bits virtual
As I see my processor allows to address 2^36 = 64Gb of address space (and the appropriate amount of RAM).

And here is my E820 memory map:
Code:

sergey@r2c3:~$ dmesg | grep -i e820
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000d2974000 (usable)
[    0.000000]  BIOS-e820: 00000000d2974000 - 00000000dea31000 (reserved)
[    0.000000]  BIOS-e820: 00000000dea31000 - 00000000deb33000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000deb33000 - 00000000debb3000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000debb3000 - 00000000e0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fe800000 - 00000000fe801000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed80000 - 00000000fed81000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000107000000 (usable)
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)

Plus 'smem' output and some calculus:
Code:

sergey@r2c3:~$ smem -R 4G -w
Area                          Used      Cache  Noncache
firmware/hardware            754056          0    754056
kernel image                      0          0          0
kernel dynamic memory        686440    599792      86648
userspace memory            561524      98652    462872
free memory                2192284    2192284          0
sergey@r2c3:~$ echo $(((754056 + 0 + 686440 + 561524 + 2192284)/1024))
4096

So, looks like 754056kB is taken by the firmware/hardware. Can I (or, "is there a way") remap those kB's back to RAM address space?

Thanks in advance.
Sorry for my broken English.

business_kid 10-21-2013 12:37 PM

I think you need to investigate amd iommu.

iommu is the amd way of handling high memory
I had an early 64bit box and the boot would say things like
"Hmmph! Found an iommu aperature at 4 Gigs - deleted it. it's clearly ridiculous. What were they smoking?
Made a temporary one at 2 gigs. This is wasting good 64M ram on you."

Subsequently the kernel was fixed, and you could specify iommu stuff with commands at boot time. don't know where things stand now.

sevs 10-21-2013 02:41 PM

@business_kid

Before I made changes to my compilation configuration there were set options:
CONFIG_AMD_IOMMU=y
CONFIG_INTEL_IOMMU=y
CONFIG_IRQ_REMP=y

Now, I've set:
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_DEFAULT_ON=y

That still makes no effect.

Currently, I'm reading Documentation/x86/x86_64/boot-options.txt, section IOMMU and I think I should put iommu option equal to force or noforce or setting amd_iommu to fullflush

UPD:
Interchanging between these boot options gives no effect with the new kernel.

business_kid 10-22-2013 03:27 AM

I would take the shourtcut of linux-laptop.net and look for guys running your hardware with a page up. Then see what worked for them.


All times are GMT -5. The time now is 03:25 AM.