Lenovo W530 64bit not detecting all 6GB of RAM

[wilbertcr]

Hello,

Here are the details I know how to show from what I read on other related threads:

$uname -r

3.12.8-300.fc20.x86_64

$ free -m

total used free shared buffers cached
Mem: 4753 4472 281 40 155 1961
-/+ buffers/cache: 2354 2399
Swap: 4879 884 3995

My machine has 6GB of RAM, they were showing back when I was running Windows and they still show when my machine start. memtest86+ also shows 6GB or RAM, however, as you can see above, Linux shows 4753MB. Also, at the time I called free -m, my System Monitor is showing 2.3GiB of RAM being used, not 4472MiB as displayed by free -m and 884MiB or Swap in use.

I understand that the 64bit Kernel should be able to detect all RAM so I am confused, specially because I have a dedicated video card:

$ lspci -vnnn | perl -lne 'print if /^\d+\:.+(\[\S+\:\S+\])/' | grep VGA

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107GLM [Quadro K1000M] [10de:0ffc] (rev a1) (prog-if 00 [VGA controller])

I am pretty puzzled by this. Also, I am sure this is not a Fedora Specific problem, I tried several flavors of Linux before settling for Fedora and they all had the same issue.

Any help would be appreciated!

Regards,

Wilbert

[ocratato]

Perhaps the dmidecode command might provide some insight. Just pipe the output through more until you get down to the memory sections (some of which may be unused).

[wilbertcr]

# dmidecode 2.12

Handle 0x0007, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 4

Handle 0x0008, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0007
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: ChannelA-DIMM0
Bank Locator: BANK 0
Type: Unknown
Type Detail: None
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: None
Part Number: Not Specified
Rank: Unknown
Configured Clock Speed: Unknown

Handle 0x0009, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0007
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: SODIMM
Set: None
Locator: ChannelA-DIMM1
Bank Locator: BANK 1
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Samsung
Serial Number: E6B5CA6D
Asset Tag: None
Part Number: M471B5273DH0-CK0
Rank: Unknown
Configured Clock Speed: 1600 MHz

Handle 0x000A, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0007
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: ChannelB-DIMM0
Bank Locator: BANK 2
Type: Unknown
Type Detail: None
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: None
Part Number: Not Specified
Rank: Unknown
Configured Clock Speed: Unknown

Handle 0x000B, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0007
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: SODIMM
Set: None
Locator: ChannelB-DIMM1
Bank Locator: BANK 3
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Hynix/Hyundai
Serial Number: 0D554E31
Asset Tag: None
Part Number: HMT325S6CFR8C-PB
Rank: Unknown
Configured Clock Speed: 1600 MHz

Handle 0x000C, DMI type 19, 31 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0017FFFFFFF
Range Size: 6 GB
Physical Array Handle: 0x0007
Partition Width: 4

Handle 0x000D, DMI type 134, 13 bytes
OEM-specific Type
Header and Data:
86 0D 0D 00 21 07 12 20 00 00 00 00 00

Handle 0x000E, DMI type 0, 24 bytes
BIOS Information
Vendor: LENOVO
Version: G5ET95WW (2.55 )
Release Date: 09/13/2013
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 12288 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 2.55
Firmware Revision: 1.12

Handle 0x000F, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 2436CTO
Version: ThinkPad W530
Serial Number: R9R8E4G
UUID: C5744E81-5192-11CB-895D-AAFCCAF55677
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_2436
Family: ThinkPad W530

Handle 0x0010, DMI type 2, 15 bytes
Base Board Information
Manufacturer: LENOVO
Product Name: 2436CTO
Version: Not Defined
Serial Number: 1ZM652731CL
Asset Tag: Not Available
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Not Available
Chassis Handle: 0x0000
Type: Motherboard
Contained Object Handles: 0

Handle 0x0011, DMI type 3, 22 bytes
Chassis Information
Manufacturer: LENOVO
Type: Notebook
Lock: Not Present
Version: Not Available
Serial Number: R9R8E4G
Asset Tag: No Asset Information
Boot-up State: Unknown
Power Supply State: Unknown
Thermal State: Unknown
Security Status: Unknown
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: Unspecified
Contained Elements: 0
SKU Number: LENOVO_MT_2436

---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------

Thanks for looking into it!

[ocratato]

The only potential issue I can see is that the 2GB memory is from a different manufacturer than the other 4GB. It is (I am lead to believe) best practice to use that same source, or even same batch, for all the memory chips so as to avoid odd timing issues etc.

Another source of information is /proc/meminfo - perhaps that might give a hint.

[lsatenstein]

Hello,

Here are the details I know how to show from what I read on other related threads:

$uname -r

3.12.8-300.fc20.x86_64

$ free -m

total used free shared buffers cached
Mem: 4753 4472 281 40 155 1961
-/+ buffers/cache: 2354 2399
Swap: 4879 884 3995

My machine has 6GB of RAM, they were showing back when I was running Windows and they still show when my machine start. memtest86+ also shows 6GB or RAM, however, as you can see above, Linux shows 4753MB. Also, at the time I called free -m, my System Monitor is showing 2.3GiB of RAM being used, not 4472MiB as displayed by free -m and 884MiB or Swap in use.

I understand that the 64bit Kernel should be able to detect all RAM so I am confused, specially because I have a dedicated video card:

$ lspci -vnnn | perl -lne 'print if /^\d+\:.+(\[\S+\:\S+\])/' | grep VGA

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107GLM [Quadro K1000M] [10de:0ffc] (rev a1) (prog-if 00 [VGA controller])

I am pretty puzzled by this. Also, I am sure this is not a Fedora Specific problem, I tried several flavors of Linux before settling for Fedora and they all had the same issue.

Any help would be appreciated!

Regards,

Wilbert

Hi Wilbert.
I just resolved a similar problem with my system. Let me explain my actions, then you can decide if you want to do the same and to let us know your results.

My system was originally assembled with 4 gigs. I received 2 more dimms of 4 gigs total, which I installed into my system. My problems started then.

I could not copy large files to a USB drive without experiencing corruption. I blamed the USB drive, I ran memtest overnight and experienced no errors, and I was getting upset and really at wits end.

By chance, I told myself that the only thing I did not look at were the bios settings. I restarted the computer, entered the bios, and visited panel by panel. My 8 gigs showed up as 7.2g. Why did I lose a half gig?

Looking around I found an option to remap the PCI (graphics) card, and to remap the 1 meg that was always reserved for XP (No, I never ran XP on that system). Revising those two parameters, I continued...

I took note of every setting, then hit F5 on my computer to reset bios defaults. That last action was the solution. In resetting defaults, the bios scanned memory and now recognized my 8gigs. Then, I tweaked the other settings to be what they were the clearing to defaults.

After saving the bios changes and rebooting, I got back a healthy system. Everything works as it should. I have my full 8 gigs, and my USB drive with ext3 formatted disk is no longer experiencing I/O corruption.

[wilbertcr]

Hello,

Thank you both for looking into it and for your advice. I tried playing with the BIOS but that wasn't very fruitful, I restored all values to Default but that didn't fix anything, nevertheless the mentioning of the PCI reminded me of something, when I start the machine, this shows up after the Intel Raid manager screen:

[ 1.99109] ] pci 0000:00:01.0: ASPM: Could not configure common clock

The system then moves on to starting "normally" from then.

I think it might come down to getting another 4GB of RAM of the Samsung Kind that it's already installed. The machine was 4GB standard and I requested 2 extra from Lenovo when I bought it, sadly they placed a different kind of dim...

It is still sad that while Windows is ok with it, it seems like the Linux Kernel it isn't...

BTW:

$sudo /proc/meminfo

It gave me a "command not found" error

---------- Post added at 06:38 AM ---------- Previous post was at 06:34 AM ----------

I just ordered another 4GB of RAM with the same Part# as the one I have installed. I'll let you know what happens once I get them and install them.

[ocratato]

Sorry. /proc/meminfo is a virtual file not a command:

cat /proc/meminfo

[wilbertcr]

No wonder hehe. Here are the contents of it:



MemTotal: 4867352 kB
MemFree: 142080 kB
Buffers: 2672 kB
Cached: 2586388 kB
SwapCached: 45324 kB
Active: 2680464 kB
Inactive: 1418856 kB
Active(anon): 2557828 kB
Inactive(anon): 1136928 kB
Active(file): 122636 kB
Inactive(file): 281928 kB
Unevictable: 156 kB
Mlocked: 156 kB
SwapTotal: 4997116 kB
SwapFree: 4578344 kB
Dirty: 13160 kB
Writeback: 0 kB
AnonPages: 1474052 kB
Mapped: 2338804 kB
Shmem: 2182612 kB
Slab: 365552 kB
SReclaimable: 291268 kB
SUnreclaim: 74284 kB
KernelStack: 4064 kB
PageTables: 41124 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 7430792 kB
Committed_AS: 7110028 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 147624 kB
VmallocChunk: 34359585788 kB
HardwareCorrupted: 0 kB
AnonHugePages: 206848 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 292352 kB
DirectMap2M: 4734976 kB

[Kobuck]

Try looking at BIOS settings to find anything that references the IOMMU. You want the IOMMU to be "enabled". Many BIOS implementations use obscure terms rather than a direct reference to IOMMU. So anything that activates "re-mapping" could apply.

The IOMMU gives Fedora the hardware registers to manage large memory spaces.

[wilbertcr]

Thanks Kobuck,

I tried but the only thing having to do with memory is a security feature that prevents buffer overflows, nothing else came up even remotely having anything to do with memory.

[Kobuck]

Was windows running 32bit? Activating 64bit memory access will change how the memory slots are used.


Read up on how to add memory in your system manual. I don't know how laptop memory is managed, but on atx style motherboards there are recommendations about which banks to use first when adding memory. You currently have memory plugged into bank1 (4GB) and bank3 (2GB).

Some designs will not allow mismatched sizes and fall back to only recognizing the memory locations which are available in both banks. ( 2GB from bank1 and 2GB from bank3 ).

The design of your particular model will determine the actual affect of different memory sizes. But given you are having issues, I would suspect which banks you use and different memory sizes could be the cause.

[wilbertcr]

Thank you. I know the system was designed to be able to deal with different stick sizes and that the way it is setup now is as per specification because what I have now is exactly what I got from Lenovo when I bought the computer. The machine was standard with 4GB and I added the 2GB when I ordered it, so it came the way it is now when I unboxed it.

I also know that currently it is recognizing both sticks because it shows over 4GB of RAM, which wouldn't be the case if it were only reading 2GB per stick.

Finally, windows, the Bios and memtest86+ all recognize the 6GB as working. The problem is really Linux, not the hardware itself as other operative systems(i.e. Windows, both 7 and 8) recognize the 6GB of RAM currently installed on the computer.

The machine has 4 slots, two of them, the ones currently holding the 4GB and 2GB sticks are hidden underneath the keyboard, the other two are easily accessible underneath the machine so I am planning to put the new stick in one of them. The funny thing is that, although Linux says the ones currently in use are 1 and 3, the ones in the back of the machine are labeled 3 and 4, which means the sticks currently in there are actually in the banks 1 and 2 hehe. This again points at Linux being the guilty party here, not the hardware.

Wilbert

[ocratato]

My understanding after doing some reading is that the MemTotal amount is the amount available for use, not the installed amount. The difference is being used by the kernel.

The kernel bits in /proc/meminfo are: Slab, SReclaimable, SUnreclaim, KernelStack, PageTables, and AnonHugePages, which I think comes to the missing difference between MemTotal and 6GB.

[Kobuck]

I can assure you that Linux is capable of utilizing large amounts of memory. The trick is getting the target hardware configuration and the Fedora kernel configuration aligned. Sometimes (often) everything just works, other times you end up learning more than you thought you wanted to know.

Via a quick Google search I found the Levento W530 spec'ed as a i7-3820QM processor using a QM77 chipset. Nothing exotic there.

My inputs to you are assuming that your Fedora build is the only OS actually trying to operate all the capabilities that come with a full 64bit memory model. Yes the BIOS and memtest can "see" the 6GB, but neither of these tools try to initialize interleaved memory access. (that was also the reason I asked whether the Windows you ran was 32bit) Since you didn't find any options in BIOS to switch IOMMU on and off , I am also assuming it's default is "on" since that option enables more of the hardware capabilities. Tools and OS's that don't use it aren't affected and OS's which can use it have access to the capabilities.

All of this is experience and assumption on my part because few hardware builders document at a sufficient level of detail to help. Therefore users are left to trial and error and forums for help.

The BIOS setting on my Shuttle is ( Intel(R) V.T. =enabled ) which according to the documentation activates Vanderpool support. Now how would anyone guess what that means?

My bet is your problem is configuration, and if you were to replace the 2GB stick with a 4GB stick you will see 8GB total memory in Fedora as well.

Good Luck!!!

[Kobuck]

My understanding after doing some reading is that the MemTotal amount is the amount available for use, not the installed amount. The difference is being used by the kernel.

On my two machines I get total "initialized" memory ( in this case it equals installed memory ) in case of O.P is is only 4GB of 6GB installed.

On Shuttle(a nework file server):

 cat /proc/meminfo
MemTotal:       16266952 kB
MemFree:         3745980 kB
Buffers:          321324 kB
Cached:         11448852 kB

On GigaByte(a workstation):

cat /proc/meminfo
MemTotal:       16432308 kB
MemFree:        14061792 kB
Buffers:            1008 kB
Cached:          1199592 kB

Wow!! tough to find a definitive memory number. Went back to journalctl initialization messages and got:
GigaByte = 16,774,340K
Shuttle = 16,606,304K ( i3 uses integrated graphics which reduces total )

Net story is meminfo for both is ~ 340MB less than total reported in journalctl initialization messages. Some support for @ocratato's point, but not at a 2GB scale.