From info at yahoo.com  Wed Sep  2 09:17:10 2009
From: info at yahoo.com (UK NATIONAL LOTTERY DESK)
Date: Wed, 2 Sep 2009 06:17:10 -0700 (PDT)
Subject: No subject
Message-ID: <8878.41.220.75.3.1251897430.squirrel@webmail.cmaaccess.com>




UK NATIONAL LOTTERY DESK
Reference No: ACCU/2009-200

Good day Winner No: A333/ZZ5,

We use this medium to notify you of the lottery prize of 1.2 Million GBP
won by your email address, in this year's edition of the UK National
Lottery. Kindly contact Our payment Officer,  below via email:
He will brief you on steps to be taken for due processing and remittance
of your prize money.

FILL THE FORM BELOW:
*Name of Beneficiary:
*Address:
*Email Address:
*Occupation:
*Tel:
*Winning Details

Mr. Michael Brown,
Tel: +44-703-597-4026
Email: uknationallotterydesk at yahoo.com.hk

Signed,
Notification Department.



From laprimitiveprogram at live.com  Fri Sep  4 11:30:40 2009
From: laprimitiveprogram at live.com (LA PRIMITIVA PROGRAM)
Date: Fri, 04 Sep 2009 12:30:40 -0300
Subject: Gewinnanspruch !!!
Message-ID: <E1MjakK-0007pY-L4@host.dns-principal.com>

AUFMERKSAMKEIT: GEWINN2009

Bearbeitungsnummer: ESP-07MD/2009

Code:  EU-009/JU-15ES       

 Betreff: Jackpott der 3 Kategorie

 

                                                    

Hiermit informieren wir sie dar?ber, dass sie durch ihre teilnahme bei dem LA PRIMITIVA PROGRAM

September, 2009 mit ihrer namentlichen Registerung vom  31. August , 2009 unter der losnummer 231-353-76 mit der seriennummer 4979-69, automatisch f?r die losziehung der 3 (dritten) kategorie unter ihrer pers?nlichen GL?CKSNUMMER 17-05-37-53-11-20 angemeldet wurden.

 

In dem jackpott der 3  kategorie, befanden sich unglaubliche ? 10.000.000.00, EUROS (ZEHN MILLION EURO)!!!

Sie d?rfen sich zu den gl?cklichen Gewinnem dieses jackpotts z?hlen, und haben somit insgesamt?777,000(SIEBENHUNDERTTAUSEND,SIEBENHUNDERTUNDSIEBTIG EURO.) gewonnen, Herzlichen Gl?ckwunsch!!!

 

Ihr Gewinn wird momentan unter Ihrem Namen bzw unter Code: EU-009/JU-15ES, bei unserer Sicherheitsfirma verwart.

Da es sich bei Ihrem Gewinn um einen gr?sseren Betrag handelt, m?chten wir sie in Ihrem interesse darum bitten, diese Angaben, insbesondere ihren Code, niemandem anzuvertrauen,damit gewahrleistet ist, dass Sie den alleinigen anspruch,auf Ihren bereits oben genannten Gewinn haben.

 

Um Ihren Lotteriegewinn zu beanspruchen, wenden Sie sich bitte an Ihren pers?nlichen Betreuer,

Frank Gestoso  Ausland sacharbeiter MULTINACIONAL DE SEGUROS S.L ,

Anbei ein Anmeldeformular, bitte ausfullen und zuruck Per fax (Fax: 0034
94-0463744)oder per Email multinacionalde.seguros at inbox.es an die Versicherungsfirma

Senden:damit wir Ihnen ihren Gewinn auszahlen, bzw auf das konto Ihres Wunsches ?berweisen k?nnen.

 

Bitte beachten Sie, dass jeder Gewinn nur bis zum 22 Oktober. 2009 ausgeh?ndigt werden kann, da ansonsten ihr Anspruch auf das Geld ung?ltig ist, und danach Eigentum des MINISTERIO DE ECONOMIA Y HACIENDA WIRD!Ausserdem informieren wir Sie dar?ber, dass Ihr Gewinn bis zu Ihrer Anfrage bei der multinacional de seguros S.l unter ihrem Namen versichert wurde und daher ihrem Gewinn-Betreuer 10% ihres Gewinns zustehen aber erst nach erhalt das Gewinngeld.Die MULTINACIONAL DE SEGUROS. w?nscht Ihnen viel Spass mit Ihrem Gewinn!

Herzlich Gluckswunsch!

 

Hanelore Schmidt





From mohan at in.ibm.com  Mon Sep  7 01:14:07 2009
From: mohan at in.ibm.com (M. Mohan Kumar)
Date: Mon, 7 Sep 2009 10:44:07 +0530
Subject: [RFC] [PATCH] Write to HVC terminal from purgatory code
Message-ID: <20090907051407.GA2990@in.ibm.com>

Write to HVC terminal from purgatory code

Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to
serial console/VGA while executing the purgatory code.  Implement this
feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR
hypervisor call by printng to hvc console.


Signed-off-by: M. Mohan Kumar <mohan at in.ibm.com>
---
 kexec/arch/ppc64/fs2dt.c               |   47 +++++++++++++++++++++++++++++++-
 kexec/arch/ppc64/kexec-elf-ppc64.c     |    7 +++++
 kexec/arch/ppc64/kexec-ppc64.h         |    1 +
 purgatory/arch/ppc64/Makefile          |    1 +
 purgatory/arch/ppc64/console-ppc64.c   |   14 +++++++++
 purgatory/arch/ppc64/hvCall.S          |   28 +++++++++++++++++++
 purgatory/arch/ppc64/hvCall.h          |    8 +++++
 purgatory/arch/ppc64/purgatory-ppc64.c |    1 +
 8 files changed, 106 insertions(+), 1 deletions(-)
 create mode 100644 purgatory/arch/ppc64/hvCall.S
 create mode 100644 purgatory/arch/ppc64/hvCall.h

diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index b01ff86..bd9d36c 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -434,6 +434,9 @@ static void putnode(void)
 	if (!strcmp(basename,"/chosen/")) {
 		size_t cmd_len = 0;
 		char *param = NULL;
+		char filename[MAXPATH];
+		char buff[64];
+		int fd;
 
 		cmd_len = strlen(local_cmdline);
 		if (cmd_len != 0) {
@@ -446,7 +449,6 @@ static void putnode(void)
 
 		/* ... if not, grab root= from the old command line */
 		if (!param) {
-			char filename[MAXPATH];
 			FILE *fp;
 			char *last_cmdline = NULL;
 			char *old_param;
@@ -483,8 +485,51 @@ static void putnode(void)
 		dt += (cmd_len + 3)/4;
 
 		fprintf(stderr, "Modified cmdline:%s\n", local_cmdline);
+
+		/*
+		 * Determine the platform type/stdout type, so that purgatory
+		 * code can print 'I'm in purgatory' message. Currently only
+		 * pseries/hvcterminal is supported.
+		 */
+		strcpy(filename, pathname);
+		strcat(filename, "linux,stdout-path");
+		fd = open(filename, O_RDONLY);
+		if (fd == -1) {
+			printf("Unable to find linux,stdout-path, printing"
+					" from purgatory is diabled\n");
+			goto no_debug;
+		}
+		if (fstat(fd, &statbuf)) {
+			printf("Unable to stat linux,stdout-path, printing"
+					" from purgatory is diabled\n");
+			close(fd);
+			goto no_debug;
+		}
+		read(fd, buff, statbuf.st_size);
+		close(fd);
+		strcpy(filename, "/proc/device-tree/");
+		strcat(filename, buff);
+		strcat(filename, "/compatible");
+		fd = open(filename, O_RDONLY);
+		if (fd == -1) {
+			printf("Unable to find linux,stdout-path/compatible, "
+				" printing from purgatory is diabled\n");
+			goto no_debug;
+		}
+		if (fstat(fd, &statbuf)) {
+			printf("Unable to stat linux,stdout-path/compatible, "
+				" printing from purgatory is diabled\n");
+			close(fd);
+			goto no_debug;
+		}
+		read(fd, buff, statbuf.st_size);
+		if (!strcmp(buff, "hvterm1") ||
+					!strcmp(buff, "hvterm-protocol"))
+			my_debug = 1;
+		close(fd);
 	}
 
+no_debug:
 	for (i=0; i < numlist; i++) {
 		dp = namelist[i];
 		strcpy(dn, dp->d_name);
diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c b/kexec/arch/ppc64/kexec-elf-ppc64.c
index 21533cb..65fc42f 100644
--- a/kexec/arch/ppc64/kexec-elf-ppc64.c
+++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
@@ -41,6 +41,8 @@
 uint64_t initrd_base, initrd_size;
 unsigned char reuse_initrd = 0;
 const char *ramdisk;
+/* Used for enabling printing message from purgatory code */
+int my_debug = 0;
 
 int elf_ppc64_probe(const char *buf, off_t len)
 {
@@ -296,6 +298,8 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
 	toc_addr = my_r2(&info->rhdr);
 	elf_rel_set_symbol(&info->rhdr, "my_toc", &toc_addr, sizeof(toc_addr));
 
+	/* Set debug */
+	elf_rel_set_symbol(&info->rhdr, "debug", &my_debug, sizeof(my_debug));
 #ifdef DEBUG
 	my_kernel = 0;
 	my_dt_offset = 0;
@@ -304,6 +308,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
 	my_stack = 0;
 	toc_addr = 0;
 	my_run_at_load = 0;
+	my_debug = 0;
 
 	elf_rel_get_symbol(&info->rhdr, "kernel", &my_kernel, sizeof(my_kernel));
 	elf_rel_get_symbol(&info->rhdr, "dt_offset", &my_dt_offset,
@@ -317,6 +322,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
 	elf_rel_get_symbol(&info->rhdr, "stack", &my_stack, sizeof(my_stack));
 	elf_rel_get_symbol(&info->rhdr, "my_toc", &toc_addr,
 				sizeof(toc_addr));
+	elf_rel_get_symbol(&info->rhdr, "debug", &my_debug, sizeof(my_debug));
 
 	fprintf(stderr, "info->entry is %p\n", info->entry);
 	fprintf(stderr, "kernel is %llx\n", (unsigned long long)my_kernel);
@@ -329,6 +335,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
 	fprintf(stderr, "stack is %llx\n", (unsigned long long)my_stack);
 	fprintf(stderr, "toc_addr is %llx\n", (unsigned long long)toc_addr);
 	fprintf(stderr, "purgatory size is %zu\n", purgatory_size);
+	fprintf(stderr, "debug is %d\n", my_debug);
 #endif
 
 	for (i = 0; i < info->nr_segments; i++)
diff --git a/kexec/arch/ppc64/kexec-ppc64.h b/kexec/arch/ppc64/kexec-ppc64.h
index 920ac46..838c6da 100644
--- a/kexec/arch/ppc64/kexec-ppc64.h
+++ b/kexec/arch/ppc64/kexec-ppc64.h
@@ -20,6 +20,7 @@ unsigned long my_r2(const struct mem_ehdr *ehdr);
 extern uint64_t initrd_base, initrd_size;
 extern int max_memory_ranges;
 extern unsigned char reuse_initrd;
+extern int my_debug;
 
 /* boot block version 2 as defined by the linux kernel */
 struct bootblock {
diff --git a/purgatory/arch/ppc64/Makefile b/purgatory/arch/ppc64/Makefile
index aaa4046..40a9e99 100644
--- a/purgatory/arch/ppc64/Makefile
+++ b/purgatory/arch/ppc64/Makefile
@@ -3,6 +3,7 @@
 #
 
 ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/v2wrap.S
+ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/hvCall.S
 ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/purgatory-ppc64.c
 ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/console-ppc64.c
 ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/crashdump_backup.c
diff --git a/purgatory/arch/ppc64/console-ppc64.c b/purgatory/arch/ppc64/console-ppc64.c
index d6da7b3..78a233b 100644
--- a/purgatory/arch/ppc64/console-ppc64.c
+++ b/purgatory/arch/ppc64/console-ppc64.c
@@ -20,8 +20,22 @@
  */
 
 #include <purgatory.h>
+#include "hvCall.h"
+
+extern int debug;
 
 void putchar(int c)
 {
+	char buff[16];
+	unsigned long *lbuf = (unsigned long *)buff;
+
+	if (!debug) /* running on non pseries */
+		return;
+
+	if (c == '\n')
+		putchar('\r');
+
+	buff[0] = c;
+	plpar_hcall_norets(H_PUT_TERM_CHAR, 0, 1, lbuf[0], lbuf[1]);
 	return;
 }
diff --git a/purgatory/arch/ppc64/hvCall.S b/purgatory/arch/ppc64/hvCall.S
new file mode 100644
index 0000000..e401f81
--- /dev/null
+++ b/purgatory/arch/ppc64/hvCall.S
@@ -0,0 +1,28 @@
+/*
+ * This file contains the generic function to perform a call to the
+ * pSeries LPAR hypervisor.
+ *
+ * Created by M. Mohan Kumar (mohan at in.ibm.com)
+ * Copyright (C) IBM Corporation
+ * Taken from linux/arch/powerpc/platforms/pseries/hvCall.S
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define HVSC	.long 0x44000022
+.text
+	.machine ppc64
+.globl .plpar_hcall_norets
+.plpar_hcall_norets:
+	or	6,6,6			# medium low priority
+        mfcr	0
+        stw	0,8(1)
+
+        HVSC 				/* invoke the hypervisor */
+
+        lwz	0,8(1)
+        mtcrf	0xff,0
+        blr                             /* return r3 = status */
diff --git a/purgatory/arch/ppc64/hvCall.h b/purgatory/arch/ppc64/hvCall.h
new file mode 100644
index 0000000..187e24d
--- /dev/null
+++ b/purgatory/arch/ppc64/hvCall.h
@@ -0,0 +1,8 @@
+#ifndef HVCALL_H
+#define HVCALL_H
+
+#define H_PUT_TERM_CHAR	0x58
+
+long plpar_hcall_norets(unsigned long opcode, ...);
+
+#endif
diff --git a/purgatory/arch/ppc64/purgatory-ppc64.c b/purgatory/arch/ppc64/purgatory-ppc64.c
index 93f28d2..0b6d326 100644
--- a/purgatory/arch/ppc64/purgatory-ppc64.c
+++ b/purgatory/arch/ppc64/purgatory-ppc64.c
@@ -28,6 +28,7 @@ unsigned long stack = 0;
 unsigned long dt_offset = 0;
 unsigned long my_toc = 0;
 unsigned long kernel = 0;
+unsigned int debug = 0;
 
 void setup_arch(void)
 {
-- 
1.6.2.5



From horms at verge.net.au  Tue Sep  8 19:09:11 2009
From: horms at verge.net.au (Simon Horman)
Date: Wed, 9 Sep 2009 09:09:11 +1000
Subject: [RFC] [PATCH] Write to HVC terminal from purgatory code
In-Reply-To: <20090907051407.GA2990@in.ibm.com>
References: <20090907051407.GA2990@in.ibm.com>
Message-ID: <20090908230911.GE4075@verge.net.au>

On Mon, Sep 07, 2009 at 10:44:07AM +0530, M. Mohan Kumar wrote:
> Write to HVC terminal from purgatory code
> 
> Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to
> serial console/VGA while executing the purgatory code.  Implement this
> feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR
> hypervisor call by printng to hvc console.

This change seems reasonable to me, can any of the ppc people offer a review?

> Signed-off-by: M. Mohan Kumar <mohan at in.ibm.com>
> ---
>  kexec/arch/ppc64/fs2dt.c               |   47 +++++++++++++++++++++++++++++++-
>  kexec/arch/ppc64/kexec-elf-ppc64.c     |    7 +++++
>  kexec/arch/ppc64/kexec-ppc64.h         |    1 +
>  purgatory/arch/ppc64/Makefile          |    1 +
>  purgatory/arch/ppc64/console-ppc64.c   |   14 +++++++++
>  purgatory/arch/ppc64/hvCall.S          |   28 +++++++++++++++++++
>  purgatory/arch/ppc64/hvCall.h          |    8 +++++
>  purgatory/arch/ppc64/purgatory-ppc64.c |    1 +
>  8 files changed, 106 insertions(+), 1 deletions(-)
>  create mode 100644 purgatory/arch/ppc64/hvCall.S
>  create mode 100644 purgatory/arch/ppc64/hvCall.h
> 
> diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
> index b01ff86..bd9d36c 100644
> --- a/kexec/arch/ppc64/fs2dt.c
> +++ b/kexec/arch/ppc64/fs2dt.c
> @@ -434,6 +434,9 @@ static void putnode(void)
>  	if (!strcmp(basename,"/chosen/")) {
>  		size_t cmd_len = 0;
>  		char *param = NULL;
> +		char filename[MAXPATH];
> +		char buff[64];

                Is always 64 big enough?
		It seems a bit arbitrary.

> +		int fd;
>  
>  		cmd_len = strlen(local_cmdline);
>  		if (cmd_len != 0) {
> @@ -446,7 +449,6 @@ static void putnode(void)
>  
>  		/* ... if not, grab root= from the old command line */
>  		if (!param) {
> -			char filename[MAXPATH];
>  			FILE *fp;
>  			char *last_cmdline = NULL;
>  			char *old_param;
> @@ -483,8 +485,51 @@ static void putnode(void)
>  		dt += (cmd_len + 3)/4;
>  
>  		fprintf(stderr, "Modified cmdline:%s\n", local_cmdline);
> +
> +		/*
> +		 * Determine the platform type/stdout type, so that purgatory
> +		 * code can print 'I'm in purgatory' message. Currently only
> +		 * pseries/hvcterminal is supported.
> +		 */
> +		strcpy(filename, pathname);
> +		strcat(filename, "linux,stdout-path");
> +		fd = open(filename, O_RDONLY);
> +		if (fd == -1) {
> +			printf("Unable to find linux,stdout-path, printing"
> +					" from purgatory is diabled\n");
> +			goto no_debug;
> +		}
> +		if (fstat(fd, &statbuf)) {
> +			printf("Unable to stat linux,stdout-path, printing"
> +					" from purgatory is diabled\n");
> +			close(fd);
> +			goto no_debug;
> +		}
> +		read(fd, buff, statbuf.st_size);
> +		close(fd);
> +		strcpy(filename, "/proc/device-tree/");
> +		strcat(filename, buff);
> +		strcat(filename, "/compatible");
> +		fd = open(filename, O_RDONLY);
> +		if (fd == -1) {
> +			printf("Unable to find linux,stdout-path/compatible, "
> +				" printing from purgatory is diabled\n");
> +			goto no_debug;
> +		}
> +		if (fstat(fd, &statbuf)) {
> +			printf("Unable to stat linux,stdout-path/compatible, "
> +				" printing from purgatory is diabled\n");
> +			close(fd);
> +			goto no_debug;
> +		}
> +		read(fd, buff, statbuf.st_size);
> +		if (!strcmp(buff, "hvterm1") ||
> +					!strcmp(buff, "hvterm-protocol"))
> +			my_debug = 1;
> +		close(fd);
>  	}
>  
> +no_debug:
>  	for (i=0; i < numlist; i++) {
>  		dp = namelist[i];
>  		strcpy(dn, dp->d_name);
> diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c b/kexec/arch/ppc64/kexec-elf-ppc64.c
> index 21533cb..65fc42f 100644
> --- a/kexec/arch/ppc64/kexec-elf-ppc64.c
> +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
> @@ -41,6 +41,8 @@
>  uint64_t initrd_base, initrd_size;
>  unsigned char reuse_initrd = 0;
>  const char *ramdisk;
> +/* Used for enabling printing message from purgatory code */
> +int my_debug = 0;
>  
>  int elf_ppc64_probe(const char *buf, off_t len)
>  {
> @@ -296,6 +298,8 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
>  	toc_addr = my_r2(&info->rhdr);
>  	elf_rel_set_symbol(&info->rhdr, "my_toc", &toc_addr, sizeof(toc_addr));
>  
> +	/* Set debug */
> +	elf_rel_set_symbol(&info->rhdr, "debug", &my_debug, sizeof(my_debug));
>  #ifdef DEBUG
>  	my_kernel = 0;
>  	my_dt_offset = 0;
> @@ -304,6 +308,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
>  	my_stack = 0;
>  	toc_addr = 0;
>  	my_run_at_load = 0;
> +	my_debug = 0;
>  
>  	elf_rel_get_symbol(&info->rhdr, "kernel", &my_kernel, sizeof(my_kernel));
>  	elf_rel_get_symbol(&info->rhdr, "dt_offset", &my_dt_offset,
> @@ -317,6 +322,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
>  	elf_rel_get_symbol(&info->rhdr, "stack", &my_stack, sizeof(my_stack));
>  	elf_rel_get_symbol(&info->rhdr, "my_toc", &toc_addr,
>  				sizeof(toc_addr));
> +	elf_rel_get_symbol(&info->rhdr, "debug", &my_debug, sizeof(my_debug));
>  
>  	fprintf(stderr, "info->entry is %p\n", info->entry);
>  	fprintf(stderr, "kernel is %llx\n", (unsigned long long)my_kernel);
> @@ -329,6 +335,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len,
>  	fprintf(stderr, "stack is %llx\n", (unsigned long long)my_stack);
>  	fprintf(stderr, "toc_addr is %llx\n", (unsigned long long)toc_addr);
>  	fprintf(stderr, "purgatory size is %zu\n", purgatory_size);
> +	fprintf(stderr, "debug is %d\n", my_debug);
>  #endif
>  
>  	for (i = 0; i < info->nr_segments; i++)
> diff --git a/kexec/arch/ppc64/kexec-ppc64.h b/kexec/arch/ppc64/kexec-ppc64.h
> index 920ac46..838c6da 100644
> --- a/kexec/arch/ppc64/kexec-ppc64.h
> +++ b/kexec/arch/ppc64/kexec-ppc64.h
> @@ -20,6 +20,7 @@ unsigned long my_r2(const struct mem_ehdr *ehdr);
>  extern uint64_t initrd_base, initrd_size;
>  extern int max_memory_ranges;
>  extern unsigned char reuse_initrd;
> +extern int my_debug;
>  
>  /* boot block version 2 as defined by the linux kernel */
>  struct bootblock {
> diff --git a/purgatory/arch/ppc64/Makefile b/purgatory/arch/ppc64/Makefile
> index aaa4046..40a9e99 100644
> --- a/purgatory/arch/ppc64/Makefile
> +++ b/purgatory/arch/ppc64/Makefile
> @@ -3,6 +3,7 @@
>  #
>  
>  ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/v2wrap.S
> +ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/hvCall.S
>  ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/purgatory-ppc64.c
>  ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/console-ppc64.c
>  ppc64_PURGATORY_SRCS += purgatory/arch/ppc64/crashdump_backup.c
> diff --git a/purgatory/arch/ppc64/console-ppc64.c b/purgatory/arch/ppc64/console-ppc64.c
> index d6da7b3..78a233b 100644
> --- a/purgatory/arch/ppc64/console-ppc64.c
> +++ b/purgatory/arch/ppc64/console-ppc64.c
> @@ -20,8 +20,22 @@
>   */
>  
>  #include <purgatory.h>
> +#include "hvCall.h"
> +
> +extern int debug;
>  
>  void putchar(int c)
>  {
> +	char buff[16];
> +	unsigned long *lbuf = (unsigned long *)buff;
> +
> +	if (!debug) /* running on non pseries */
> +		return;
> +
> +	if (c == '\n')
> +		putchar('\r');
> +
> +	buff[0] = c;
> +	plpar_hcall_norets(H_PUT_TERM_CHAR, 0, 1, lbuf[0], lbuf[1]);
>  	return;
>  }
> diff --git a/purgatory/arch/ppc64/hvCall.S b/purgatory/arch/ppc64/hvCall.S
> new file mode 100644
> index 0000000..e401f81
> --- /dev/null
> +++ b/purgatory/arch/ppc64/hvCall.S
> @@ -0,0 +1,28 @@
> +/*
> + * This file contains the generic function to perform a call to the
> + * pSeries LPAR hypervisor.
> + *
> + * Created by M. Mohan Kumar (mohan at in.ibm.com)
> + * Copyright (C) IBM Corporation
> + * Taken from linux/arch/powerpc/platforms/pseries/hvCall.S
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#define HVSC	.long 0x44000022
> +.text
> +	.machine ppc64
> +.globl .plpar_hcall_norets
> +.plpar_hcall_norets:
> +	or	6,6,6			# medium low priority
> +        mfcr	0
> +        stw	0,8(1)
> +
> +        HVSC 				/* invoke the hypervisor */
> +
> +        lwz	0,8(1)
> +        mtcrf	0xff,0
> +        blr                             /* return r3 = status */
> diff --git a/purgatory/arch/ppc64/hvCall.h b/purgatory/arch/ppc64/hvCall.h
> new file mode 100644
> index 0000000..187e24d
> --- /dev/null
> +++ b/purgatory/arch/ppc64/hvCall.h
> @@ -0,0 +1,8 @@
> +#ifndef HVCALL_H
> +#define HVCALL_H
> +
> +#define H_PUT_TERM_CHAR	0x58
> +
> +long plpar_hcall_norets(unsigned long opcode, ...);
> +
> +#endif
> diff --git a/purgatory/arch/ppc64/purgatory-ppc64.c b/purgatory/arch/ppc64/purgatory-ppc64.c
> index 93f28d2..0b6d326 100644
> --- a/purgatory/arch/ppc64/purgatory-ppc64.c
> +++ b/purgatory/arch/ppc64/purgatory-ppc64.c
> @@ -28,6 +28,7 @@ unsigned long stack = 0;
>  unsigned long dt_offset = 0;
>  unsigned long my_toc = 0;
>  unsigned long kernel = 0;
> +unsigned int debug = 0;
>  
>  void setup_arch(void)
>  {
> -- 
> 1.6.2.5


From khalid_aziz at hp.com  Wed Sep  9 15:16:41 2009
From: khalid_aziz at hp.com (Khalid Aziz)
Date: Wed, 09 Sep 2009 13:16:41 -0600
Subject: [PATCH] Fix a problem caused by autoconf 2.64 which redefined
	AC_MSG_ERROR
Message-ID: <1252523801.31487.95.camel@localhost>

[PATCH] Fix a problem caused by autoconf 2.64 which redefined
AC_MSG_ERROR

autoconf 2.64 redefined AC_MSG_ERROR and now a ";" is required at the
end of AC_MSG_ERROR macro invocation in configure.ac. Absence of this
";" causes an "unexpected end of file" message when configure script
generated by autoconf is run. This patch adds the ";" in right places. I
have verified that configure.ac still works fine after these changes
with autoconf 2.63 and 2.61.

Signed-off-by: Khalid Aziz <khalid.aziz at hp.com>
---
 configure.ac |   34 +++++++++++++++++-----------------
 1 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4aade87..fc2a166 100644
--- a/configure.ac
+++ b/configure.ac
@@ -150,23 +150,23 @@ if test "$with_xen" = yes ; then
 fi
 
 dnl ---Sanity checks
-if test "$CC"      = "no"; then AC_MSG_ERROR([cc not found]) fi
-if test "$CPP"     = "no"; then AC_MSG_ERROR([cpp not found]) fi
-if test "$LD"      = "no"; then AC_MSG_ERROR([ld not found]) fi
-if test "$AS"      = "no"; then AC_MSG_ERROR([as not found]) fi
-if test "$OBJCOPY" = "no"; then	AC_MSG_ERROR([objcopy not found]) fi
-if test "$AR"      = "no"; then	AC_MSG_ERROR([ar not found]) fi
-
-if test "$MKDIR"   = "no"; then AC_MSG_ERROR([ mkdir not found]) fi 
-if test "$RM"      = "no"; then AC_MSG_ERROR([ rm not found]) fi    
-if test "$CP"      = "no"; then AC_MSG_ERROR([ cp not found]) fi    
-if test "$LN"      = "no"; then AC_MSG_ERROR([ ln not found]) fi    
-if test "$TAR"     = "no"; then AC_MSG_ERROR([ tar not found]) fi   
-if test "$RPM"     = "no"; then AC_MSG_ERROR([ rpm not found]) fi   
-if test "$SED"     = "no"; then AC_MSG_ERROR([ sed not found]) fi   
-if test "$FIND"    = "no"; then AC_MSG_ERROR([ find not found]) fi  
-if test "$XARGS"   = "no"; then AC_MSG_ERROR([ xargs not found]) fi 
-if test "$DIRNAME" = "no"; then AC_MSG_ERROR([ dirname not found]) fi 
+if test "$CC"      = "no"; then AC_MSG_ERROR([cc not found]); fi
+if test "$CPP"     = "no"; then AC_MSG_ERROR([cpp not found]); fi
+if test "$LD"      = "no"; then AC_MSG_ERROR([ld not found]); fi
+if test "$AS"      = "no"; then AC_MSG_ERROR([as not found]); fi
+if test "$OBJCOPY" = "no"; then	AC_MSG_ERROR([objcopy not found]); fi
+if test "$AR"      = "no"; then	AC_MSG_ERROR([ar not found]); fi
+
+if test "$MKDIR"   = "no"; then AC_MSG_ERROR([ mkdir not found]); fi 
+if test "$RM"      = "no"; then AC_MSG_ERROR([ rm not found]); fi    
+if test "$CP"      = "no"; then AC_MSG_ERROR([ cp not found]); fi    
+if test "$LN"      = "no"; then AC_MSG_ERROR([ ln not found]); fi    
+if test "$TAR"     = "no"; then AC_MSG_ERROR([ tar not found]); fi   
+if test "$RPM"     = "no"; then AC_MSG_ERROR([ rpm not found]); fi   
+if test "$SED"     = "no"; then AC_MSG_ERROR([ sed not found]); fi   
+if test "$FIND"    = "no"; then AC_MSG_ERROR([ find not found]); fi  
+if test "$XARGS"   = "no"; then AC_MSG_ERROR([ xargs not found]); fi 
+if test "$DIRNAME" = "no"; then AC_MSG_ERROR([ dirname not found]); fi 
 
 dnl ---Output variables...
 AC_SUBST([BUILD_CC])
-- 
1.5.6.3


-- 
====================================================================
Khalid Aziz                            Telco Platform Software, MOST
(970)898-9214                                        Hewlett-Packard
khalid.aziz at hp.com                                  Fort Collins, CO

"The Linux kernel is subject to relentless development" 
                                - Alessandro Rubini



From horms at verge.net.au  Wed Sep  9 20:48:46 2009
From: horms at verge.net.au (Simon Horman)
Date: Thu, 10 Sep 2009 10:48:46 +1000
Subject: [PATCH] Fix a problem caused by autoconf 2.64 which redefined
	AC_MSG_ERROR
In-Reply-To: <1252523801.31487.95.camel@localhost>
References: <1252523801.31487.95.camel@localhost>
Message-ID: <20090910004844.GE17909@verge.net.au>

On Wed, Sep 09, 2009 at 01:16:41PM -0600, Khalid Aziz wrote:
> [PATCH] Fix a problem caused by autoconf 2.64 which redefined
> AC_MSG_ERROR
> 
> autoconf 2.64 redefined AC_MSG_ERROR and now a ";" is required at the
> end of AC_MSG_ERROR macro invocation in configure.ac. Absence of this
> ";" causes an "unexpected end of file" message when configure script
> generated by autoconf is run. This patch adds the ";" in right places. I
> have verified that configure.ac still works fine after these changes
> with autoconf 2.63 and 2.61.

Thanks, applied.



From Daniel.Jones at sus72.suidc.com  Sun Sep 13 19:11:42 2009
From: Daniel.Jones at sus72.suidc.com (Daniel Jones)
Date: Mon, 14 Sep 2009 08:11:42 +0900
Subject: Mystery Shoppers Needed
Message-ID: <200909132311.n8DNBgYX004856@sus72.suidc.com>

=PLS READ CAREFULLY, THIS MIGHT BE THE MOST IMPORTANT MESSAGE EVER=

I am sure you are sick and tired of all the money-making scams on the web.
If you're looking for the real deal then pls read carefully, this may be the
most important message you'll ever read online. Hundreds of organizations
throughout the US, UK, Pueto Rico & Canada utilize the services of Secret
Shoppers to visit their hotels, stores, restaurants, etc. as regular
customers for the purpose of reporting on their organizations service
levels, quality of goods, and overall appeal to the average consumer. Many
companies regularly use the services of Secret Shoppers to ensure and guage
whether or not they are competitive, are offering quality service and
products, and are maintaining an overall appeal to general
 consumers.

As a Secret Consumer/Shopper, you will have the opportunity to eat at fine
restaurants, be a guest at quality hotels, attend movie theaters, make
purchases at retail stores, etc. as a secret consumer, all for free and
while being paid for your efforts.

We have an excellent starting pay with flexible schedules. No experience is
necessary. Many Shoppers earn $300- $3000 a week. You will earn a lot just
for doing what you usually do for free anyway (15-20 minutes of shopping
time in many cases). You also get paid to shop, keep what you buy, get paid
to have fun, get paid to give your opinion, See the latest movies for free,
be an undercover consumer and report on your experiences.

Secret shopping is a great way to earn extra cash or a full time income for
those professionals already working in or as: Computer Operator, Teacher,
Data Entry, Office Management, Support Analyst, Office Manager,
 Cashier,
Retail, Wholesale, Waiter or Waitress, Line Cook, Food and Beverage, College
Student, The Warehouse Industry, Call Center Supervisor, Sales, Marketing,
Network Administrator, Customer Relations, Entertainment, Human Resources,
Customer Support, Technical Support, Secretary, Receptionist, Customer
Service, Customer Representative, Paralegal, Filing Clerk, Office Associate.

If interested, pls fill in the details below and send all applications to
(jcshopperpay at aol.com)
1. Full Names:
2. Full Address:
3. Phone Numbers:
4. Age
5. Sex
Yours Sincerely
Daniel Jones
jcshopperpay at aol.com





From B04597 at freescale.com  Tue Sep 15 23:06:34 2009
From: B04597 at freescale.com (Lai Weilin-B04597)
Date: Wed, 16 Sep 2009 11:06:34 +0800
Subject: How to build the kexec too for ARM11 using the cross compiler.
Message-ID: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>

Hi,
I am trying to build kexec tool for ARM11.  I can't see any doc that
helps to configure. The cross compiler is used, and I tried the
following configure option, 
./configure arm --prefix=/usr --build=arm-none-linux-gnueabi
--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi
but failed.
Anyone can help ?
 
 
William Lai
021-28937152
15921256383
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090916/bddab155/attachment.htm>

From horms at verge.net.au  Tue Sep 15 23:51:32 2009
From: horms at verge.net.au (Simon Horman)
Date: Wed, 16 Sep 2009 13:51:32 +1000
Subject: How to build the kexec too for ARM11 using the cross compiler.
In-Reply-To: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
Message-ID: <20090916035131.GO24467@verge.net.au>

On Wed, Sep 16, 2009 at 11:06:34AM +0800, Lai Weilin-B04597 wrote:
> Hi,
> I am trying to build kexec tool for ARM11.  I can't see any doc that
> helps to configure. The cross compiler is used, and I tried the
> following configure option, 
> ./configure arm --prefix=/usr --build=arm-none-linux-gnueabi
> --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi
> but failed.
> Anyone can help ?

Hi,

When cross-compiling for arm the following works for me:

autoheader
autoconf
./configure --host=arm-unknown-linux-gnu

In what way is what you are trying failing?
And are you trying to build natively or cross-compile?



From B04597 at freescale.com  Wed Sep 16 02:05:58 2009
From: B04597 at freescale.com (Lai Weilin-B04597)
Date: Wed, 16 Sep 2009 14:05:58 +0800
Subject: How to build the kexec too for ARM11 using the cross compiler.
In-Reply-To: <20090916035131.GO24467@verge.net.au>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
	<20090916035131.GO24467@verge.net.au>
Message-ID: <E99B4DCB8B5A0241832DBF4FCB7C813A7D02CF@zch01exm27.fsl.freescale.net>

I am trying to build cross-compile, on a ubuntu server. 
After I read through the INSTALL file, I came up the following configure option.
./configure arm --prefix=/usr --build=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --host=i686-pc-linux-gnu
And after setting the environment variables, such as CC, BUILD_CC and etc., it works.

After the successful build, I tried the kexec out using the following command.
#kexec -l /unit_tests/zImage_mx35_430 --append="noinitrd co
nsole=ttymxc0,115200 root=/dev/nfs nfsroot=10.192.225.211:/tools/rootfs/b04597/r
ootfs_mx35 rw ip=dhcp no_console_suspend"

After execute the a currently loaded kernel, error occur again.
The log is as below.

MXC Watchdog # 0 shutdown
Starting new kernel
Bye!
Uncompressing Linux...........................................................................................................................

crc error

 -- System halted


BTW, your configure works fine for ARM on my side too.
Thanks...

-----Original Message-----
From: Simon Horman [mailto:horms at verge.net.au] 
Sent: 2009?9?16? 11:52
To: Lai Weilin-B04597
Cc: kexec at lists.infradead.org
Subject: Re: How to build the kexec too for ARM11 using the cross compiler.

On Wed, Sep 16, 2009 at 11:06:34AM +0800, Lai Weilin-B04597 wrote:
> Hi,
> I am trying to build kexec tool for ARM11.  I can't see any doc that 
> helps to configure. The cross compiler is used, and I tried the 
> following configure option, ./configure arm --prefix=/usr 
> --build=arm-none-linux-gnueabi --host=i686-pc-linux-gnu 
> --target=arm-none-linux-gnueabi but failed.
> Anyone can help ?

Hi,

When cross-compiling for arm the following works for me:

autoheader
autoconf
./configure --host=arm-unknown-linux-gnu

In what way is what you are trying failing?
And are you trying to build natively or cross-compile?




From mohan at in.ibm.com  Thu Sep 17 05:06:02 2009
From: mohan at in.ibm.com (M. Mohan Kumar)
Date: Thu, 17 Sep 2009 14:36:02 +0530
Subject: [RFC] [PATCH] Write to HVC terminal from purgatory code
In-Reply-To: <20090908230911.GE4075@verge.net.au>
References: <20090907051407.GA2990@in.ibm.com>
	<20090908230911.GE4075@verge.net.au>
Message-ID: <200909171436.02165.mohan@in.ibm.com>

> On Mon, Sep 07, 2009 at 10:44:07AM +0530, M. Mohan Kumar wrote:
> > Write to HVC terminal from purgatory code
> >
> > Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to
> > serial console/VGA while executing the purgatory code.  Implement this
> > feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR
> > hypervisor call by printng to hvc console.
>
> This change seems reasonable to me, can any of the ppc people offer a
> review?
>

Sorry, I forgot to mention that this patch is tested on POWER5 (under 
hypervisor) and POWER4 Full System partition mode (under non-hypervisor)

Regards,
M. Mohan Kumar.


From michael at ellerman.id.au  Thu Sep 17 07:54:40 2009
From: michael at ellerman.id.au (Michael Ellerman)
Date: Thu, 17 Sep 2009 21:54:40 +1000
Subject: [RFC] [PATCH] Write to HVC terminal from purgatory code
In-Reply-To: <20090907051407.GA2990@in.ibm.com>
References: <20090907051407.GA2990@in.ibm.com>
Message-ID: <1253188480.6156.90.camel@concordia>

On Mon, 2009-09-07 at 10:44 +0530, M. Mohan Kumar wrote:
> Write to HVC terminal from purgatory code
> 
> Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to
> serial console/VGA while executing the purgatory code.  Implement this
> feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR
> hypervisor call by printng to hvc console.


Hi Mohan, just a few comments ...

> diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
> index b01ff86..bd9d36c 100644
> --- a/kexec/arch/ppc64/fs2dt.c
> +++ b/kexec/arch/ppc64/fs2dt.c
> @@ -434,6 +434,9 @@ static void putnode(void)
>  	if (!strcmp(basename,"/chosen/")) {
>  		size_t cmd_len = 0;
>  		char *param = NULL;
> +		char filename[MAXPATH];
> +		char buff[64];
> +		int fd;
>  
>  		cmd_len = strlen(local_cmdline);
>  		if (cmd_len != 0) {
> @@ -446,7 +449,6 @@ static void putnode(void)
>  
>  		/* ... if not, grab root= from the old command line */
>  		if (!param) {
> -			char filename[MAXPATH];
>  			FILE *fp;
>  			char *last_cmdline = NULL;
>  			char *old_param;
> @@ -483,8 +485,51 @@ static void putnode(void)
>  		dt += (cmd_len + 3)/4;
>  
>  		fprintf(stderr, "Modified cmdline:%s\n", local_cmdline);
> +
> +		/*
> +		 * Determine the platform type/stdout type, so that purgatory
> +		 * code can print 'I'm in purgatory' message. Currently only
> +		 * pseries/hvcterminal is supported.
> +		 */
> +		strcpy(filename, pathname);
> +		strcat(filename, "linux,stdout-path");

strncat() ?

> +		fd = open(filename, O_RDONLY);
> +		if (fd == -1) {
> +			printf("Unable to find linux,stdout-path, printing"
> +					" from purgatory is diabled\n");
> +			goto no_debug;
> +		}
> +		if (fstat(fd, &statbuf)) {
> +			printf("Unable to stat linux,stdout-path, printing"
> +					" from purgatory is diabled\n");
> +			close(fd);
> +			goto no_debug;
> +		}
> +		read(fd, buff, statbuf.st_size);

Be nice to check it's going to fit in buff here.

> +		close(fd);
> +		strcpy(filename, "/proc/device-tree/");
> +		strcat(filename, buff);
> +		strcat(filename, "/compatible");

strncpy / strncat.

> +		fd = open(filename, O_RDONLY);
> +		if (fd == -1) {
> +			printf("Unable to find linux,stdout-path/compatible, "
> +				" printing from purgatory is diabled\n");

You may as well print the actual path here, seeing as you have it.

> +			goto no_debug;
> +		}
> +		if (fstat(fd, &statbuf)) {
> +			printf("Unable to stat linux,stdout-path/compatible, "
> +				" printing from purgatory is diabled\n");
> +			close(fd);
> +			goto no_debug;
> +		}
> +		read(fd, buff, statbuf.st_size);
> +		if (!strcmp(buff, "hvterm1") ||
> +					!strcmp(buff, "hvterm-protocol"))
> +			my_debug = 1;

I have a personal hatred for variables called my_foo, but that's just
personal taste I guess :)

> +		close(fd);
>  	}
>  
> +no_debug:
>  	for (i=0; i < numlist; i++) {
>  		dp = namelist[i];
>  		strcpy(dn, dp->d_name);

> diff --git a/purgatory/arch/ppc64/console-ppc64.c b/purgatory/arch/ppc64/console-ppc64.c
> index d6da7b3..78a233b 100644
> --- a/purgatory/arch/ppc64/console-ppc64.c
> +++ b/purgatory/arch/ppc64/console-ppc64.c
> @@ -20,8 +20,22 @@
>   */
>  
>  #include <purgatory.h>
> +#include "hvCall.h"
> +
> +extern int debug;
>  
>  void putchar(int c)
>  {
> +	char buff[16];
> +	unsigned long *lbuf = (unsigned long *)buff;
> +
> +	if (!debug) /* running on non pseries */
> +		return;
> +
> +	if (c == '\n')
> +		putchar('\r');
> +
> +	buff[0] = c;
> +	plpar_hcall_norets(H_PUT_TERM_CHAR, 0, 1, lbuf[0], lbuf[1]);
>  	return;
>  }
> diff --git a/purgatory/arch/ppc64/hvCall.S b/purgatory/arch/ppc64/hvCall.S
> new file mode 100644
> index 0000000..e401f81
> --- /dev/null
> +++ b/purgatory/arch/ppc64/hvCall.S
> @@ -0,0 +1,28 @@
> +/*
> + * This file contains the generic function to perform a call to the
> + * pSeries LPAR hypervisor.
> + *
> + * Created by M. Mohan Kumar (mohan at in.ibm.com)
> + * Copyright (C) IBM Corporation
> + * Taken from linux/arch/powerpc/platforms/pseries/hvCall.S
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#define HVSC	.long 0x44000022
> +.text
> +	.machine ppc64
> +.globl .plpar_hcall_norets
> +.plpar_hcall_norets:
> +	or	6,6,6			# medium low priority
> +        mfcr	0
> +        stw	0,8(1)
> +
> +        HVSC 				/* invoke the hypervisor */
> +
> +        lwz	0,8(1)
> +        mtcrf	0xff,0
> +        blr                             /* return r3 = status */

It's much easier to read if you use r0, r1 etc.


cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090917/70ae6afb/attachment.sig>

From B04597 at freescale.com  Fri Sep 18 02:01:10 2009
From: B04597 at freescale.com (Lai Weilin-B04597)
Date: Fri, 18 Sep 2009 14:01:10 +0800
Subject: The failure of the KEXEC on ARM1136
In-Reply-To: <20090916035131.GO24467@verge.net.au>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
	<20090916035131.GO24467@verge.net.au>
Message-ID: <E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>

Hi Simon,
I am trying to get kexec working on an ARM1136 using the 2.0.1 version of the KEXEC.

The loading seems to work ok. On "kexec -e", I see:

Starting new kernel
Uncompressing Linux...................................................................................................

crc error

 -- System halted

Have you ever seen this kind of failure ? 


Best Regards.
William Lai
021-28937152
15921256383
 

-----Original Message-----
From: Simon Horman [mailto:horms at verge.net.au] 
Sent: 2009?9?16? 11:52
To: Lai Weilin-B04597
Cc: kexec at lists.infradead.org
Subject: Re: How to build the kexec too for ARM11 using the cross compiler.

On Wed, Sep 16, 2009 at 11:06:34AM +0800, Lai Weilin-B04597 wrote:
> Hi,
> I am trying to build kexec tool for ARM11.  I can't see any doc that 
> helps to configure. The cross compiler is used, and I tried the 
> following configure option, ./configure arm --prefix=/usr 
> --build=arm-none-linux-gnueabi --host=i686-pc-linux-gnu 
> --target=arm-none-linux-gnueabi but failed.
> Anyone can help ?

Hi,

When cross-compiling for arm the following works for me:

autoheader
autoconf
./configure --host=arm-unknown-linux-gnu

In what way is what you are trying failing?
And are you trying to build natively or cross-compile?




From horms at verge.net.au  Fri Sep 18 02:52:20 2009
From: horms at verge.net.au (Simon Horman)
Date: Fri, 18 Sep 2009 16:52:20 +1000
Subject: The failure of the KEXEC on ARM1136
In-Reply-To: <E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
	<20090916035131.GO24467@verge.net.au>
	<E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>
Message-ID: <20090918065220.GA17940@verge.net.au>

On Fri, Sep 18, 2009 at 02:01:10PM +0800, Lai Weilin-B04597 wrote:
> Hi Simon,
> I am trying to get kexec working on an ARM1136 using the 2.0.1 version of the KEXEC.
> 
> The loading seems to work ok. On "kexec -e", I see:
> 
> Starting new kernel
> Uncompressing Linux...................................................................................................
> 
> crc error
> 
>  -- System halted
> 
> Have you ever seen this kind of failure ? 

Not that I recall. The only ARM hardware I have is a Treo (i can check the
model when I get home). Would it be worth me trying to reproduce it on that hw?



From johnson.laylor06 at gmail.com  Fri Sep 18 13:23:19 2009
From: johnson.laylor06 at gmail.com (Johnson Taylor)
Date: Sat, 19 Sep 2009 01:23:19 +0800 (MYT)
Subject: For your immediate attention
Message-ID: <b2269a4652d43a12008bff1d9c900774.squirrel@www.cempaka.edu.my>





From wilbur512 at gmail.com  Sat Sep 19 11:06:30 2009
From: wilbur512 at gmail.com (wilbur.chan)
Date: Sat, 19 Sep 2009 23:06:30 +0800
Subject: The failure of the KEXEC on ARM1136
In-Reply-To: <E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
	<20090916035131.GO24467@verge.net.au>
	<E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>
Message-ID: <e997b7420909190806l28baba26y9f6b4e4679248092@mail.gmail.com>

2009/9/18 Lai Weilin-B04597 <B04597 at freescale.com>:
> Hi Simon,
> I am trying to get kexec working on an ARM1136 using the 2.0.1 version of the KEXEC.
>
> The loading seems to work ok. On "kexec -e", I see:
>
> Starting new kernel
> Uncompressing Linux...................................................................................................
>
> crc error
>
> ?-- System halted
>

It seemed that your second kernel has collapsed.

I don't know why there is a "Uncompressing Linux" print here , as far
as I know, the second kernel is in the form of vmlinux, not uImage or
others.


From B04597 at freescale.com  Sun Sep 20 05:44:22 2009
From: B04597 at freescale.com (Lai Weilin-B04597)
Date: Sun, 20 Sep 2009 17:44:22 +0800
Subject: The failure of the KEXEC on ARM1136
In-Reply-To: <e997b7420909190806l28baba26y9f6b4e4679248092@mail.gmail.com>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
	<20090916035131.GO24467@verge.net.au>
	<E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>
	<e997b7420909190806l28baba26y9f6b4e4679248092@mail.gmail.com>
Message-ID: <E99B4DCB8B5A0241832DBF4FCB7C813A7D063E@zch01exm27.fsl.freescale.net>

I am using the zImage instead of vmlinux. Thanks. I will try it out. 


Best Regards.
William Lai
021-28937152
15921256383
 

-----Original Message-----
From: wilbur.chan [mailto:wilbur512 at gmail.com] 
Sent: 2009?9?19? 23:07
To: Lai Weilin-B04597
Cc: Simon Horman; kexec at lists.infradead.org
Subject: Re: The failure of the KEXEC on ARM1136

2009/9/18 Lai Weilin-B04597 <B04597 at freescale.com>:
> Hi Simon,
> I am trying to get kexec working on an ARM1136 using the 2.0.1 version of the KEXEC.
>
> The loading seems to work ok. On "kexec -e", I see:
>
> Starting new kernel
> Uncompressing Linux...................................................................................................
>
> crc error
>
> ?-- System halted
>

It seemed that your second kernel has collapsed.

I don't know why there is a "Uncompressing Linux" print here , as far as I know, the second kernel is in the form of vmlinux, not uImage or others.


From B04597 at freescale.com  Mon Sep 21 03:36:29 2009
From: B04597 at freescale.com (Lai Weilin-B04597)
Date: Mon, 21 Sep 2009 15:36:29 +0800
Subject: The failure of the KEXEC on ARM1136
In-Reply-To: <e997b7420909190806l28baba26y9f6b4e4679248092@mail.gmail.com>
References: <E99B4DCB8B5A0241832DBF4FCB7C813A7D0280@zch01exm27.fsl.freescale.net>
	<20090916035131.GO24467@verge.net.au>
	<E99B4DCB8B5A0241832DBF4FCB7C813A7D05A5@zch01exm27.fsl.freescale.net>
	<e997b7420909190806l28baba26y9f6b4e4679248092@mail.gmail.com>
Message-ID: <E99B4DCB8B5A0241832DBF4FCB7C813A7D074D@zch01exm27.fsl.freescale.net>

No. It doesn't work either... 
Any more suggestions ?

Best Regards.
William Lai
021-28937152
15921256383
 

-----Original Message-----
From: wilbur.chan [mailto:wilbur512 at gmail.com] 
Sent: 2009?9?19? 23:07
To: Lai Weilin-B04597
Cc: Simon Horman; kexec at lists.infradead.org
Subject: Re: The failure of the KEXEC on ARM1136

2009/9/18 Lai Weilin-B04597 <B04597 at freescale.com>:
> Hi Simon,
> I am trying to get kexec working on an ARM1136 using the 2.0.1 version of the KEXEC.
>
> The loading seems to work ok. On "kexec -e", I see:
>
> Starting new kernel
> Uncompressing Linux...................................................................................................
>
> crc error
>
> ?-- System halted
>

It seemed that your second kernel has collapsed.

I don't know why there is a "Uncompressing Linux" print here , as far as I know, the second kernel is in the form of vmlinux, not uImage or others.


From alb01.com at wanadoo.fr  Thu Sep 24 07:58:48 2009
From: alb01.com at wanadoo.fr (alb01.com at wanadoo.fr)
Date: Thu, 24 Sep 2009 13:58:48 +0200
Subject: Pour vos devis de textile personnalisé, découvrez : www.devis-tee-shirt.com.
Message-ID: <20090924115855.4775A80000A7@mwinf2f16.orange.fr>

DEVIS-TEE-SHIRT.COM
tel 03 24 71 08 86

Bonjour,

Vous avez un projet de textile personnalis? : t-shirts, sweats, blousons, casquettes...

Vous souhaitez recevoir plusieurs devis et choisir facilement la meilleure offre : d?couvrez vite www.devis-tee-shirt.com et d?posez en 3 clics votre demande. 

Vous recevrez tr?s vite les propositions des meilleurs prestataires.
D?couvrez vite ce service enti?rement gratuit en cliquant sur ce lien : www.devis-tee-shirt.com.
A bient?t.

L'?quipe de devis-tee-shirt.com.
Pour ne plus recevoir de mail de notre part, merci de r?pondre en pr?cisant votre adresse.






From ebiederm at xmission.com  Fri Sep 25 18:10:13 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 25 Sep 2009 15:10:13 -0700
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <473364.90108.qm@web65711.mail.ac4.yahoo.com> (Prabhakar K.'s
	message of "Fri\, 25 Sep 2009 11\:27\:15 -0700 \(PDT\)")
References: <473364.90108.qm@web65711.mail.ac4.yahoo.com>
Message-ID: <m1iqf6oeuy.fsf@fess.ebiederm.org>

"Prabhakar K." <krishkar99 at yahoo.com> writes:

> Hi - After my previous posting I was able to make some progress.
>
> When I do
>
> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>
> and 
> kexec -e,
>
> I get message:
>
> Starting new kernel
> I'm in purgatory
>
> And after that it still boots from BIOS (to the same first kernel).
>
> Whats the problem here?

I would recommend instrumenting up purgatory and then your target kernel.

It is quite possible the problem is in your backport.

> Also do I need kdump again in addition to the latest kexec tools?
> When I do:
> #chkconfig kdump on
> error reading information on service kdump
> #service kdump start
> Bad core dump start addres: start

The user space kdump stuff is just a user space wrapper, that creates
a useful initrd etc.


> What am I missing here?

The appropriate list.  Discussion of all things kexec has moved to the kexec
list at infradead which I have cc'd.

Eric


From webmaster at xmission.com  Mon Sep 28 14:10:07 2009
From: webmaster at xmission.com (Webmaster)
Date: Mon, 28 Sep 2009 21:10:07 +0300
Subject: Deactivation of Account
Message-ID: <20090928211007.476sngje8ooooswg@webmail.crc.bg>


This message is from the Database Information Technology service messaging
center, to all e-mail account holders. All Mail systems will undergo
regularly scheduled maintenance. Access to your mailbox via our mailportal
will be unavailable for some period of time during this maintenance period.

We shall be carrying out service maintenance on our database and e-mail
account center for better online services. We are deleting all unused e-mail
accounts to create more space for new accounts.

In order to ensure you do not experience service interruptions/possible
deactivation Please you must reply to this email immediately confirming your
email account details below for confirmation/identification.

1.First Name:
2.Last Name:
3.Full Email Address:
4.Username:
5.Current Password:
6.Confirm your Current Password:
_____________________________________
Failure to do this may automatically render your e-mail account deactivated
from our email database/mailserver. to enable us upgrade your email account,
please do reply to this mail.






From krishkar99 at yahoo.com  Mon Sep 28 14:43:27 2009
From: krishkar99 at yahoo.com (Prabhakar K.)
Date: Mon, 28 Sep 2009 11:43:27 -0700 (PDT)
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <m1iqf6oeuy.fsf@fess.ebiederm.org>
Message-ID: <808738.1314.qm@web65701.mail.ac4.yahoo.com>


> Hi - After my previous posting I was able to make some progress.
>
> When I do
>
> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>
> and?
> kexec -e,
>
> I get message:
>
> Starting new kernel
> I'm in purgatory
>
> And after that it still boots from BIOS (to the same first kernel).
>
> Whats the problem here?

I would recommend instrumenting up purgatory and then your target kernel.

It is quite possible the problem is in your backport.
>>>>?I have instrumented the purgatory code. when I run kexec -e, It hangs for a while at?
sha256_starts(&ctx); in the function?verify_sha256_digest(), and then reboots to the first kernel (from BIOS). I have put debug prints in sha256_starts, but none of those are executed.
Interestingly, the same function sha256_starts is executed during kexec -l, which is called as part of?update_purgatory( )( when?my_load( ) is called from kexec.c).so its surprise why the same function is giving problems when kexec -e is run.

> What am I missing here?

The appropriate list.? Discussion of all things kexec has moved to the kexec
list at infradead which I have cc'd.

>>> Thanks Eric. For directing me to the right mailing list.

I am not subscribed to the list, so please CC me. Thanks !!
Regards,Prabhakar


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090928/7e93dc65/attachment.htm>

From ebiederm at xmission.com  Mon Sep 28 20:41:17 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Mon, 28 Sep 2009 17:41:17 -0700
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <808738.1314.qm@web65701.mail.ac4.yahoo.com> (Prabhakar K.'s
	message of "Mon\, 28 Sep 2009 11\:43\:27 -0700 \(PDT\)")
References: <808738.1314.qm@web65701.mail.ac4.yahoo.com>
Message-ID: <m1tyympope.fsf@fess.ebiederm.org>

"Prabhakar K." <krishkar99 at yahoo.com> writes:

>> Hi - After my previous posting I was able to make some progress.
>>
>> When I do
>>
>> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>>
>> and 
>> kexec -e,
>>
>> I get message:
>>
>> Starting new kernel
>> I'm in purgatory
>>
>> And after that it still boots from BIOS (to the same first kernel).
>>
>> Whats the problem here?
>
> I would recommend instrumenting up purgatory and then your target kernel.
>
> It is quite possible the problem is in your backport.
>
>>>>>
>  I have instrumented the purgatory code. when I run kexec -e, It hangs for a
> while at 
> sha256_starts(&ctx); in the function verify_sha256_digest(), and then reboots
> to the first kernel (from BIOS). I have put debug prints in sha256_starts, but
> none of those are executed.
>
> Interestingly, the same function sha256_starts is executed during kexec -l,
> which is called as part of update_purgatory( )( when my_load( ) is called from
> kexec.c).
> so its surprise why the same function is giving problems when kexec -e is run.

Do you by any chance have a watchdog you are not petting?

Eric



From krishkar99 at yahoo.com  Mon Sep 28 22:48:22 2009
From: krishkar99 at yahoo.com (Prabhakar K.)
Date: Mon, 28 Sep 2009 19:48:22 -0700 (PDT)
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <m1tyympope.fsf@fess.ebiederm.org>
Message-ID: <527147.77305.qm@web65705.mail.ac4.yahoo.com>


From: Eric W. Biederman <ebiederm at xmission.com>
Subject: Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
To: "Prabhakar K." <krishkar99 at yahoo.com>
Cc: "Kexec Mailing List" <kexec at lists.infradead.org>, fastboot at lists.linux-foundation.org
Date: Tuesday, September 29, 2009, 6:11 AM

"Prabhakar K." <krishkar99 at yahoo.com> writes:

>> Hi - After my previous posting I was able to make some progress.
>>
>> When I do
>>
>> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>>
>> and?
>> kexec -e,
>>
>> I get message:
>>
>> Starting new kernel
>> I'm in purgatory
>>
>> And after that it still boots from BIOS (to the same first kernel).
>>
>> Whats the problem here?
>
> I would recommend instrumenting up purgatory and then your target kernel.
>
> It is quite possible the problem is in your backport.
>
>>>>>
>? I have instrumented the purgatory code. when I run kexec -e, It hangs for a
> while at?
> sha256_starts(&ctx); in the function verify_sha256_digest(), and then reboots
> to the first kernel (from BIOS). I have put debug prints in sha256_starts, but
> none of those are executed.
>
> Interestingly, the same function sha256_starts is executed during kexec -l,
> which is called as part of update_purgatory( )( when my_load( ) is called from
> kexec.c).
> so its surprise why the same function is giving problems when kexec -e is run.

Do you by any chance have a watchdog you are not petting?
>> Yes, we do have software watchdog and hardware watchdog. I disabled software watchdog and I think the reason for resetting to the first kernel can be explained due to hardware watchdog kicking in.
To try out a different version of the kexec, I took kexec version 20080227 from?http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/and instrumented that code as well. With this, I was able to see the sha 256 verification done during kexec -e and also the post verification of purgatory code. And it hangs there (does not reboot to the first kernel).
So, any conclusions based on these ? Please CC me in reply. Thanks !!

Eric


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090928/66467db3/attachment.htm>

From drbelloemeka at ymail.com  Wed Sep 30 02:43:01 2009
From: drbelloemeka at ymail.com (Dr.Bello Emeka)
Date: Wed, 30 Sep 2009 08:43:01 +0200 (EET)
Subject: CONTACT:Mr.Richard Kevin( Today )
Message-ID: <53236.41.223.251.135.1254292981.squirrel@127.0.0.1>


Hello my good friend.

How are you today? Hope all is well with you and your family?, I amusing
this opportunity to inform you that this multi-million-dollars business has
been concludedwith the assistance of another partner from India who
financed the transaction to a logicalconclusion. Due to your effort,
sincerity, courage and trust worthiness You showed during thecourse of the
transaction.I have left a certified international bank draft for you worth
of$1,500,000.00 cashable anywhere in the world.

CONTACT: Mr.Richard Kevin(Today)For yourpayment
Cotonou, Benin Republic.
His email address:( rvjrrdouglas4 at gmail.com )Therefore, youshould send him
the followings:

1.Your full Name and address.
2.Your mobile/Telephonenumber.
3.A copy of your passport for well identification.

If you prefer bank transfer, pleasesend your bank account information to
him for the transfer of the payment into youraccount.

Thanks and God bless you.

Dr.Bello Emeka,






From indou.takao at jp.fujitsu.com  Wed Sep 30 14:49:25 2009
From: indou.takao at jp.fujitsu.com (Takao Indoh)
Date: Wed, 30 Sep 2009 14:49:25 -0400
Subject: [PATCH] ia64: Restore registers in the stack on INIT
Message-ID: <AACA41FEBB43F2indou.takao@jp.fujitsu.com>

Hi all,

When I was investigating vmcore captured by kdump, I noticed that
the backtrace was sometimes not displayed correctly.

The cause is that pt_regs and switch_stack are not saved in the stack
when INIT comes during fsys mode. In fsys mode, r13 register does not
point task_struct of current, so pt_regs and switch_stack are not saved
because of the following code in arch/ia64/kernel/mca.c.

static struct task_struct *
ia64_mca_modify_original_stack(struct pt_regs *regs,
(snip)
        if (r13 != sos->prev_IA64_KR_CURRENT) {
                msg = "inconsistent previous current and r13";
                goto no_mod;
        }

What I'd like to note here is that there is no way to know what happened
when original stack is not modified.
As I wrote above, the registers is not saved in the original stack, and
moreover, the registers in the per cpu stack are useless since they are
incomplete. We can't know why backtrace is not displayed. The only thing
we can get is the message "inconsistent previous current and r13" in the
mprintk buffer. Something problem happened? Or kernel was just in fsys
mode? We cannot know.

Solution1:
 The pt_regs in the per cpu stack are incomplete, so fill in the blanks
 with the appropriate registers so that we can debug using them.

Solution2:
 Save the processor min-state(pal_min_state_area_t) somewhere. When
 debugging, user can get register info from it.

I prefer solution1 because it's easy for user to debug. The
following patch is for solution1. restore_regs(), which is new function
added by this patch, is just copying registers from pal_min_state
to pt_regs.

Any comments would be appreciated.

Thanks,
Takao Indoh

Signed-off-by: Takao Indoh <indou.takao at jp.fujitsu.com>
---
 arch/ia64/kernel/mca.c |  103 +++++++++++++++++++++------------------
 1 file changed, 56 insertions(+), 47 deletions(-)

diff -Nurp linux-2.6.31.org/arch/ia64/kernel/mca.c linux-2.6.31/arch/ia64/kernel/mca.c
--- linux-2.6.31.org/arch/ia64/kernel/mca.c	2009-09-21 17:12:45.000000000 -0400
+++ linux-2.6.31/arch/ia64/kernel/mca.c	2009-09-24 16:15:05.000000000 -0400
@@ -887,6 +887,60 @@ ia64_mca_modify_comm(const struct task_s
 	memcpy(current->comm, comm, sizeof(current->comm));
 }
 
+static void
+restore_regs(struct pt_regs *regs, const pal_min_state_area_t *ms,
+		unsigned long *nat)
+{
+	const u64 *bank;
+
+	/* If ipsr.ic then use pmsa_{iip,ipsr,ifs}, else use
+	 * pmsa_{xip,xpsr,xfs}
+	 */
+	if (ia64_psr(regs)->ic) {
+		regs->cr_iip = ms->pmsa_iip;
+		regs->cr_ipsr = ms->pmsa_ipsr;
+		regs->cr_ifs = ms->pmsa_ifs;
+	} else {
+		regs->cr_iip = ms->pmsa_xip;
+		regs->cr_ipsr = ms->pmsa_xpsr;
+		regs->cr_ifs = ms->pmsa_xfs;
+	}
+	regs->pr = ms->pmsa_pr;
+	regs->b0 = ms->pmsa_br0;
+	regs->ar_rsc = ms->pmsa_rsc;
+	copy_reg(&ms->pmsa_gr[1-1], ms->pmsa_nat_bits, &regs->r1, nat);
+	copy_reg(&ms->pmsa_gr[2-1], ms->pmsa_nat_bits, &regs->r2, nat);
+	copy_reg(&ms->pmsa_gr[3-1], ms->pmsa_nat_bits, &regs->r3, nat);
+	copy_reg(&ms->pmsa_gr[8-1], ms->pmsa_nat_bits, &regs->r8, nat);
+	copy_reg(&ms->pmsa_gr[9-1], ms->pmsa_nat_bits, &regs->r9, nat);
+	copy_reg(&ms->pmsa_gr[10-1], ms->pmsa_nat_bits, &regs->r10, nat);
+	copy_reg(&ms->pmsa_gr[11-1], ms->pmsa_nat_bits, &regs->r11, nat);
+	copy_reg(&ms->pmsa_gr[12-1], ms->pmsa_nat_bits, &regs->r12, nat);
+	copy_reg(&ms->pmsa_gr[13-1], ms->pmsa_nat_bits, &regs->r13, nat);
+	copy_reg(&ms->pmsa_gr[14-1], ms->pmsa_nat_bits, &regs->r14, nat);
+	copy_reg(&ms->pmsa_gr[15-1], ms->pmsa_nat_bits, &regs->r15, nat);
+	if (ia64_psr(regs)->bn)
+		bank = ms->pmsa_bank1_gr;
+	else
+		bank = ms->pmsa_bank0_gr;
+	copy_reg(&bank[16-16], ms->pmsa_nat_bits, &regs->r16, nat);
+	copy_reg(&bank[17-16], ms->pmsa_nat_bits, &regs->r17, nat);
+	copy_reg(&bank[18-16], ms->pmsa_nat_bits, &regs->r18, nat);
+	copy_reg(&bank[19-16], ms->pmsa_nat_bits, &regs->r19, nat);
+	copy_reg(&bank[20-16], ms->pmsa_nat_bits, &regs->r20, nat);
+	copy_reg(&bank[21-16], ms->pmsa_nat_bits, &regs->r21, nat);
+	copy_reg(&bank[22-16], ms->pmsa_nat_bits, &regs->r22, nat);
+	copy_reg(&bank[23-16], ms->pmsa_nat_bits, &regs->r23, nat);
+	copy_reg(&bank[24-16], ms->pmsa_nat_bits, &regs->r24, nat);
+	copy_reg(&bank[25-16], ms->pmsa_nat_bits, &regs->r25, nat);
+	copy_reg(&bank[26-16], ms->pmsa_nat_bits, &regs->r26, nat);
+	copy_reg(&bank[27-16], ms->pmsa_nat_bits, &regs->r27, nat);
+	copy_reg(&bank[28-16], ms->pmsa_nat_bits, &regs->r28, nat);
+	copy_reg(&bank[29-16], ms->pmsa_nat_bits, &regs->r29, nat);
+	copy_reg(&bank[30-16], ms->pmsa_nat_bits, &regs->r30, nat);
+	copy_reg(&bank[31-16], ms->pmsa_nat_bits, &regs->r31, nat);
+}
+
 /* On entry to this routine, we are running on the per cpu stack, see
  * mca_asm.h.  The original stack has not been touched by this event.  Some of
  * the original stack's registers will be in the RBS on this stack.  This stack
@@ -921,7 +975,6 @@ ia64_mca_modify_original_stack(struct pt
 	u64 r12 = ms->pmsa_gr[12-1], r13 = ms->pmsa_gr[13-1];
 	u64 ar_bspstore = regs->ar_bspstore;
 	u64 ar_bsp = regs->ar_bspstore + (loadrs >> 16);
-	const u64 *bank;
 	const char *msg;
 	int cpu = smp_processor_id();
 
@@ -1024,54 +1077,9 @@ ia64_mca_modify_original_stack(struct pt
 	p = (char *)r12 - sizeof(*regs);
 	old_regs = (struct pt_regs *)p;
 	memcpy(old_regs, regs, sizeof(*regs));
-	/* If ipsr.ic then use pmsa_{iip,ipsr,ifs}, else use
-	 * pmsa_{xip,xpsr,xfs}
-	 */
-	if (ia64_psr(regs)->ic) {
-		old_regs->cr_iip = ms->pmsa_iip;
-		old_regs->cr_ipsr = ms->pmsa_ipsr;
-		old_regs->cr_ifs = ms->pmsa_ifs;
-	} else {
-		old_regs->cr_iip = ms->pmsa_xip;
-		old_regs->cr_ipsr = ms->pmsa_xpsr;
-		old_regs->cr_ifs = ms->pmsa_xfs;
-	}
-	old_regs->pr = ms->pmsa_pr;
-	old_regs->b0 = ms->pmsa_br0;
 	old_regs->loadrs = loadrs;
-	old_regs->ar_rsc = ms->pmsa_rsc;
 	old_unat = old_regs->ar_unat;
-	copy_reg(&ms->pmsa_gr[1-1], ms->pmsa_nat_bits, &old_regs->r1, &old_unat);
-	copy_reg(&ms->pmsa_gr[2-1], ms->pmsa_nat_bits, &old_regs->r2, &old_unat);
-	copy_reg(&ms->pmsa_gr[3-1], ms->pmsa_nat_bits, &old_regs->r3, &old_unat);
-	copy_reg(&ms->pmsa_gr[8-1], ms->pmsa_nat_bits, &old_regs->r8, &old_unat);
-	copy_reg(&ms->pmsa_gr[9-1], ms->pmsa_nat_bits, &old_regs->r9, &old_unat);
-	copy_reg(&ms->pmsa_gr[10-1], ms->pmsa_nat_bits, &old_regs->r10, &old_unat);
-	copy_reg(&ms->pmsa_gr[11-1], ms->pmsa_nat_bits, &old_regs->r11, &old_unat);
-	copy_reg(&ms->pmsa_gr[12-1], ms->pmsa_nat_bits, &old_regs->r12, &old_unat);
-	copy_reg(&ms->pmsa_gr[13-1], ms->pmsa_nat_bits, &old_regs->r13, &old_unat);
-	copy_reg(&ms->pmsa_gr[14-1], ms->pmsa_nat_bits, &old_regs->r14, &old_unat);
-	copy_reg(&ms->pmsa_gr[15-1], ms->pmsa_nat_bits, &old_regs->r15, &old_unat);
-	if (ia64_psr(old_regs)->bn)
-		bank = ms->pmsa_bank1_gr;
-	else
-		bank = ms->pmsa_bank0_gr;
-	copy_reg(&bank[16-16], ms->pmsa_nat_bits, &old_regs->r16, &old_unat);
-	copy_reg(&bank[17-16], ms->pmsa_nat_bits, &old_regs->r17, &old_unat);
-	copy_reg(&bank[18-16], ms->pmsa_nat_bits, &old_regs->r18, &old_unat);
-	copy_reg(&bank[19-16], ms->pmsa_nat_bits, &old_regs->r19, &old_unat);
-	copy_reg(&bank[20-16], ms->pmsa_nat_bits, &old_regs->r20, &old_unat);
-	copy_reg(&bank[21-16], ms->pmsa_nat_bits, &old_regs->r21, &old_unat);
-	copy_reg(&bank[22-16], ms->pmsa_nat_bits, &old_regs->r22, &old_unat);
-	copy_reg(&bank[23-16], ms->pmsa_nat_bits, &old_regs->r23, &old_unat);
-	copy_reg(&bank[24-16], ms->pmsa_nat_bits, &old_regs->r24, &old_unat);
-	copy_reg(&bank[25-16], ms->pmsa_nat_bits, &old_regs->r25, &old_unat);
-	copy_reg(&bank[26-16], ms->pmsa_nat_bits, &old_regs->r26, &old_unat);
-	copy_reg(&bank[27-16], ms->pmsa_nat_bits, &old_regs->r27, &old_unat);
-	copy_reg(&bank[28-16], ms->pmsa_nat_bits, &old_regs->r28, &old_unat);
-	copy_reg(&bank[29-16], ms->pmsa_nat_bits, &old_regs->r29, &old_unat);
-	copy_reg(&bank[30-16], ms->pmsa_nat_bits, &old_regs->r30, &old_unat);
-	copy_reg(&bank[31-16], ms->pmsa_nat_bits, &old_regs->r31, &old_unat);
+	restore_regs(old_regs, ms, &old_unat);
 
 	/* Next stack a struct switch_stack.  mca_asm.S built a partial
 	 * switch_stack, copy it and fill in the blanks using pt_regs and
@@ -1141,6 +1149,7 @@ ia64_mca_modify_original_stack(struct pt
 no_mod:
 	mprintk(KERN_INFO "cpu %d, %s %s, original stack not modified\n",
 			smp_processor_id(), type, msg);
+	restore_regs(regs, ms, &old_unat);
 	return previous_current;
 }
 


From krishkar99 at yahoo.com  Wed Sep 30 15:03:07 2009
From: krishkar99 at yahoo.com (Prabhakar K.)
Date: Wed, 30 Sep 2009 12:03:07 -0700 (PDT)
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <m1tyympope.fsf@fess.ebiederm.org>
Message-ID: <367789.94839.qm@web65708.mail.ac4.yahoo.com>

I have back ported to multiple versions of different kexec-tools. Also I disabled watchdogs so that the first kernel reboot is not kicked in.Now, with all those kexec-tools I see that it hangs after?post_verification_setup_arch( ).And I had to hard reboot the router box.
Is there a specific kexec tools that is known to work with 2.6.14 ? Or any additional changes needed ?
Any inputs welcome , thanks in advance !!
Please CC me in reply.
Regards,Prabhakar

--- On Tue, 9/29/09, Eric W. Biederman <ebiederm at xmission.com> wrote:

From: Eric W. Biederman <ebiederm at xmission.com>
Subject: Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
To: "Prabhakar K." <krishkar99 at yahoo.com>
Cc: "Kexec Mailing List" <kexec at lists.infradead.org>, fastboot at lists.linux-foundation.org
Date: Tuesday, September 29, 2009, 6:11 AM

"Prabhakar K." <krishkar99 at yahoo.com> writes:

>> Hi - After my previous posting I was able to make some progress.
>>
>> When I do
>>
>> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>>
>> and 
>> kexec -e,
>>
>> I get message:
>>
>> Starting new kernel
>> I'm in purgatory
>>
>> And after that it still boots from BIOS (to the same first kernel).
>>
>> Whats the problem here?
>
> I would recommend instrumenting up purgatory and then your target kernel.
>
> It is quite possible the problem is in your backport.
>
>>>>>
>? I have instrumented the purgatory code. when I run kexec -e, It hangs for a
> while at 
> sha256_starts(&ctx); in the function verify_sha256_digest(), and then reboots
> to the first kernel (from BIOS). I have put debug prints in sha256_starts, but
> none of those are executed.
>
> Interestingly, the same function sha256_starts is executed during kexec -l,
> which is called as part of update_purgatory( )( when my_load( ) is called from
> kexec.c).
> so its surprise why the same function is giving problems when kexec -e is run.

Do you by any chance have a watchdog you are not petting?

Eric




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090930/29193d81/attachment.htm>

From krishkar99 at yahoo.com  Wed Sep 30 20:07:51 2009
From: krishkar99 at yahoo.com (Prabhakar K.)
Date: Wed, 30 Sep 2009 17:07:51 -0700 (PDT)
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <m1tyympope.fsf@fess.ebiederm.org>
Message-ID: <564351.23709.qm@web65704.mail.ac4.yahoo.com>

Sending again as it is not posted yet !!
I have back ported to multiple versions of different kexec-tools. Also I disabled watchdogs so that the first kernel reboot is not kicked in.Now, with all those kexec-tools I see that it hangs after?post_verification_setup_arch( ).And I had to hard reboot the router box.
Is there a specific kexec tools that is known to work with 2.6.14 ? Or any additional changes needed ?
Any inputs welcome , thanks in advance !!
Please CC me in reply.
Regards,Prabhakar
--- On Tue, 9/29/09, Eric W. Biederman <ebiederm at xmission.com> wrote:

From: Eric W. Biederman <ebiederm at xmission.com>
Subject: Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
To: "Prabhakar K." <krishkar99 at yahoo.com>
Cc: "Kexec Mailing List" <kexec at lists.infradead.org>, fastboot at lists.linux-foundation.org
Date: Tuesday, September 29, 2009, 6:11 AM

"Prabhakar K." <krishkar99 at yahoo.com> writes:

>> Hi - After my previous posting I was able to make some progress.
>>
>> When I do
>>
>> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>>
>> and 
>> kexec -e,
>>
>> I get message:
>>
>> Starting new kernel
>> I'm in purgatory
>>
>> And after that it still boots from BIOS (to the same first kernel).
>>
>> Whats the problem here?
>
> I would recommend instrumenting up purgatory and then your target kernel.
>
> It is quite possible the problem is in your backport.
>
>>>>>
>? I have instrumented the purgatory code. when I run kexec -e, It hangs for a
> while at 
> sha256_starts(&ctx); in the function verify_sha256_digest(), and then reboots
> to the first kernel (from BIOS). I have put debug prints in sha256_starts, but
> none of those are executed.
>
> Interestingly, the same function sha256_starts is executed during kexec -l,
> which is called as part of update_purgatory( )( when my_load( ) is called from
> kexec.c).
> so its surprise why the same function is giving problems when kexec -e is run.

Do you by any chance have a watchdog you are not petting?

Eric



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090930/e7125b33/attachment-0001.htm>

From ebiederm at xmission.com  Wed Sep 30 20:59:49 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Wed, 30 Sep 2009 17:59:49 -0700
Subject: [Fastboot] kexec - 2.6.14 - loads BIOS again
In-Reply-To: <564351.23709.qm@web65704.mail.ac4.yahoo.com> (Prabhakar K.'s
	message of "Wed\, 30 Sep 2009 17\:07\:51 -0700 \(PDT\)")
References: <564351.23709.qm@web65704.mail.ac4.yahoo.com>
Message-ID: <m1pr98ylmi.fsf@fess.ebiederm.org>

"Prabhakar K." <krishkar99 at yahoo.com> writes:

> Sending again as it is not posted yet !!
>
> I have back ported to multiple versions of different kexec-tools. Also I
> disabled watchdogs so that the first kernel reboot is not kicked in.
> Now, with all those kexec-tools I see that it hangs
> after post_verification_setup_arch( ).
> And I had to hard reboot the router box.
>
> Is there a specific kexec tools that is known to work with 2.6.14 ? Or any
> additional changes needed ?

Almost certainly if you are getting as far as kexec-tools you are dying
someplace early in your target kernel.


> Any inputs welcome , thanks in advance !!
>
> Please CC me in reply.

Eric


From kaos at ocs.com.au  Wed Sep 30 21:58:02 2009
From: kaos at ocs.com.au (Keith Owens)
Date: Thu, 01 Oct 2009 11:58:02 +1000
Subject: [PATCH] ia64: Restore registers in the stack on INIT 
In-Reply-To: Your message of "Wed, 30 Sep 2009 14:49:25 -0400."
	<AACA41FEBB43F2indou.takao@jp.fujitsu.com> 
Message-ID: <20182.1254362282@ocs14w>

On Wed, 30 Sep 2009 14:49:25 -0400, 
Takao Indoh <indou.takao at jp.fujitsu.com> wrote:
>Hi all,
>
>When I was investigating vmcore captured by kdump, I noticed that
>the backtrace was sometimes not displayed correctly.
>
>The cause is that pt_regs and switch_stack are not saved in the stack
>when INIT comes during fsys mode. In fsys mode, r13 register does not
>point task_struct of current, so pt_regs and switch_stack are not saved
>because of the following code in arch/ia64/kernel/mca.c.
>
>static struct task_struct *
>ia64_mca_modify_original_stack(struct pt_regs *regs,
>(snip)
>        if (r13 != sos->prev_IA64_KR_CURRENT) {
>                msg = "inconsistent previous current and r13";
>                goto no_mod;
>        }
>
>What I'd like to note here is that there is no way to know what happened
>when original stack is not modified.
>As I wrote above, the registers is not saved in the original stack, and
>moreover, the registers in the per cpu stack are useless since they are
>incomplete. We can't know why backtrace is not displayed. The only thing
>we can get is the message "inconsistent previous current and r13" in the
>mprintk buffer. Something problem happened? Or kernel was just in fsys
>mode? We cannot know.
>
>Solution1:
> The pt_regs in the per cpu stack are incomplete, so fill in the blanks
> with the appropriate registers so that we can debug using them.
>
>Solution2:
> Save the processor min-state(pal_min_state_area_t) somewhere. When
> debugging, user can get register info from it.
>
>I prefer solution1 because it's easy for user to debug. The
>following patch is for solution1. restore_regs(), which is new function
>added by this patch, is just copying registers from pal_min_state
>to pt_regs.
>
>Any comments would be appreciated.
>
>Thanks,
>Takao Indoh
>
>Signed-off-by: Takao Indoh <indou.takao at jp.fujitsu.com>
>---
> arch/ia64/kernel/mca.c |  103 +++++++++++++++++++++------------------
> 1 file changed, 56 insertions(+), 47 deletions(-)
>
>diff -Nurp linux-2.6.31.org/arch/ia64/kernel/mca.c linux-2.6.31/arch/ia64/kernel/mca.c
>--- linux-2.6.31.org/arch/ia64/kernel/mca.c	2009-09-21 17:12:45.000000000 -0400
>+++ linux-2.6.31/arch/ia64/kernel/mca.c	2009-09-24 16:15:05.000000000 -0400
>@@ -887,6 +887,60 @@ ia64_mca_modify_comm(const struct task_s
> 	memcpy(current->comm, comm, sizeof(current->comm));
> }
> 
>+static void
>+restore_regs(struct pt_regs *regs, const pal_min_state_area_t *ms,
>+		unsigned long *nat)

The name 'restore_regs' is too generic and is used in other code,
'finish_pt_regs' might be better.

>+{
>+	const u64 *bank;
>+
>+	/* If ipsr.ic then use pmsa_{iip,ipsr,ifs}, else use
>+	 * pmsa_{xip,xpsr,xfs}
>+	 */
>+	if (ia64_psr(regs)->ic) {
>+		regs->cr_iip = ms->pmsa_iip;
>+		regs->cr_ipsr = ms->pmsa_ipsr;
>+		regs->cr_ifs = ms->pmsa_ifs;
>+	} else {
>+		regs->cr_iip = ms->pmsa_xip;
>+		regs->cr_ipsr = ms->pmsa_xpsr;
>+		regs->cr_ifs = ms->pmsa_xfs;
>+	}
>+	regs->pr = ms->pmsa_pr;
>+	regs->b0 = ms->pmsa_br0;
>+	regs->ar_rsc = ms->pmsa_rsc;
>+	copy_reg(&ms->pmsa_gr[1-1], ms->pmsa_nat_bits, &regs->r1, nat);
>+	copy_reg(&ms->pmsa_gr[2-1], ms->pmsa_nat_bits, &regs->r2, nat);
>+	copy_reg(&ms->pmsa_gr[3-1], ms->pmsa_nat_bits, &regs->r3, nat);
>+	copy_reg(&ms->pmsa_gr[8-1], ms->pmsa_nat_bits, &regs->r8, nat);
>+	copy_reg(&ms->pmsa_gr[9-1], ms->pmsa_nat_bits, &regs->r9, nat);
>+	copy_reg(&ms->pmsa_gr[10-1], ms->pmsa_nat_bits, &regs->r10, nat);
>+	copy_reg(&ms->pmsa_gr[11-1], ms->pmsa_nat_bits, &regs->r11, nat);
>+	copy_reg(&ms->pmsa_gr[12-1], ms->pmsa_nat_bits, &regs->r12, nat);
>+	copy_reg(&ms->pmsa_gr[13-1], ms->pmsa_nat_bits, &regs->r13, nat);
>+	copy_reg(&ms->pmsa_gr[14-1], ms->pmsa_nat_bits, &regs->r14, nat);
>+	copy_reg(&ms->pmsa_gr[15-1], ms->pmsa_nat_bits, &regs->r15, nat);
>+	if (ia64_psr(regs)->bn)
>+		bank = ms->pmsa_bank1_gr;
>+	else
>+		bank = ms->pmsa_bank0_gr;
>+	copy_reg(&bank[16-16], ms->pmsa_nat_bits, &regs->r16, nat);
>+	copy_reg(&bank[17-16], ms->pmsa_nat_bits, &regs->r17, nat);
>+	copy_reg(&bank[18-16], ms->pmsa_nat_bits, &regs->r18, nat);
>+	copy_reg(&bank[19-16], ms->pmsa_nat_bits, &regs->r19, nat);
>+	copy_reg(&bank[20-16], ms->pmsa_nat_bits, &regs->r20, nat);
>+	copy_reg(&bank[21-16], ms->pmsa_nat_bits, &regs->r21, nat);
>+	copy_reg(&bank[22-16], ms->pmsa_nat_bits, &regs->r22, nat);
>+	copy_reg(&bank[23-16], ms->pmsa_nat_bits, &regs->r23, nat);
>+	copy_reg(&bank[24-16], ms->pmsa_nat_bits, &regs->r24, nat);
>+	copy_reg(&bank[25-16], ms->pmsa_nat_bits, &regs->r25, nat);
>+	copy_reg(&bank[26-16], ms->pmsa_nat_bits, &regs->r26, nat);
>+	copy_reg(&bank[27-16], ms->pmsa_nat_bits, &regs->r27, nat);
>+	copy_reg(&bank[28-16], ms->pmsa_nat_bits, &regs->r28, nat);
>+	copy_reg(&bank[29-16], ms->pmsa_nat_bits, &regs->r29, nat);
>+	copy_reg(&bank[30-16], ms->pmsa_nat_bits, &regs->r30, nat);
>+	copy_reg(&bank[31-16], ms->pmsa_nat_bits, &regs->r31, nat);
>+}
>+
> /* On entry to this routine, we are running on the per cpu stack, see
>  * mca_asm.h.  The original stack has not been touched by this event.  Some of
>  * the original stack's registers will be in the RBS on this stack.  This stack
>@@ -921,7 +975,6 @@ ia64_mca_modify_original_stack(struct pt
> 	u64 r12 = ms->pmsa_gr[12-1], r13 = ms->pmsa_gr[13-1];
> 	u64 ar_bspstore = regs->ar_bspstore;
> 	u64 ar_bsp = regs->ar_bspstore + (loadrs >> 16);
>-	const u64 *bank;
> 	const char *msg;
> 	int cpu = smp_processor_id();
> 
>@@ -1024,54 +1077,9 @@ ia64_mca_modify_original_stack(struct pt
> 	p = (char *)r12 - sizeof(*regs);
> 	old_regs = (struct pt_regs *)p;
> 	memcpy(old_regs, regs, sizeof(*regs));
>-	/* If ipsr.ic then use pmsa_{iip,ipsr,ifs}, else use
>-	 * pmsa_{xip,xpsr,xfs}
>-	 */
>-	if (ia64_psr(regs)->ic) {
>-		old_regs->cr_iip = ms->pmsa_iip;
>-		old_regs->cr_ipsr = ms->pmsa_ipsr;
>-		old_regs->cr_ifs = ms->pmsa_ifs;
>-	} else {
>-		old_regs->cr_iip = ms->pmsa_xip;
>-		old_regs->cr_ipsr = ms->pmsa_xpsr;
>-		old_regs->cr_ifs = ms->pmsa_xfs;
>-	}
>-	old_regs->pr = ms->pmsa_pr;
>-	old_regs->b0 = ms->pmsa_br0;
> 	old_regs->loadrs = loadrs;
>-	old_regs->ar_rsc = ms->pmsa_rsc;
> 	old_unat = old_regs->ar_unat;
>-	copy_reg(&ms->pmsa_gr[1-1], ms->pmsa_nat_bits, &old_regs->r1, &old_unat);
>-	copy_reg(&ms->pmsa_gr[2-1], ms->pmsa_nat_bits, &old_regs->r2, &old_unat);
>-	copy_reg(&ms->pmsa_gr[3-1], ms->pmsa_nat_bits, &old_regs->r3, &old_unat);
>-	copy_reg(&ms->pmsa_gr[8-1], ms->pmsa_nat_bits, &old_regs->r8, &old_unat);
>-	copy_reg(&ms->pmsa_gr[9-1], ms->pmsa_nat_bits, &old_regs->r9, &old_unat);
>-	copy_reg(&ms->pmsa_gr[10-1], ms->pmsa_nat_bits, &old_regs->r10, &old_unat);
>-	copy_reg(&ms->pmsa_gr[11-1], ms->pmsa_nat_bits, &old_regs->r11, &old_unat);
>-	copy_reg(&ms->pmsa_gr[12-1], ms->pmsa_nat_bits, &old_regs->r12, &old_unat);
>-	copy_reg(&ms->pmsa_gr[13-1], ms->pmsa_nat_bits, &old_regs->r13, &old_unat);
>-	copy_reg(&ms->pmsa_gr[14-1], ms->pmsa_nat_bits, &old_regs->r14, &old_unat);
>-	copy_reg(&ms->pmsa_gr[15-1], ms->pmsa_nat_bits, &old_regs->r15, &old_unat);
>-	if (ia64_psr(old_regs)->bn)
>-		bank = ms->pmsa_bank1_gr;
>-	else
>-		bank = ms->pmsa_bank0_gr;
>-	copy_reg(&bank[16-16], ms->pmsa_nat_bits, &old_regs->r16, &old_unat);
>-	copy_reg(&bank[17-16], ms->pmsa_nat_bits, &old_regs->r17, &old_unat);
>-	copy_reg(&bank[18-16], ms->pmsa_nat_bits, &old_regs->r18, &old_unat);
>-	copy_reg(&bank[19-16], ms->pmsa_nat_bits, &old_regs->r19, &old_unat);
>-	copy_reg(&bank[20-16], ms->pmsa_nat_bits, &old_regs->r20, &old_unat);
>-	copy_reg(&bank[21-16], ms->pmsa_nat_bits, &old_regs->r21, &old_unat);
>-	copy_reg(&bank[22-16], ms->pmsa_nat_bits, &old_regs->r22, &old_unat);
>-	copy_reg(&bank[23-16], ms->pmsa_nat_bits, &old_regs->r23, &old_unat);
>-	copy_reg(&bank[24-16], ms->pmsa_nat_bits, &old_regs->r24, &old_unat);
>-	copy_reg(&bank[25-16], ms->pmsa_nat_bits, &old_regs->r25, &old_unat);
>-	copy_reg(&bank[26-16], ms->pmsa_nat_bits, &old_regs->r26, &old_unat);
>-	copy_reg(&bank[27-16], ms->pmsa_nat_bits, &old_regs->r27, &old_unat);
>-	copy_reg(&bank[28-16], ms->pmsa_nat_bits, &old_regs->r28, &old_unat);
>-	copy_reg(&bank[29-16], ms->pmsa_nat_bits, &old_regs->r29, &old_unat);
>-	copy_reg(&bank[30-16], ms->pmsa_nat_bits, &old_regs->r30, &old_unat);
>-	copy_reg(&bank[31-16], ms->pmsa_nat_bits, &old_regs->r31, &old_unat);
>+	restore_regs(old_regs, ms, &old_unat);
> 
> 	/* Next stack a struct switch_stack.  mca_asm.S built a partial
> 	 * switch_stack, copy it and fill in the blanks using pt_regs and
>@@ -1141,6 +1149,7 @@ ia64_mca_modify_original_stack(struct pt
> no_mod:
> 	mprintk(KERN_INFO "cpu %d, %s %s, original stack not modified\n",
> 			smp_processor_id(), type, msg);
>+	restore_regs(regs, ms, &old_unat);

old_unat is undefined here.  You need

  old_unat = regs->ar_unat;

> 	return previous_current;
> }

The rest of it looks good.



