[Linux-ia64] Memory clearing at reboot

[Linux-ia64] Memory clearing at reboot

[John Baboval]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

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
jbaboval@missioncriticallinux.com

[-- Attachment #2: set_reset.c --]
[-- Type: text/x-csrc, Size: 1339 bytes --]

#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;
}

RE: [Linux-ia64] Memory clearing at reboot

[Saxena, Sunil]

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:baboval@mclinux.com]
Sent: Tuesday, August 22, 2000 11:50 AM
To: linux-ia64@linuxia64.org
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
jbaboval@missioncriticallinux.com

Re: [Linux-ia64] Memory clearing at reboot

[Gerrit.Huizenga]

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

> 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:baboval@mclinux.com]
> Sent: Tuesday, August 22, 2000 11:50 AM
> To: linux-ia64@linuxia64.org
> 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
> jbaboval@missioncriticallinux.com
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

Re: [Linux-ia64] Memory clearing at reboot

[Gerrit.Huizenga]

> > Having an ability to dump system memory to disk from an application
> > other than the kernel that just crashed is a major serviceability
> 
> Patrick O'Rourke said...
>
> Do you mean the equivalent of 'dd if=/dev/mem of=<some file>?  The problem
> with dumping memory from an application is that the kernel is still active,

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