x86_64 - 8G RAM quick, 16G very slow?

[bwaldow]

Hello,

The laptop is an HP ProBook 4540s, SKU: B7C25PA#ABG, with a Core i5-3210M CPU, Intel HD4000 graphics, discrete graphics disabled in BIOS. BIOS updated to latest F.42.

RAM is Crucial 8G DDR3 1600 1.35v, one or two sticks.

OS is a fresh install of gentoo x86_64, kernel 3.10.17. No problems were noted during the install. The system boots to a prompt. I used genkernel.

Running the system with 1 x 8G RAM SODIMM installed is sprightly, and the system idles at less than 1%. Adding the second 8G RAM SODIMM (2 x 8 = 16G RAM) puts one core at 28+%. This is the only change.

The system boots to prompt in less than 30 seconds with one RAM module, and requires more than 6 minutes with two.

What is happening, and how can I run with full RAM?

Background:
I purchased the machine to run as a Hackintosh. I have OS X Mavericks installed on another disk to run natively, and that configuration idles with the full 16G RAM at 99+% idle. From 'uname -a' OS X reports 'x86_64' and other Hackintosh users have confirmed Mavericks is 64 bit only.

So the OS X experience says this hardware can indeed run 16G RAM (2x8 sticks) and has low CPU usage.

I'd appreciate any knowledge about... well, what is it? Different kernel compile settings?

Thanks in advance for any help.

Regards,
Bret

[anbc]

Barring hardware failures with your second channel... (i.e., memtest)

I'd ditch a generic genkernel and start from scratch with a self built kernel:

With this minimal kernel i'd have a starting point to troubleshoot the problem.
I'd compare my dmesg outputs with one channel then two channels of ram as a starting point.

[bwaldow]

[aCOSwt]

With your 16G physically installed, add mem=8G to your boot command line parameters and retry.
_________________

[bwaldow]

I am copying files or hand typing messages from the offending machine onto this one, which can actually access the Internet.

The offending machine (HP ProBook 4540s) has only type 83, ext4 formatted partitions. No LVM or RAID is configured.

I collected dmesg for several situations:

1x8G module: quick boot
2x8G module: very slow boot
2x8G module with "mem=8G" boot parameter: quick boot, and only lists 6612 of RAM from "free -m"

I removed the time signature from the lines with (e.g.):

[aCOSwt]

Hmmmm... the discovery of your webcam depends on the quantity of ram available ???

Well, are you sure the ram settings (timings + voltage) in your BIOS precisely match what your CRUCIAL are awaiting ?
_________________

[bwaldow]

[s_bernstein]

have you seen this:

http://h30434.www3.hp.com/t5/Hardware-Upgrades-Replacements/ProBook-4540s-Maximum-Supported-Memory/td-p/2527609

[bwaldow]

Yes, I have seen that.

However, whether HP changes their support terms or not has no effect on the laws of physics. The machine continues to idle at less than 1% in OS X with 2x8G RAM. I want to find out what need change in the Linux configuration to provide the same.

It's obviously happening, and for quite a few other people on the tonymacx86 forums.

So, there's something that needs correcting in the Linux set up. I'd like to find out what, so the machine is usable.

[s_bernstein]

Correct, but the laws of physics having an effect on HP's support terms. There is probably a reason why they've change it to 8GB. Maybe the chipset has problems with supporting 16GB. And OS X in your case is the odd man out. So, maybe OS X has some kind of workaround that is missing in linux and windows. Maybe OS X disables some of the cpu / chipset features to prevent this error. The BIOS settings are only in effect until a system driver change them - linux and windows usually respect the BIOS settings, OS X may be different.

[aCOSwt]

emerge sys-apps/dmidecode, run and report output in both situations.
What we could suspect here is some flacky power supply that significantly lowers the voltage applied to the sticks (and other misc devices such as usb) when plugging the second stick.
dmidecode should be capable of reporting what the BIOS believes.

EDIT, if you can also get sys-apps/lm-sensors running, please run and report as well.
_________________

[bwaldow]

dmidecode for 1x8G:

[s4e8]

enable CONFIG_MTRR, and check /proc/mtrr.

[NeddySeagoon]

bwaldow

[bwaldow]

[aCOSwt]

OK, back to my hypothesis that when you plug an additional stick, the voltage drops, I am puzzled by the fact that :
1/ lm-sensors does not report any values for voltages,
2/ the BIOS does not report voltage values for RAM and admits : Configured Clock Speed: Unknown

Considering that UEFI is supported, I would try booting in UEFI mode.
_________________

[bwaldow]

I switched the BIOS to use UEFI mode (with CSM).

Without CSM claimed it found no bootable drive. With CSM booted.

I noted no difference in behaviour between the 8G & 16G configurations. Both behaved as they have previously.

What would I have expected from this?

[mgranet]

[eccerr0r]

I thought that memtest86+ will also use SPD to detect DIMMs if available, is that true?
If it can read some of the bytes from SPD there's no reason why BIOS can't either.

I have a feeling HP might be doing something funny with the hardware, what happens if you limit RAM to something strange like 12GB?

I have an HP laptop as well with HM77 chipset, and wonderring if I will run into the same issue...then again I only have 4GB in the machine now. Likely next step is 12GB though.

Also memtest86+ also displays memory speed, is that also reporting speed differences between the 8G and 16G? How about actual test runtime, is it about double with 16G?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[chithanh]

[krinn]

And i don't see why it cannot be hardware issue, seeing HP lowering the max amount of memory in their sheet (so lowering their own product value), is certainly a clue it's really an hardware issue, else they would had provide bios update/patch... to fix software issue to not impact their own product value.
Hardware bugs or problem doesn't mean it has to be a crash result.

You should reconsider the only option that let you think HP didn't built a defective product (something that happen to any company).
OS/X : everyone here assume there's a way to solve your problem as OS/X is working, but as it has been prove already linux can also works with limiting to 8G the memory.
So try to look at OS/X and see if it works as you think : having 16G install and OS/X handling the 16G. Because if OS/X limit itself or have an option set to limit memory to 8G : there's no more magic going on.

[chithanh]

Most types of hardware issues would cause the first 8GB of memory to also exhibit problematic behaviour (ie. the problems would appear and disappear based on the amount of memory that is physically installed, not on the amount that the kernel uses per mem=... kernel parameter). It could be a chipset bug, but I consider that rather unlikely.

To me, it looks like there is a firmware/BIOS bug in the HP system (e.g. E820 reported memory regions are incorrect above 8G). And possibly they are not willing to fix it because that is expensive. So they just update the supported configurations to exclude non-working configurations.

[trismo]

hardware bug 16 GB run only with core i3

sell this notebook fast

EDIT :
core i5 i7 one memory channel can not access the memory bank

[bwaldow]