After starting with AMT too much memory is alocated by the Hardware

After starting with AMT too much memory is alocated by the Hardware

Hello everyone,

i use AMT to set a computers boot device before starting it. This worked without and problems for about a week.

Now whenever i do this the Hardware alocates about 60 to 80% of the RAM. Whenever i boot normaly (by switching it on via the power Switch) it does not do that and the RAM usage is normal.

Normal booting:

RAM usage without amt start up

Booting with AMT:

RAM after booting with AMT

Does anyone know how to fix this issue?

18 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Looking at your images, I would suspect your issue is with the ISO image that you are booting to. The Live ISO OS is only recognizing 1.4 GB vs 15.9 GB when you boot to your drive.

If your not booting to an image let me know

Joe

 

It should not be booting to an ISO image. I have 2 SSD in the Computer with a seperate Windows installations and 2 seperate configurations. There is no bootloader on the Computer, so before starting it I set the Primary SSD over AMT and then power it up.

What tool or script are you using to initiate the change of boot device?

If its a script you can PM me if you want.

Joe

I created a small C# program that uses the HLAPI and i can send you the code over PM, i just have not found the option to send a message to you.

Hi,

Does the problem happen with both images or just one image in particular?

My suspicion is that one of the OS images has been inadvertently configured to only use 1.4GB.

You can check by running msconfig, go to the Boot tab, Advanced options and check the Maximum Memory setting.

 

Ken

Hello,

the OS installation is okay and not the problem, if the same OS disk starts without AMT boot with 16GB RAM in Windows Taskmanger, but when start the PC and the same OS disk with intel AMT Script, in the Taskmanager you have only 1,4GB RAM and 14 GB for hardware reserved.

The error must be at the script or intel amt (9.1.41.3024 - Fujitsu D3348-B2 Motherboard with Intel Xeon E5-1650v4
Prozessor)

we have open a Support Call - Request:03004829

Hello Ken,

The problem happens with both images, when i start it by pushing the power button it starts and uses the full 16 GB of RAM. When I start it with the script it limits the RAM. I checked the boot option and there is no limit on Memory. 

The setup I am using:

  • Motherboard: Fujitsu D3348-B2
  • CPU: Xeon E5-1650v4
  • AMT: 9.1.41.3024

 

 

Hey Ben,

You can see in one of the above pictures that th physical memory is still 16GB but OS has only 1.5GB (15.6GB indicated as “Hardware Reserved”). This suggests that the BIOS didn’t allocate all DRAM to host.

I would update your BIOS and retest.

You can search for “hardware reserved memory fix” in google and see many such reported issues. See for example these sites (including some setting to change in host/BIOS that might help):

Joe

 

Hello Joseph,

BIOS is up to date (Version R1.11.0)

ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Products/Mainboards/Ind...

it's not a Windows problem, BIOS and Intel AMT is up to date.... what can we do?

Attachments: 

AttachmentSize
Downloadimage/png after update.PNG18.5 KB

this is the code ... change the boot hard disk and power on the PC... but only 1,4 GB RAM ... WHY ???

using System;

using Intel.Manageability;

using Intel.Manageability.BootControl;

using Intel.Manageability.Power;

using Intel.Manageability.Exceptions;

 

namespace BootControlSample

{

    class Program

    {

        static void Main(string[] args)

        {

            IAMTInstance amt;

            try

            {

                ConnectionInfoEX ci = new ConnectionInfoEX(IP, USER, PW, false,

                                                      string.Empty, ConnectionInfoEX.AuthMethod.Digest,

                                                      null, null, null);

                amt = AMTInstanceFactory.CreateEX(ci);

 

            }

            catch (ManageabilityException e)

            {

                Console.WriteLine(e.Message);

                return;

            }

           BootSource bootsource = new BootSource(BootSourceEnum.HardDriveBoot, (ushort)2);

            amt.BootControl.SetNextBoot(bootsource, BootOptionsFlags.NONE, FirmwareVerbosityEnum.NONE);

            amt.Power.Powerup();

            Console.ReadLine();

        }

    }

}

Attachments: 

Hey Stefan,

You mentioned, that this originally was working then stopped about a week in. Something must have changed on the client.... BIOS Update, OS update, driver update, etc...

At this point everything is pointing at a platform issue of some sort and not your code.

The only AMT related activity that I can come up with is doing a BIOS reset to defaults and a full Un-provision and re-provision. Then try and see if that doesn't fix it.

However as Intel AMT doesn't effect the memory allocation. So if this fixes it, A ticket should be put into Fujitsu if it occurs again

Joe

Hello,

i did some testing and think i should explain the situation more in detail with the gained knowledge:

The setup:

  • Each computer has 2 SSD's with a separate OS on each SSD. Each SSD is set up for a different task.
  • There is no boot loader on these computers, so whatever SSD is selected as the primary SSD (in BIOS) boots when pressing the power button.
  • I want to set the primary SSD of each computer remotely while they are powered off, so when I turn them on (also remotely) they boot up in the desired SSD

The reason for that requirement is that I want to utilize the same Hardware for different tasks. For example SSD 1 sorts books and SSD 2 calculates taxes. When i want to sort books i boot up SSD 1 when i need to do taxes i boot up SSD 2(I could not think of a better example). 

The Script I use:

I used one of the examples from the SDK and made a small script that recreates the problem:

using System;
using Intel.Manageability;
using Intel.Manageability.BootControl;
using Intel.Manageability.Power;
using Intel.Manageability.Exceptions;

namespace BootControlSample
{
    class Program
    {
        static void Main(string[] args)
        {
            IAMTInstance amt;
            try
            {
                ConnectionInfoEX ci = new ConnectionInfoEX(IP, USER, PW, false,
                                                      string.Empty, ConnectionInfoEX.AuthMethod.Digest,
                                                      null, null, null);
                amt = AMTInstanceFactory.CreateEX(ci);

            }
            catch (ManageabilityException e)
            {
                Console.WriteLine(e.Message);
                return;
            }
           BootSource bootsource = new BootSource(BootSourceEnum.HardDriveBoot, (ushort)INDEX);
           amt.BootControl.SetNextBoot(bootsource, BootOptionsFlags.NONE, FirmwareVerbosityEnum.NONE);
           amt.Power.Powerup();
           Console.ReadLine();
        }
    }
}

Variables in the script:

  • IP
  • USER
  • PW
  • INDEX

The Problem: 

While I was further investigating the problem i may found out why it appeared that it was working in the beginning.

  • The computer has SSD 1 set as the primary boot option (So when I would push the power button the computer boots into the OS on SSD 1).
  • I use the previously posted script to set the index to the index of SSD 1 and start the computer remotely with the script.
  • The computer boots up in the OS of SSD 1 and the 16 GB of RAM after fully available to use.
  • When i use the script with the index of SSD 2 (in the same setup) and power it up i get the RAM problems.

I use the same script in both cases, the only difference is the index for the SSD. This was also the reason why i thought it worked fine at the beginning. At the beginning we were mostly testing SSD 1 and then later switched to SSD 2 for testing that. Then the RAM problem started to occur.

Tests done so far:

  • Upgrade the BIOS to the most current one
  • Make sure there is no limit on the RAM
  • Tested with a 16 GB RAM from another manufacturer
  • We tested it with 2 x 16 GB RAM (see post #11 for screenshots).
  • Minimalistic script (see in this post the script above)

These are the unsuccessful tests i have done so far.

Open test:

  • Reset the BIOS

Hey Ben

Intel customer Service has picked up support for this issue, please continue working your issue through that channel

Joe

Hello,

we have delimit the problem:
 
Mesh commander just offers the possibility to select up to index 4, but with my script I can select more index and if I select index 5 I can boot the Windows from SSD 1 without any RAM Issues.
·         Index 1: No boot, text that ready “Reboot and select proper boot medium”
·         Index 2: Windows from SSD 2 - RAM problem
·         Index 3: Windows from SSD 1 – RAM problem
·         Index 4: Windows from SSD 1 – RAM problem

it is near that there is a problem with the index numbers.
how many index numbers can be used, there is possibly an index number that works for SSD2 also without RAM problem?

is this a bug in the amt firmware, or motherboard Manufacturer?

Wow, this is very interesting. I have never seen this before. I am the author of MeshCommander, I can certainly add more index (like 5 and 6) to help with testing. I don't know what is the limit on the index, I will have to try that.

As for who is responsible for this problem. In my opinion Intel AMT does not have power to control the boot process or system memory. It just gives instructions for how the BIOS should boot. So, I would probably start with the motherboard manufacturer. The BIOS people for that manufacturer would probably be the best to answer this.

Hello,

The Motherboard Manufacturer says:

I can also adjust the behavior on the Intel CRB (Customer Reference Board). This allows us to exclude FTS BIOS components as a source of error.
For troubleshooting, we are now dependent on AMI / Intel. Today a corresponding bugreport to AMI with all relevant information out.

 

We got a fix from Fujitsu solving the memory issue. After the fix it was possible to switch between the different SSDs without any memory issues. The fix we got will be included in the next official BIOS patch.

Thanks everyone for your help in solving the issue!

Leave a Comment

Please sign in to add a comment. Not a member? Join today