Memory clearing at reboot

I have a small test program that I run at the EFI shell prompt to set an area of memory and then perform a warm reboot. After the reboot our BigSur still contains the values written, but the Lion is cleared to zero. (We check the contents with the mem command, and the ResetSystem() is called with the EfiResetWarm parameter.)

Does anyone know if there is a way to cause the Lion *not* to clear memory? Also, our Lion has newer firmware then the BigSur. Perhaps the newer firmware causes the reset?

If someone out there has a BigSur with the latest firmware/CPU rev., could you run my program and tell me if your machine resets it's memory? The source code is attached, and you can build it with gnu-efi-0.9.

Basically, you run the program and write down the address, and then when the machine comes back up type 'mem <Address>' and see if the memory is zero or not.

Not reseting memory makes taking kernel core dumps with our in-memory core dump patches MUCH easier! Thanks for any help,

--John
[email protected]

#include <efi.h>
#include <efilib.h>

EFI_STATUS
efi_main (EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)

{
	unsigned long bytes, mbytes;
	CHAR16 *prompt = W2U(L"Enter number of Mbytes: ");
	CHAR16 input[255];
	int input_len = 255;
	void *buffer;
	EFI_STATUS status;
	unsigned long i;
	long *temp;
	CHAR16 *ugh = W2U(L"test");

	InitializeLib(image, systab);

	Input(prompt, input, input_len);
	mbytes = Atoi(input);
	bytes = mbytes*1024*1024;

	Print (W2U(L"\nAllocating pool of %d bytes\n"), bytes);
	status = BS->AllocatePool(EfiBootServicesData, bytes, &buffer);

	if(status != EFI_SUCCESS) {
		Print(W2U(L"AllocatePool Failed with "));
		switch(status) {
			case EFI_OUT_OF_RESOURCES:
				Print(W2U(L"EFI_OUT_OF_RESOURCES\n"));
				break;
			case EFI_INVALID_PARAMETER:
				Print(W2U(L"EFI_INVALID_PARAMETER\n"));
				break;
			default:
				Print(W2U(L"%d\n"), status);
		}
		return status;
	}

	Print(W2U(L"Allocation succeeded. Buffer start :%016x\n"), buffer);

	Print(W2U(L"Setting Memory to 0xDEADBEEF"));
	for(i=0; i<bytes/8; i++) {
		temp = (long *)(buffer + i*8);
		*temp = (0xEFBEADDEEFBEADDE);
		if(((i*8)%(1024*1024)) == 0)
			Print(W2U(L"."));
	}

	Print(W2U(L"Press any key to reboot\n"));
        WaitForSingleEvent(ST->ConIn->WaitForKey, 0);
	RT->ResetSystem(EfiResetWarm, EFI_SUCCESS, 0, NULL);
		
	return EFI_SUCCESS;
}

Hi John,

Big Sur initializes it's memory only on power on; it does not do so on a soft reboot. The behavior you are seeing should continue on all build of our BIOS.

I am waiting for the answer on the Lion machine and do not know if Lion team can also enable this functionality. I will respond again once I have the answer. (By the way, my gut feelings says that they will not be able to enable this functionality.)

Thanks
Sunil

-----Original Message-----
From: John Baboval [mailto:[email protected]]
Sent: Tuesday, August 22, 2000 11:50 AM
To: [email protected]
Subject: [Linux-ia64] Memory clearing at reboot

I have a small test program that I run at the EFI shell prompt to set an area of memory and then perform a warm reboot. After the reboot our BigSur still contains the values written, but the Lion is cleared to zero. (We check the contents with the mem command, and the ResetSystem() is called with the EfiResetWarm parameter.)

Does anyone know if there is a way to cause the Lion *not* to clear memory? Also, our Lion has newer firmware then the BigSur. Perhaps the newer firmware causes the reset?

If someone out there has a BigSur with the latest firmware/CPU rev., could you run my program and tell me if your machine resets it's memory? The source code is attached, and you can build it with gnu-efi-0.9.

Basically, you run the program and write down the address, and then when the machine comes back up type 'mem <Address>' and see if the memory is zero or not.

Not reseting memory makes taking kernel core dumps with our in-memory core dump patches MUCH easier! Thanks for any help,

--John
[email protected]

Having an ability to dump system memory to disk from an application other than the kernel that just crashed is a major serviceability feature for larger systems. I don't see it as being as useful on a one or two proc system, but post-mortem analysis is typically considered a major feature for people running departmental or large servers (e.g. Lion sized).

Being only able to dump memory from inside of a dying kernel (a la NT) seems like a bad idea on a big box.

Of course, if this is BIOS specific, people building larger machines (e.g. 4 proc or larger) can hopefully avoid this problem (e.g. here at IBM ;-). It would be more useful though if this were a feature of the standard Lion BIOS as well.

gerrit

Not at all what I'm referring to - I mean instead it should be possible for, say, an EFI app to read system memory after the kernel has panic'd/shut down, and then copy that image to a disk for later kernel or hardware fault isolation. In larger sites and larger systems (where Itanium will more likely fit in its first couple of years) customers expect that the machine will be back in operation ASAP and the system can not afford to be down while people run diagnostics or try things to see if they can figure out what caused a kernel to crash.

On smaller systems, yes, debugging is also important; however, those systems can be typically co-opted for HW or SW debugging. The users are more tolerant of someone saying "Oh, try that again" or "Here's a debug kernel, see what happens". A large database customer running their business on a 16 processor machine is much less tolerant of such impact to their systems. Hence, being able to take a snapshot of the machine state at the time of failure and sending that information elsewhere for out of band debugging simplifies everyone's life.

Most operating systems tend to try to write an image to disk after the system has failed. As a result, a system with already corrupt memory is trying to set up DMA or programmed IO of all of memory to some disk subsystem, which tends to be a recipe for failure. It's like giving an accident victim the responsibility for self-diagnosis.

As far as which memory to dump, usually only kernel pages need to be dumped; however, that takes a slightly more sophisticated dump program and crash dump analyzer. Not impossible, but usually not a first generation choice (we've done exactly that with Sequent NUMA systems several years back).

gerrit