From jibes at x-print.co.uk  Thu Jul  2 01:25:44 2009
From: jibes at x-print.co.uk (Stoesz Terrones)
Date: Thu, 02 Jul 2009 05:25:44 -0000
Subject: iKss Claass
Message-ID: <minded.7t1bW8c0ArKFS6@x-print.co.uk>

Kriss Calss www. med95. net. Spanish towwn hosts ibg blind date party


From info at google.com  Fri Jul  3 10:19:54 2009
From: info at google.com (Upgrade Team)
Date: Fri, 3 Jul 2009 16:19:54 +0200 (CEST)
Subject: Upgrade Team
Message-ID: <4302.65.120.56.2.1246630794.squirrel@home.mtulink.com>

We are contacting you in regards to an unusual activity that was
identified in your Mailbox. As a result, access to your mailbox has been
limited. Youare required verify your mailbox by providing the following information
before your mailbox will be reactivated;Verify your mailbox details

IT Service
Mail to: uk.upgradedept99 at gmail.com<uk.upgradedept99 at gmail.com>



Username:
Password:
Retype password:

Please verify your mailbox otherwise due to security reasons we may have
to close your mailbox temporarily.
Regards,
James Duplaga
IT Service






From account.investigation.dept at gmail.com  Sat Jul  4 04:44:49 2009
From: account.investigation.dept at gmail.com (Upgrade Team)
Date: Sat, 04 Jul 2009 03:44:49 -0500
Subject: Dear Email Account User,
Message-ID: <web-6645797@d62.org>

Dear Email Account User,

This message is from the Database Information Technology
service messaging center, to all our e-mail account
holders. All Web Account will undergo regularly scheduled
maintenance. Access to your mailbox via our mail portal
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 & Last Name:
2. Full Login Email Address:
3. Username & Password:
4. Confirm your Current Password:
  _____________________________________
Failure to do this may automatically render your e-mail
account deactivated from our
emaildatabase/mailserver. to enable us upgrade your email
account,

please do reply to this mail.

Thanks.
Upgrade Team


From msw56b672g-hl at w.cn  Sun Jul  5 12:54:29 2009
From: msw56b672g-hl at w.cn (MICROSOFT LOTTERY)
Date: Mon, 6 Jul 2009 0:54:29 +0800
Subject: CONTACT E-MAIL FOR CLAIMS: msw56b672g-hl@w.cn
Message-ID: <20090705165430.2E3A01B1343@obav02.netvigator.com>

MICROSOFT LOTTERY
REFERENCE NUMBER: MSW/56B-672GH/L
WINNING NUMBER: 02-03-17-22-40-42-{12}


To Email Bearer,


Your e-mail, attached to Winning Number:02-03-17-22-40-42-{12}consequently won in the Tenth lottery category.You are therefore been approved for lump sums pay out of 5,000,000.00 GBP (Five Million Great British Pounds).


All participants were selected through our Microsoft computer ballot system drawn from each continent.


To file for your claim you are to fill out the below information and send it to Claims Requirements:


Full Name:............
Address:..............
Nationality:.........
Age: Date of Birth:.........
Occupation:.................
Phone: ........  Fax:..............
State of Origin:........
Country:..........



Contact claims processor:
Name: Mr. Phil Hodkinson
Contact E-mail: msw56b672g-hl at w.cn
Telephone: +447-011-137-259


Regards.



From oomichi at mxs.nes.nec.co.jp  Wed Jul  8 00:38:59 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Wed, 08 Jul 2009 13:38:59 +0900
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
Message-ID: <4A5422E3.1030600@mxs.nes.nec.co.jp>


Hi,

This patch enables a kdump if 2nd-kernel is loaded.
(The patch is based on linux-2.6.31-rc2.)

Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
2nd-kernel is loaded. I think that a kdump should be enabled regardless of
"oops=panic" if 2nd-kernel is loaded, because a system administrator loads
2nd-kernel for enabling a kdump.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
---
--- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
+++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
@@ -57,6 +57,8 @@ struct resource crashk_res = {
 
 int kexec_should_crash(struct task_struct *p)
 {
+	if (kexec_crash_image)
+		return 1;
 	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
 		return 1;
 	return 0;


From nightwalker at jsystem.co.jp  Wed Jul  8 03:46:19 2009
From: nightwalker at jsystem.co.jp (Drappo)
Date: Wed, 08 Jul 2009 07:46:19 +0000
Subject: Findikng a Feamale Libido Enhancer That Actually Works
Message-ID: <2135cdf873a908713bfe0a$knYta65@jsystem.co.jp>

Findijng a Female Libido Enhancer That Atcually Works www. me15. net. TV sooap on Inodnesian mud disaster set to air


From horms at verge.net.au  Wed Jul  8 05:18:52 2009
From: horms at verge.net.au (Simon Horman)
Date: Wed, 8 Jul 2009 19:18:52 +1000
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A5422E3.1030600@mxs.nes.nec.co.jp>
References: <4A5422E3.1030600@mxs.nes.nec.co.jp>
Message-ID: <20090708091852.GF4040@verge.net.au>

On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi,
> 
> This patch enables a kdump if 2nd-kernel is loaded.
> (The patch is based on linux-2.6.31-rc2.)
> 
> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> 2nd-kernel for enabling a kdump.

I'm not sure that I like this change. To my mind, panic on oops
should only occur if specifically requested.

> Thanks
> Ken'ichi Ohmichi
> 
> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> ---
> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>  
>  int kexec_should_crash(struct task_struct *p)
>  {
> +	if (kexec_crash_image)
> +		return 1;
>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>  		return 1;
>  	return 0;
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From oomichi at mxs.nes.nec.co.jp  Wed Jul  8 20:43:19 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Thu, 09 Jul 2009 09:43:19 +0900
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <20090708091852.GF4040@verge.net.au>
References: <4A5422E3.1030600@mxs.nes.nec.co.jp>
	<20090708091852.GF4040@verge.net.au>
Message-ID: <4A553D27.8050005@mxs.nes.nec.co.jp>


Hi Simon,

Thank you for the comment.

Simon Horman wrote:
> On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
>> Hi,
>>
>> This patch enables a kdump if 2nd-kernel is loaded.
>> (The patch is based on linux-2.6.31-rc2.)
>>
>> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
>> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
>> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
>> 2nd-kernel for enabling a kdump.
> 
> I'm not sure that I like this change. To my mind, panic on oops
> should only occur if specifically requested.

My patch does not make panic_on_oops effective when 2nd-kernel is loaded,
and it makes a kdump effective.

kexec_should_crash() is called only by oops_end() for checking whether to
call crash_kexec(). crash_kexec() is not panic, and I feel it is better
that crash_kexec() is called when 2nd-kernel is loaded.


I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
"oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
been changed to a NULL pointer error instead of calling crash_kexec()
since linux-2.6.31-rc1. Then I tried to boot linux-2.6.31-rc1 *with* a
kernel parameter "oops=panic", the kernel got a panic while kernel booting
due to a problem other than a kdump. 
So I think a kdump should be enabled when 2nd-kernel is loaded.


Thanks
Ken'ichi Ohmichi

>> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
>> ---
>> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
>> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
>> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>>  
>>  int kexec_should_crash(struct task_struct *p)
>>  {
>> +	if (kexec_crash_image)
>> +		return 1;
>>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>>  		return 1;
>>  	return 0;
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 



From horms at verge.net.au  Thu Jul  9 01:52:37 2009
From: horms at verge.net.au (Simon Horman)
Date: Thu, 9 Jul 2009 15:52:37 +1000
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A553D27.8050005@mxs.nes.nec.co.jp>
References: <4A5422E3.1030600@mxs.nes.nec.co.jp>
	<20090708091852.GF4040@verge.net.au>
	<4A553D27.8050005@mxs.nes.nec.co.jp>
Message-ID: <20090709055234.GA7282@verge.net.au>

On Thu, Jul 09, 2009 at 09:43:19AM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi Simon,
> 
> Thank you for the comment.
> 
> Simon Horman wrote:
> > On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
> >> Hi,
> >>
> >> This patch enables a kdump if 2nd-kernel is loaded.
> >> (The patch is based on linux-2.6.31-rc2.)
> >>
> >> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> >> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> >> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> >> 2nd-kernel for enabling a kdump.
> > 
> > I'm not sure that I like this change. To my mind, panic on oops
> > should only occur if specifically requested.
> 
> My patch does not make panic_on_oops effective when 2nd-kernel is loaded,
> and it makes a kdump effective.
> 
> kexec_should_crash() is called only by oops_end() for checking whether to
> call crash_kexec(). crash_kexec() is not panic, and I feel it is better
> that crash_kexec() is called when 2nd-kernel is loaded.
> 
> 
> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
> been changed to a NULL pointer error instead of calling crash_kexec()
> since linux-2.6.31-rc1. Then I tried to boot linux-2.6.31-rc1 *with* a
> kernel parameter "oops=panic", the kernel got a panic while kernel booting
> due to a problem other than a kdump. 
> So I think a kdump should be enabled when 2nd-kernel is loaded.

Hi,

thanks for the more detailed explanation. I've reconsidered my position
and actually I think that I quite like your idea - it does indeed make
sense for kdump to occur if a kdump kernel has been loaded.

Acked-by: Simon Horman <horms at verge.net.au>

> Thanks
> Ken'ichi Ohmichi
> 
> >> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> >> ---
> >> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
> >> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
> >> @@ -57,6 +57,8 @@ struct resource crashk_res = {
> >>  
> >>  int kexec_should_crash(struct task_struct *p)
> >>  {
> >> +	if (kexec_crash_image)
> >> +		return 1;
> >>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> >>  		return 1;
> >>  	return 0;
> >>
> >> _______________________________________________
> >> kexec mailing list
> >> kexec at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
> > 
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> > 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:02:11 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:02:11 +0900
Subject: [PATCH v2 0/7] Patches for kdump vs. INIT
In-Reply-To: <4A39E247.4030908@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com>
Message-ID: <4A5595F3.2050609@jp.fujitsu.com>

Hi all,

Here is the updated version:
 - Better descriptions with justifiable reasons
 - Add comments to point where the mask is removed
 - Move extern to header file
 - Minor fix for style, typo
 - No changes in logic

Thanks,
H.Seto

===

Hidetoshi Seto (7):
      ia64, kdump: Mask MCA/INIT on frozen cpus
      ia64, kexec: Make INIT safe while transition to kdump/kexec kernel
      ia64, kexec: Unregister MCA handler before kexec
      ia64, kdump: Don't return APs to SAL from kdump
      ia64, kdump: Mask INIT first in panic-kdump path
      ia64, kdump: Try INIT regardless of kdump_on_init
      ia64, kdump: Short path to freeze CPUs

 arch/ia64/include/asm/mca.h        |    2 +
 arch/ia64/kernel/crash.c           |   83 ++++++++++++++++++++++++-----------
 arch/ia64/kernel/head.S            |    2 +-
 arch/ia64/kernel/machine_kexec.c   |   15 ++++++
 arch/ia64/kernel/mca.c             |   15 ++++++-
 arch/ia64/kernel/mca_asm.S         |   47 ++++++++++++++++++++
 arch/ia64/kernel/relocate_kernel.S |    2 +-
 7 files changed, 136 insertions(+), 30 deletions(-)

Hidetoshi Seto wrote:
> Hi Tony-san, and kdump folks,
> 
> I got some trouble on kdump on IPF with INIT, and my investigation
> proves there are some bugs and races in startup of kdump.
> Here are fixes based on .30, for issues I found.
> 
> Since it must be serious problem for (likely big) IPF servers if we
> could fail to retrieve crashdump via kdump, so I believe these patches
> should be applied asap.
> 
> 
> Thanks,
> H.Seto
> 
> ===
> 
> Hidetoshi Seto (7):
>       ia64, kdump: Mask MCA/INIT on freezing cpus
>       ia64, kexec: Make INIT safe while kdump/kexec
>       ia64, kexec: Unregister MCA handler before kexec
>       ia64, kdump: Don't offline APs
>       ia64, kdump: Mask INIT first in panic-kdump path
>       ia64, kdump: Try INIT regardless of kdump_on_init
>       ia64, kdump: Short path to freeze CPUs
> 
>  arch/ia64/kernel/crash.c         |   85 ++++++++++++++++++++++++++------------
>  arch/ia64/kernel/machine_kexec.c |   17 ++++++++
>  arch/ia64/kernel/mca.c           |   15 ++++++-
>  arch/ia64/kernel/mca_asm.S       |   47 +++++++++++++++++++++
>  4 files changed, 136 insertions(+), 28 deletions(-)




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:10:05 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:10:05 +0900
Subject: [PATCH v2 1/7] ia64, kdump: Mask MCA/INIT on frozen cpus
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A5597CD.4060201@jp.fujitsu.com>

Summary:

  INIT asserted on kdump kernel invokes INIT handler not only on a
  cpu that running on the kdump kernel, but also BSP of the panicked
  kernel, because the (badly) frozen BSP can be thawed by INIT.

Description:

  The kdump_cpu_freeze() is called on cpus except one that initiates
  panic and/or kdump, to stop/offline the cpu (on ia64, it means we
  pass control of cpus to SAL, or put them in spinloop).  Note that
  CPU0(BSP) always go to spinloop, so if panic was happened on an AP,
  there are at least 2cpus (= the AP and BSP) which not back to SAL.

  On the spinning cpus, interrupts are disabled (rsm psr.i), but INIT
  is still interruptible because psr.mc for mask them is not set unless
  kdump_cpu_freeze() is not called from MCA/INIT context.

  Therefore, assume that a panic was happened on an AP, kdump was
  invoked, new INIT handlers for kdump kernel was registered and then
  an INIT is asserted.  From the viewpoint of SAL, there are 2 online
  cpus, so INIT will be delivered to both of them.  It likely means
  that not only the AP (= a cpu executing kdump) enters INIT handler
  which is newly registered, but also BSP (= another cpu spinning in
  panicked kernel) enters the same INIT handler.  Of course setting of
  registers in BSP are still old (for panicked kernel), so what happen
  with running handler with wrong setting will be extremely unexpected.
  I believe this is not desirable behavior.

How to Reproduce:

  Start kdump on one of APs (e.g. cpu1)
    # taskset 0x2 echo c > /proc/sysrq-trigger
  Then assert INIT after kdump kernel is booted, after new INIT handler
  for kdump kernel is registered.

Expected results:

  An INIT handler is invoked only on the AP.

Actual results:

  An INIT handler is invoked on the AP and BSP.

Sample of results:

  I got following console log by asserting INIT after prompt "root:/>".
  It seems that two monarchs appeared by one INIT, and one panicked at
  last.  And it also seems that the panicked one supposed there were
  4 online cpus and no one did rendezvous:

    :
    [  0 %]dropping to initramfs shell
    exiting this shell will reboot your system
    root:/> Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=0
    ia64_init_handler: Promoting cpu 0 to monarch.
    Delaying for 5 seconds...
    All OS INIT slaves have reached rendezvous
    Processes interrupted by INIT - 0 (cpu 0 task 0xa000000100af0000)
    :
    <<snip>>
    :
    Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=1
    Delaying for 5 seconds...
    mlogbuf_finish: printing switched to urgent mode, MCA/INIT might be dodgy or fail.
    OS INIT slave did not rendezvous on cpu 1 2 3
    INIT swapper 0[0]: bugcheck! 0 [1]
    :
    <<snip>>
    :
    Kernel panic - not syncing: Attempted to kill the idle task!

Proposed fix:

  To avoid this problem, this patch inserts ia64_set_psr_mc() to mask
  INIT on cpus going to be frozen.  This masking have no effect if the
  kdump_cpu_freeze() is called from INIT handler when kdump_on_init == 1,
  because psr.mc is already turned on to 1 before entering OS_INIT.
  I confirmed that weird log like above are disappeared after applying
  this patch.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/include/asm/mca.h |    1 +
 arch/ia64/kernel/crash.c    |    4 ++++
 arch/ia64/kernel/head.S     |    2 +-
 arch/ia64/kernel/mca_asm.S  |   27 +++++++++++++++++++++++++++
 4 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/include/asm/mca.h b/arch/ia64/include/asm/mca.h
index 44a0b53..cb0952f 100644
--- a/arch/ia64/include/asm/mca.h
+++ b/arch/ia64/include/asm/mca.h
@@ -151,6 +151,7 @@ extern void ia64_mca_cmc_vector_setup(void);
 extern int  ia64_reg_MCA_extension(int (*fn)(void *, struct ia64_sal_os_state *));
 extern void ia64_unreg_MCA_extension(void);
 extern unsigned long ia64_get_rnat(unsigned long *);
+extern void ia64_set_psr_mc(void);
 extern void ia64_mca_printk(const char * fmt, ...)
 	 __attribute__ ((format (printf, 1, 2)));
 
diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
index f065093..3f3a579 100644
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -129,10 +129,14 @@ void
 kdump_cpu_freeze(struct unw_frame_info *info, void *arg)
 {
 	int cpuid;
+
 	local_irq_disable();
 	cpuid = smp_processor_id();
 	crash_save_this_cpu();
 	current->thread.ksp = (__u64)info->sw - 16;
+
+	ia64_set_psr_mc();	/* mask MCA/INIT and stop reentrance */
+
 	atomic_inc(&kdump_cpu_frozen);
 	kdump_status[cpuid] = 1;
 	mb();
diff --git a/arch/ia64/kernel/head.S b/arch/ia64/kernel/head.S
index 23f846d..e1f97ac 100644
--- a/arch/ia64/kernel/head.S
+++ b/arch/ia64/kernel/head.S
@@ -1242,7 +1242,7 @@ GLOBAL_ENTRY(ia64_jump_to_sal)
 	movl r16=SAL_PSR_BITS_TO_SET;;
 	mov cr.ipsr=r16
 	mov cr.ifs=r0;;
-	rfi;;
+	rfi;;			// note: this unmask MCA/INIT (psr.mc)
 1:
 	/*
 	 * Invalidate all TLB data/inst
diff --git a/arch/ia64/kernel/mca_asm.S b/arch/ia64/kernel/mca_asm.S
index a06d465..8d2eabe 100644
--- a/arch/ia64/kernel/mca_asm.S
+++ b/arch/ia64/kernel/mca_asm.S
@@ -1073,3 +1073,30 @@ GLOBAL_ENTRY(ia64_get_rnat)
 	mov ar.rsc=3
 	br.ret.sptk.many rp
 END(ia64_get_rnat)
+
+
+// void ia64_set_psr_mc(void)
+//
+// Set psr.mc bit to mask MCA/INIT.
+GLOBAL_ENTRY(ia64_set_psr_mc)
+	rsm psr.i | psr.ic		// disable interrupts
+	;;
+	srlz.d
+	;;
+	mov r14 = psr			// get psr{36:35,31:0}
+	movl r15 = 1f
+	;;
+	dep r14 = -1, r14, PSR_MC, 1	// set psr.mc
+	;;
+	dep r14 = -1, r14, PSR_IC, 1	// set psr.ic
+	;;
+	dep r14 = -1, r14, PSR_BN, 1	// keep bank1 in use
+	;;
+	mov cr.ipsr = r14
+	mov cr.ifs = r0
+	mov cr.iip = r15
+	;;
+	rfi
+1:
+	br.ret.sptk.many rp
+END(ia64_set_psr_mc)
-- 
1.6.0




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:11:46 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:11:46 +0900
Subject: [PATCH v2 2/7] ia64,
	kexec: Make INIT safe while transition to kdump/kexec kernel
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A559832.3080000@jp.fujitsu.com>

Summary:

  Asserting INIT on the beginning of kdump/kexec kernel will result
  in unexpected behavior because INIT handler for previous kernel is
  invoked on new kernel.

Description:

  In panic situation, we can receive INIT while kernel transition,
  i.e. from beginning of panic to bootstrap of kdump kernel.
  Since we initialize registers on leave from current kernel, no
  longer monarch/slave handlers of current kernel in virtual mode are
  called safely.  (In fact system goes hang as far as I confirmed)

How to Reproduce:

  Start kdump
    # echo c > /proc/sysrq-trigger
  Then assert INIT while kdump kernel is booting, before new INIT
  handler for kdump kernel is registered.

Expected(Desirable) result:

  kdump kernel boots without any problem, crashdump retrieved

Actual result:

  INIT handler for previous kernel is invoked on kdump kernel
  => panic, hang etc. (unexpected)

Proposed fix:

  We can unregister these init handlers from SAL before jumping into
  new kernel, however then the INIT will fallback to default behavior,
  result in warmboot by SAL (according to the SAL specification) and
  we cannot retrieve the crashdump.

  Therefore this patch introduces a NOP init handler and register it
  to SAL before leave from current kernel, to start kdump safely by
  preventing INITs from entering virtual mode and resulting in warmboot.

  On the other hand, in case of kexec that not for kdump, it also
  has same problem with INIT while kernel transition.
  This patch handles this case differently, because for kexec
  unregistering handlers will be preferred than registering NOP
  handler, since the situation "no handlers registered" is usual
  state for kernel's entry.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/include/asm/mca.h      |    1 +
 arch/ia64/kernel/machine_kexec.c |   12 ++++++++++++
 arch/ia64/kernel/mca_asm.S       |   20 ++++++++++++++++++++
 3 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/ia64/include/asm/mca.h b/arch/ia64/include/asm/mca.h
index cb0952f..c171cdf 100644
--- a/arch/ia64/include/asm/mca.h
+++ b/arch/ia64/include/asm/mca.h
@@ -145,6 +145,7 @@ extern void ia64_mca_ucmc_handler(struct pt_regs *, struct ia64_sal_os_state *);
 extern void ia64_init_handler(struct pt_regs *,
 			      struct switch_stack *,
 			      struct ia64_sal_os_state *);
+extern void ia64_os_init_on_kdump(void);
 extern void ia64_monarch_init_handler(void);
 extern void ia64_slave_init_handler(void);
 extern void ia64_mca_cmc_vector_setup(void);
diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index 0823de1..571d663 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -24,6 +24,8 @@
 #include <asm/delay.h>
 #include <asm/meminit.h>
 #include <asm/processor.h>
+#include <asm/sal.h>
+#include <asm/mca.h>
 
 typedef NORET_TYPE void (*relocate_new_kernel_t)(
 					unsigned long indirection_page,
@@ -85,11 +87,21 @@ static void ia64_machine_kexec(struct unw_frame_info *info, void *arg)
 	void *pal_addr = efi_get_pal_addr();
 	unsigned long code_addr = (unsigned long)page_address(image->control_code_page);
 	int ii;
+	u64 fp, gp;
+	ia64_fptr_t *init_handler = (ia64_fptr_t *)ia64_os_init_on_kdump;
 
 	BUG_ON(!image);
 	if (image->type == KEXEC_TYPE_CRASH) {
 		crash_save_this_cpu();
 		current->thread.ksp = (__u64)info->sw - 16;
+
+		/* Register noop init handler */
+		fp = ia64_tpa(init_handler->fp);
+		gp = ia64_tpa(ia64_getreg(_IA64_REG_GP));
+		ia64_sal_set_vectors(SAL_VECTOR_OS_INIT, fp, gp, 0, fp, gp, 0);
+	} else {
+		/* Unregister init handlers of current kernel */
+		ia64_sal_set_vectors(SAL_VECTOR_OS_INIT, 0, 0, 0, 0, 0, 0);
 	}
 
 	/* Interrupts aren't acceptable while we reboot */
diff --git a/arch/ia64/kernel/mca_asm.S b/arch/ia64/kernel/mca_asm.S
index 8d2eabe..7461d25 100644
--- a/arch/ia64/kernel/mca_asm.S
+++ b/arch/ia64/kernel/mca_asm.S
@@ -40,6 +40,7 @@
 
 	.global ia64_do_tlb_purge
 	.global ia64_os_mca_dispatch
+	.global ia64_os_init_on_kdump
 	.global ia64_os_init_dispatch_monarch
 	.global ia64_os_init_dispatch_slave
 
@@ -299,6 +300,25 @@ END(ia64_os_mca_virtual_begin)
 //StartMain////////////////////////////////////////////////////////////////////
 
 //
+// NOP init handler for kdump.  In panic situation, we may receive INIT
+// while kernel transition.  Since we initialize registers on leave from
+// current kernel, no longer monarch/slave handlers of current kernel in
+// virtual mode are called safely.
+// We can unregister these init handlers from SAL, however then the INIT
+// will result in warmboot by SAL and we cannot retrieve the crashdump.
+// Therefore register this NOP function to SAL, to prevent entering virtual
+// mode and resulting warmboot by SAL.
+//
+ia64_os_init_on_kdump:
+	mov		r8=r0		// IA64_INIT_RESUME
+	mov             r9=r10		// SAL_GP
+	mov		r22=r17		// *minstate
+	;;
+	mov		r10=r0		// return to same context
+	mov		b0=r12		// SAL_CHECK return address
+	br		b0
+
+//
 // SAL to OS entry point for INIT on all processors.  This has been defined for
 // registration purposes with SAL as a part of ia64_mca_init.  Monarch and
 // slave INIT have identical processing, except for the value of the
-- 
1.6.0




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:12:48 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:12:48 +0900
Subject: [PATCH v2 3/7] ia64, kexec: Unregister MCA handler before kexec
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A559870.7090801@jp.fujitsu.com>

Summary:

  MCA on the beginning of kdump/kexec kernel will result in unexpected
  behavior because MCA handler for previous kernel is invoked on the
  kdump kernel.

Description:

  Once a cpu is passed to new kernel, all resources in previous kernel
  should not be used from the cpu.  Even the resources for MCA handler
  are no exception.  So we cannot handle MCAs and its machine check
  errors during kernel transition, until new handler for new kernel is
  registered with new resources ready for handling the MCA.

How to reproduce:

  Assert MCA while kdump kernel is booting, before new MCA handler for
  kdump kernel is registered.

Expected(Desirable) results:

  No recovery, cancel kdump and reboot the system.

Actual results:

  MCA handler for previous kernel is invoked on the kdump kernel.
  => panic, hang etc. (unexpected)

Proposed fix:

  To avoid entering MCA handler from early stage of new kernel,
  unregister the entry point from SAL before leave from current
  kernel.  Then SAL will make all MCAs to warmboot safely, without
  invoking OS_MCA.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/kernel/machine_kexec.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index 571d663..3d3aeef 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -104,6 +104,9 @@ static void ia64_machine_kexec(struct unw_frame_info *info, void *arg)
 		ia64_sal_set_vectors(SAL_VECTOR_OS_INIT, 0, 0, 0, 0, 0, 0);
 	}
 
+	/* Unregister mca handler - No more recovery on current kernel */
+	ia64_sal_set_vectors(SAL_VECTOR_OS_MCA, 0, 0, 0, 0, 0, 0);
+
 	/* Interrupts aren't acceptable while we reboot */
 	local_irq_disable();
 
-- 
1.6.0




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:14:28 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:14:28 +0900
Subject: [PATCH v2 4/7] ia64, kdump: Don't return APs to SAL from kdump
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A5598D4.3060001@jp.fujitsu.com>

Summary:

  Asserting INIT on cpu going to be offline will result in unexpected
  behavior.  It will be a real problem in kdump cases where INIT might
  be asserted to unstable APs going to be offline by returning to SAL.

Description:

  Since psr.mc is cleared when bits in psr are set to SAL_PSR_BITS_TO_SET
  in ia64_jump_to_sal(), there is a small window (~few msecs) that the
  cpu can receive INIT even if the cpu enter there via INIT handler.
  In this window we do restore of registers for SAL, so INIT asserted
  here will not work properly.

  It is hard to remove this window by masking INIT (i.e. setting psr.mc)
  because we have to unmask it later in OS, because we have to use branch
  instruction (br.ret, not rfi) to return SAL, due to OS_BOOT_RENDEZ to
  SAL return convention.

  I suppose this window will not be a real problem on cpu offline if we
  can educate people not to push INIT button during hotplug operation.
  However, only exception is a race in kdump and INIT.  Now kdump returns
  APs to SAL before processing dump, but the kernel might receive INIT at
  that point in time.  Such INIT might be asserted by kdump itself if an
  AP doesn't react IPI soon and kdump decided to use INIT to stop the AP.
  Or it might be asserted by operator or an external agent to start dump
  on the unstable system.

  Such panic+INIT or INIT+INIT cases should be rare, but it will be happy
  if we can retrieve crashdump even in such cases.

How to reproduce:

  panic+INIT or INIT+INIT, with kdump configured

Expected results:

  crashdump is retrieved anyway

Actual results:

  panic, hang etc. (unexpected)

Proposed fix

  To avoid the window on the way to SAL, this patch stops returning APs
  to SAL in case of kdump.  In other words, this patch makes APs spin
  in OS instead of spinning in SAL.

  (* Note: What impact would be there?  If a cpu is spinning in SAL,
   the cpu is in BOOT_RENDEZ loop, as same as offlined cpu.
   In theory if an INIT is asserted there, cpus in the BOOT_RENDEZ loop
   should not invoke OS_INIT on it.  So in either way, no matter where
   the cpu is spinning actually in, once cpu starts spin and act as
   "frozen," INIT on the cpu have no effects.
   From another point of view, all debug information on the cpu should
   have stored to memory before the cpu start to be frozen.  So no more
   action on the cpu is required.)

  I confirmed that the kdump sometime hangs by concurrent INITs (another
  INIT after an INIT), and it doesn't hang after applying this patch.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/kernel/crash.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
index 3f3a579..b2a8b3d 100644
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -140,10 +140,6 @@ kdump_cpu_freeze(struct unw_frame_info *info, void *arg)
 	atomic_inc(&kdump_cpu_frozen);
 	kdump_status[cpuid] = 1;
 	mb();
-#ifdef CONFIG_HOTPLUG_CPU
-	if (cpuid != 0)
-		ia64_jump_to_sal(&sal_boot_rendez_state[cpuid]);
-#endif
 	for (;;)
 		cpu_relax();
 }
-- 
1.6.0




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:15:53 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:15:53 +0900
Subject: [PATCH v2 5/7] ia64, kdump: Mask INIT first in panic-kdump path
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A559929.6040600@jp.fujitsu.com>

Summary:

  Asserting INIT might block kdump if the system is already going to
  start kdump via panic.

Description:

  INIT can interrupt anywhere in panic path, so it can interrupt in
  middle of kdump kicked by panic.  Therefore there is a race if kdump
  is kicked concurrently, via Panic and via INIT.

  INIT could fail to invoke kdump if the system is already going to
  start kdump via panic.  It could not restart kdump from INIT handler
  if some of cpus are already playing dead with INIT masked.  It also
  means that INIT could block kdump's progress if no monarch is entered
  in the INIT rendezvous.

  Panic+INIT is a rare, but possible situation since it can be assumed
  that the kernel or an internal agent decides to panic the unstable
  system while another external agent decides to send an INIT to the
  system at same time.

How to reproduce:

  Assert INIT just after panic, before all other cpus have frozen

Expected results:

  continue kdump invoked by panic, or restart kdump from INIT

Actual results:

  might be hang, crashdump not retrieved

Proposed Fix:

  This patch masks INIT first in panic path to take the initiative on
  kdump, and reuse atomic value kdump_in_progress to make sure there is
  only one initiator of kdump.  All INITs asserted later should be used
  only for freezing all other cpus.

  This mask will be removed soon by rfi in relocate_kernel.S, before jump
  into kdump kernel, after all cpus are frozen and no-op INIT handler is
  registered.  So if INIT was in the interval while it is masked, it will
  pend on the system and will received just after the rfi, and handled by
  the no-op handler.

  If there was a MCA event while psr.mc is 1, in theory the event will
  pend on the system and will received just after the rfi same as above.
  MCA handler is unregistered here at the time, so received MCA will not
  reach to OS_MCA and will result in warmboot by SAL.

  Note that codes in this masked interval are relatively simpler than
  that in MCA/INIT handler which also executed with the mask.  So it can
  be said that probability of error in this interval is supposed not so
  higher than that in MCA/INIT handler.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/kernel/crash.c           |   47 +++++++++++++++++++++++++++++++----
 arch/ia64/kernel/relocate_kernel.S |    2 +-
 2 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
index b2a8b3d..9c851b7 100644
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -23,6 +23,7 @@
 int kdump_status[NR_CPUS];
 static atomic_t kdump_cpu_frozen;
 atomic_t kdump_in_progress;
+static int kdump_freeze_monarch;
 static int kdump_on_init = 1;
 static int kdump_on_fatal_mca = 1;
 
@@ -108,6 +109,33 @@ machine_crash_shutdown(struct pt_regs *pt)
 	 */
 	kexec_disable_iosapic();
 #ifdef CONFIG_SMP
+	/*
+	 * If kdump_on_init is set and an INIT is asserted here, kdump will
+	 * be started again via INIT monarch.
+	 */
+	local_irq_disable();
+	ia64_set_psr_mc();	/* mask MCA/INIT */
+	if (atomic_inc_return(&kdump_in_progress) != 1)
+		unw_init_running(kdump_cpu_freeze, NULL);
+
+	/*
+	 * Now this cpu is ready for kdump.
+	 * Stop all others by IPI or INIT.  They could receive INIT from
+	 * outside and might be INIT monarch, but only thing they have to
+	 * do is falling into kdump_cpu_freeze().
+	 *
+	 * If an INIT is asserted here:
+	 * - All receivers might be slaves, since some of cpus could already
+	 *   be frozen and INIT might be masked on monarch.  In this case,
+	 *   all slaves will park in while (monarch_cpu == -1) loop before
+	 *   DIE_INIT_SLAVE_ENTER that for waiting monarch enters.
+	 *	=> TBD: freeze all slaves
+	 * - One might be a monarch, but INIT rendezvous will fail since
+	 *   at least this cpu already have INIT masked so it never join
+	 *   to the rendezvous.  In this case, all slaves and monarch will
+	 *   be frozen after timeout of the INIT rendezvous.
+	 *	=> TBD: freeze them without waiting timeout
+	 */
 	kdump_smp_send_stop();
 	/* not all cpu response to IPI, send INIT to freeze them */
 	if (kdump_wait_cpu_freeze() && kdump_on_init) 	{
@@ -177,13 +205,18 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 	switch (val) {
 	case DIE_INIT_MONARCH_PROCESS:
 		if (kdump_on_init) {
-			atomic_set(&kdump_in_progress, 1);
+			if (atomic_inc_return(&kdump_in_progress) != 1)
+				kdump_freeze_monarch = 1;
 			*(nd->monarch_cpu) = -1;
 		}
 		break;
 	case DIE_INIT_MONARCH_LEAVE:
-		if (kdump_on_init)
-			machine_kdump_on_init();
+		if (kdump_on_init) {
+			if (kdump_freeze_monarch)
+				unw_init_running(kdump_cpu_freeze, NULL);
+			else
+				machine_kdump_on_init();
+		}
 		break;
 	case DIE_INIT_SLAVE_LEAVE:
 		if (atomic_read(&kdump_in_progress))
@@ -196,9 +229,11 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 	case DIE_MCA_MONARCH_LEAVE:
 		/* *(nd->data) indicate if MCA is recoverable */
 		if (kdump_on_fatal_mca && !(*(nd->data))) {
-			atomic_set(&kdump_in_progress, 1);
-			*(nd->monarch_cpu) = -1;
-			machine_kdump_on_init();
+			if (atomic_inc_return(&kdump_in_progress) == 1) {
+				*(nd->monarch_cpu) = -1;
+				machine_kdump_on_init();
+			}
+			/* We got fatal MCA while kdump!? No way!! */
 		}
 		break;
 	}
diff --git a/arch/ia64/kernel/relocate_kernel.S b/arch/ia64/kernel/relocate_kernel.S
index 903babd..32f6fc1 100644
--- a/arch/ia64/kernel/relocate_kernel.S
+++ b/arch/ia64/kernel/relocate_kernel.S
@@ -52,7 +52,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
 	srlz.i
 	;;
 	mov ar.rnat=r18
-	rfi
+	rfi				// note: this unmask MCA/INIT (psr.mc)
 	;;
 1:
 	//physical mode code begin
-- 
1.6.0




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:17:18 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:17:18 +0900
Subject: [PATCH v2 6/7] ia64, kdump: Try INIT regardless of kdump_on_init
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A55997E.8020903@jp.fujitsu.com>

CPUs should be frozen if possible, otherwise it might hinder kdump.
So if there are CPUs not respond to IPI, try INIT to stop them.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/kernel/crash.c |   43 +++++++++++++++++++++----------------------
 1 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
index 9c851b7..0995fdc 100644
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -138,8 +138,10 @@ machine_crash_shutdown(struct pt_regs *pt)
 	 */
 	kdump_smp_send_stop();
 	/* not all cpu response to IPI, send INIT to freeze them */
-	if (kdump_wait_cpu_freeze() && kdump_on_init) 	{
+	if (kdump_wait_cpu_freeze()) {
 		kdump_smp_send_init();
+		/* wait again, don't go ahead if possible */
+		kdump_wait_cpu_freeze();
 	}
 #endif
 }
@@ -178,6 +180,19 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 	struct ia64_mca_notify_die *nd;
 	struct die_args *args = data;
 
+	if (atomic_read(&kdump_in_progress)) {
+		switch (val) {
+		case DIE_INIT_MONARCH_LEAVE:
+			if (!kdump_freeze_monarch)
+				break;
+			/* fall through */
+		case DIE_INIT_SLAVE_LEAVE:
+		case DIE_MCA_RENDZVOUS_LEAVE:
+			unw_init_running(kdump_cpu_freeze, NULL);
+			break;
+		}
+	}
+
 	if (!kdump_on_init && !kdump_on_fatal_mca)
 		return NOTIFY_DONE;
 
@@ -190,41 +205,25 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 	}
 
 	if (val != DIE_INIT_MONARCH_LEAVE &&
-	    val != DIE_INIT_SLAVE_LEAVE &&
 	    val != DIE_INIT_MONARCH_PROCESS &&
-	    val != DIE_MCA_RENDZVOUS_LEAVE &&
 	    val != DIE_MCA_MONARCH_LEAVE)
 		return NOTIFY_DONE;
 
 	nd = (struct ia64_mca_notify_die *)args->err;
-	/* Reason code 1 means machine check rendezvous*/
-	if ((val == DIE_INIT_MONARCH_LEAVE || val == DIE_INIT_SLAVE_LEAVE
-	    || val == DIE_INIT_MONARCH_PROCESS) && nd->sos->rv_rc == 1)
-		return NOTIFY_DONE;
 
 	switch (val) {
 	case DIE_INIT_MONARCH_PROCESS:
-		if (kdump_on_init) {
+		/* Reason code 1 means machine check rendezvous*/
+		if (kdump_on_init && (nd->sos->rv_rc != 1)) {
 			if (atomic_inc_return(&kdump_in_progress) != 1)
 				kdump_freeze_monarch = 1;
 			*(nd->monarch_cpu) = -1;
 		}
 		break;
 	case DIE_INIT_MONARCH_LEAVE:
-		if (kdump_on_init) {
-			if (kdump_freeze_monarch)
-				unw_init_running(kdump_cpu_freeze, NULL);
-			else
-				machine_kdump_on_init();
-		}
-		break;
-	case DIE_INIT_SLAVE_LEAVE:
-		if (atomic_read(&kdump_in_progress))
-			unw_init_running(kdump_cpu_freeze, NULL);
-		break;
-	case DIE_MCA_RENDZVOUS_LEAVE:
-		if (atomic_read(&kdump_in_progress))
-			unw_init_running(kdump_cpu_freeze, NULL);
+		/* Reason code 1 means machine check rendezvous*/
+		if (kdump_on_init && (nd->sos->rv_rc != 1))
+			machine_kdump_on_init();
 		break;
 	case DIE_MCA_MONARCH_LEAVE:
 		/* *(nd->data) indicate if MCA is recoverable */
-- 
1.6.0




From seto.hidetoshi at jp.fujitsu.com  Thu Jul  9 03:18:42 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Thu, 09 Jul 2009 16:18:42 +0900
Subject: [PATCH v2 7/7] ia64, kdump: Short path to freeze CPUs
In-Reply-To: <4A5595F3.2050609@jp.fujitsu.com>
References: <4A39E247.4030908@jp.fujitsu.com> <4A5595F3.2050609@jp.fujitsu.com>
Message-ID: <4A5599D2.7080604@jp.fujitsu.com>

Setting monarch_cpu = -1 to let slaves frozen might not work, because
there might be slaves being late, not entered the rendezvous yet.
Such slaves might be caught in while (monarch_cpu == -1) loop.

Use kdump_in_progress instead of monarch_cpus to break INIT rendezvous
and let all slaves enter DIE_INIT_SLAVE_LEAVE smoothly.

And monarch no longer need to manage rendezvous if once kdump_in_progress
is set, catch the monarch in DIE_INIT_MONARCH_ENTER then.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Haren Myneni <hbabu at us.ibm.com>
Cc: kexec at lists.infradead.org
---
 arch/ia64/kernel/crash.c |   15 ++++++---------
 arch/ia64/kernel/mca.c   |   15 +++++++++++++--
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
index 0995fdc..6631a9d 100644
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -127,14 +127,13 @@ machine_crash_shutdown(struct pt_regs *pt)
 	 * If an INIT is asserted here:
 	 * - All receivers might be slaves, since some of cpus could already
 	 *   be frozen and INIT might be masked on monarch.  In this case,
-	 *   all slaves will park in while (monarch_cpu == -1) loop before
-	 *   DIE_INIT_SLAVE_ENTER that for waiting monarch enters.
-	 *	=> TBD: freeze all slaves
+	 *   all slaves will be frozen soon since kdump_in_progress will let
+	 *   them into DIE_INIT_SLAVE_LEAVE.
 	 * - One might be a monarch, but INIT rendezvous will fail since
 	 *   at least this cpu already have INIT masked so it never join
 	 *   to the rendezvous.  In this case, all slaves and monarch will
-	 *   be frozen after timeout of the INIT rendezvous.
-	 *	=> TBD: freeze them without waiting timeout
+	 *   be frozen soon with no wait since the INIT rendezvous is skipped
+	 *   by kdump_in_progress.
 	 */
 	kdump_smp_send_stop();
 	/* not all cpu response to IPI, send INIT to freeze them */
@@ -187,6 +186,7 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 				break;
 			/* fall through */
 		case DIE_INIT_SLAVE_LEAVE:
+		case DIE_INIT_MONARCH_ENTER:
 		case DIE_MCA_RENDZVOUS_LEAVE:
 			unw_init_running(kdump_cpu_freeze, NULL);
 			break;
@@ -217,7 +217,6 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 		if (kdump_on_init && (nd->sos->rv_rc != 1)) {
 			if (atomic_inc_return(&kdump_in_progress) != 1)
 				kdump_freeze_monarch = 1;
-			*(nd->monarch_cpu) = -1;
 		}
 		break;
 	case DIE_INIT_MONARCH_LEAVE:
@@ -228,10 +227,8 @@ kdump_init_notifier(struct notifier_block *self, unsigned long val, void *data)
 	case DIE_MCA_MONARCH_LEAVE:
 		/* *(nd->data) indicate if MCA is recoverable */
 		if (kdump_on_fatal_mca && !(*(nd->data))) {
-			if (atomic_inc_return(&kdump_in_progress) == 1) {
-				*(nd->monarch_cpu) = -1;
+			if (atomic_inc_return(&kdump_in_progress) == 1)
 				machine_kdump_on_init();
-			}
 			/* We got fatal MCA while kdump!? No way!! */
 		}
 		break;
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 7b30d21..d2877a7 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1682,14 +1682,25 @@ ia64_init_handler(struct pt_regs *regs, struct switch_stack *sw,
 
 	if (!sos->monarch) {
 		ia64_mc_info.imi_rendez_checkin[cpu] = IA64_MCA_RENDEZ_CHECKIN_INIT;
+
+#ifdef CONFIG_KEXEC
+		while (monarch_cpu == -1 && !atomic_read(&kdump_in_progress))
+			udelay(1000);
+#else
 		while (monarch_cpu == -1)
-		       cpu_relax();	/* spin until monarch enters */
+			cpu_relax();	/* spin until monarch enters */
+#endif
 
 		NOTIFY_INIT(DIE_INIT_SLAVE_ENTER, regs, (long)&nd, 1);
 		NOTIFY_INIT(DIE_INIT_SLAVE_PROCESS, regs, (long)&nd, 1);
 
+#ifdef CONFIG_KEXEC
+		while (monarch_cpu != -1 && !atomic_read(&kdump_in_progress))
+			udelay(1000);
+#else
 		while (monarch_cpu != -1)
-		       cpu_relax();	/* spin until monarch leaves */
+			cpu_relax();	/* spin until monarch leaves */
+#endif
 
 		NOTIFY_INIT(DIE_INIT_SLAVE_LEAVE, regs, (long)&nd, 1);
 
-- 
1.6.0




From oomichi at mxs.nes.nec.co.jp  Thu Jul  9 03:17:22 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Thu, 09 Jul 2009 16:17:22 +0900
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <20090709055234.GA7282@verge.net.au>
References: <4A5422E3.1030600@mxs.nes.nec.co.jp>
	<20090708091852.GF4040@verge.net.au>
	<4A553D27.8050005@mxs.nes.nec.co.jp>
	<20090709055234.GA7282@verge.net.au>
Message-ID: <4A559982.8000003@mxs.nes.nec.co.jp>


Hi Simon,

Thank you so much for your review and comment.

I have one question.
Should I resend the patch to LKML with your "Acked-by:" tag for merging it ?
Or isn't that necessary ?


Thanks
Ken'ichi Ohmichi

Simon Horman wrote:
> On Thu, Jul 09, 2009 at 09:43:19AM +0900, Ken'ichi Ohmichi wrote:
>> Hi Simon,
>>
>> Thank you for the comment.
>>
>> Simon Horman wrote:
>>> On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
>>>> Hi,
>>>>
>>>> This patch enables a kdump if 2nd-kernel is loaded.
>>>> (The patch is based on linux-2.6.31-rc2.)
>>>>
>>>> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
>>>> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
>>>> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
>>>> 2nd-kernel for enabling a kdump.
>>> I'm not sure that I like this change. To my mind, panic on oops
>>> should only occur if specifically requested.
>> My patch does not make panic_on_oops effective when 2nd-kernel is loaded,
>> and it makes a kdump effective.
>>
>> kexec_should_crash() is called only by oops_end() for checking whether to
>> call crash_kexec(). crash_kexec() is not panic, and I feel it is better
>> that crash_kexec() is called when 2nd-kernel is loaded.
>>
>>
>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>> been changed to a NULL pointer error instead of calling crash_kexec()
>> since linux-2.6.31-rc1. Then I tried to boot linux-2.6.31-rc1 *with* a
>> kernel parameter "oops=panic", the kernel got a panic while kernel booting
>> due to a problem other than a kdump. 
>> So I think a kdump should be enabled when 2nd-kernel is loaded.
> 
> Hi,
> 
> thanks for the more detailed explanation. I've reconsidered my position
> and actually I think that I quite like your idea - it does indeed make
> sense for kdump to occur if a kdump kernel has been loaded.
> 
> Acked-by: Simon Horman <horms at verge.net.au>
> 
>> Thanks
>> Ken'ichi Ohmichi
>>
>>>> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
>>>> ---
>>>> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
>>>> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
>>>> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>>>>  
>>>>  int kexec_should_crash(struct task_struct *p)
>>>>  {
>>>> +	if (kexec_crash_image)
>>>> +		return 1;
>>>>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>>>>  		return 1;
>>>>  	return 0;
>>>>
>>>> _______________________________________________
>>>> kexec mailing list
>>>> kexec at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/kexec
>>> _______________________________________________
>>> kexec mailing list
>>> kexec at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
> 




From horms at verge.net.au  Thu Jul  9 03:58:54 2009
From: horms at verge.net.au (Simon Horman)
Date: Thu, 9 Jul 2009 17:58:54 +1000
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A559982.8000003@mxs.nes.nec.co.jp>
References: <4A5422E3.1030600@mxs.nes.nec.co.jp>
	<20090708091852.GF4040@verge.net.au>
	<4A553D27.8050005@mxs.nes.nec.co.jp>
	<20090709055234.GA7282@verge.net.au>
	<4A559982.8000003@mxs.nes.nec.co.jp>
Message-ID: <20090709075854.GB28547@verge.net.au>

On Thu, Jul 09, 2009 at 04:17:22PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi Simon,
> 
> Thank you so much for your review and comment.
> 
> I have one question.
> Should I resend the patch to LKML with your "Acked-by:" tag for merging it ?
> Or isn't that necessary ?

I think sending it to LKML with the acked-by would be a good idea.

> 
> Thanks
> Ken'ichi Ohmichi
> 
> Simon Horman wrote:
> > On Thu, Jul 09, 2009 at 09:43:19AM +0900, Ken'ichi Ohmichi wrote:
> >> Hi Simon,
> >>
> >> Thank you for the comment.
> >>
> >> Simon Horman wrote:
> >>> On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
> >>>> Hi,
> >>>>
> >>>> This patch enables a kdump if 2nd-kernel is loaded.
> >>>> (The patch is based on linux-2.6.31-rc2.)
> >>>>
> >>>> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> >>>> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> >>>> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> >>>> 2nd-kernel for enabling a kdump.
> >>> I'm not sure that I like this change. To my mind, panic on oops
> >>> should only occur if specifically requested.
> >> My patch does not make panic_on_oops effective when 2nd-kernel is loaded,
> >> and it makes a kdump effective.
> >>
> >> kexec_should_crash() is called only by oops_end() for checking whether to
> >> call crash_kexec(). crash_kexec() is not panic, and I feel it is better
> >> that crash_kexec() is called when 2nd-kernel is loaded.
> >>
> >>
> >> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
> >> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
> >> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
> >> been changed to a NULL pointer error instead of calling crash_kexec()
> >> since linux-2.6.31-rc1. Then I tried to boot linux-2.6.31-rc1 *with* a
> >> kernel parameter "oops=panic", the kernel got a panic while kernel booting
> >> due to a problem other than a kdump. 
> >> So I think a kdump should be enabled when 2nd-kernel is loaded.
> > 
> > Hi,
> > 
> > thanks for the more detailed explanation. I've reconsidered my position
> > and actually I think that I quite like your idea - it does indeed make
> > sense for kdump to occur if a kdump kernel has been loaded.
> > 
> > Acked-by: Simon Horman <horms at verge.net.au>
> > 
> >> Thanks
> >> Ken'ichi Ohmichi
> >>
> >>>> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> >>>> ---
> >>>> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
> >>>> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
> >>>> @@ -57,6 +57,8 @@ struct resource crashk_res = {
> >>>>  
> >>>>  int kexec_should_crash(struct task_struct *p)
> >>>>  {
> >>>> +	if (kexec_crash_image)
> >>>> +		return 1;
> >>>>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> >>>>  		return 1;
> >>>>  	return 0;
> >>>>
> >>>> _______________________________________________
> >>>> kexec mailing list
> >>>> kexec at lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/kexec
> >>> _______________________________________________
> >>> kexec mailing list
> >>> kexec at lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/kexec
> >>>
> >>
> >> _______________________________________________
> >> kexec mailing list
> >> kexec at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
> > 
> 


From oomichi at mxs.nes.nec.co.jp  Thu Jul  9 04:01:22 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Thu, 09 Jul 2009 17:01:22 +0900
Subject: [PATCH] Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <20090709075854.GB28547@verge.net.au>
References: <4A5422E3.1030600@mxs.nes.nec.co.jp>	<20090708091852.GF4040@verge.net.au>	<4A553D27.8050005@mxs.nes.nec.co.jp>	<20090709055234.GA7282@verge.net.au>	<4A559982.8000003@mxs.nes.nec.co.jp>
	<20090709075854.GB28547@verge.net.au>
Message-ID: <4A55A3D2.40702@mxs.nes.nec.co.jp>


Hi Simon,

Simon Horman wrote:
> On Thu, Jul 09, 2009 at 04:17:22PM +0900, Ken'ichi Ohmichi wrote:
>> Hi Simon,
>>
>> Thank you so much for your review and comment.
>>
>> I have one question.
>> Should I resend the patch to LKML with your "Acked-by:" tag for merging it ?
>> Or isn't that necessary ?
> 
> I think sending it to LKML with the acked-by would be a good idea.

OK, I will do it.


Thanks
Ken'ichi Ohmichi


>> Simon Horman wrote:
>>> On Thu, Jul 09, 2009 at 09:43:19AM +0900, Ken'ichi Ohmichi wrote:
>>>> Hi Simon,
>>>>
>>>> Thank you for the comment.
>>>>
>>>> Simon Horman wrote:
>>>>> On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This patch enables a kdump if 2nd-kernel is loaded.
>>>>>> (The patch is based on linux-2.6.31-rc2.)
>>>>>>
>>>>>> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
>>>>>> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
>>>>>> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
>>>>>> 2nd-kernel for enabling a kdump.
>>>>> I'm not sure that I like this change. To my mind, panic on oops
>>>>> should only occur if specifically requested.
>>>> My patch does not make panic_on_oops effective when 2nd-kernel is loaded,
>>>> and it makes a kdump effective.
>>>>
>>>> kexec_should_crash() is called only by oops_end() for checking whether to
>>>> call crash_kexec(). crash_kexec() is not panic, and I feel it is better
>>>> that crash_kexec() is called when 2nd-kernel is loaded.
>>>>
>>>>
>>>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>>>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>>>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>>>> been changed to a NULL pointer error instead of calling crash_kexec()
>>>> since linux-2.6.31-rc1. Then I tried to boot linux-2.6.31-rc1 *with* a
>>>> kernel parameter "oops=panic", the kernel got a panic while kernel booting
>>>> due to a problem other than a kdump. 
>>>> So I think a kdump should be enabled when 2nd-kernel is loaded.
>>> Hi,
>>>
>>> thanks for the more detailed explanation. I've reconsidered my position
>>> and actually I think that I quite like your idea - it does indeed make
>>> sense for kdump to occur if a kdump kernel has been loaded.
>>>
>>> Acked-by: Simon Horman <horms at verge.net.au>
>>>
>>>> Thanks
>>>> Ken'ichi Ohmichi
>>>>
>>>>>> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
>>>>>> ---
>>>>>> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
>>>>>> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
>>>>>> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>>>>>>  
>>>>>>  int kexec_should_crash(struct task_struct *p)
>>>>>>  {
>>>>>> +	if (kexec_crash_image)
>>>>>> +		return 1;
>>>>>>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>>>>>>  		return 1;
>>>>>>  	return 0;
>>>>>>
>>>>>> _______________________________________________
>>>>>> kexec mailing list
>>>>>> kexec at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>>> _______________________________________________
>>>>> kexec mailing list
>>>>> kexec at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>>>
>>>> _______________________________________________
>>>> kexec mailing list
>>>> kexec at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/kexec
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 



From oomichi at mxs.nes.nec.co.jp  Thu Jul  9 04:05:02 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Thu, 09 Jul 2009 17:05:02 +0900
Subject: [PATCH] kdump: Enable kdump if 2nd-kernel is loaded.
Message-ID: <4A55A4AE.3000206@mxs.nes.nec.co.jp>


Hi,

This patch enables a kdump if 2nd-kernel is loaded.
(The patch is based on linux-2.6.31-rc2.)

Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
2nd-kernel is loaded. I think that a kdump should be enabled regardless of
"oops=panic" if 2nd-kernel is loaded, because a system administrator loads
2nd-kernel for enabling a kdump.

* Reference
  The discussion about this patch
  http://lists.infradead.org/pipermail/kexec/2009-July/003417.html


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
Acked-by: Simon Horman <horms at verge.net.au>
---
--- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
+++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
@@ -57,6 +57,8 @@ struct resource crashk_res = {
 
 int kexec_should_crash(struct task_struct *p)
 {
+	if (kexec_crash_image)
+		return 1;
 	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
 		return 1;
 	return 0;

_______________________________________________
kexec mailing list
kexec at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec



From seto.hidetoshi at jp.fujitsu.com  Fri Jul 10 02:32:09 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Fri, 10 Jul 2009 15:32:09 +0900
Subject: [PATCH] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
Message-ID: <4A56E069.5040907@jp.fujitsu.com>

Hi Ohmichi-san,

Ken'ichi Ohmichi wrote:
> Hi,
> 
> This patch enables a kdump if 2nd-kernel is loaded.
> (The patch is based on linux-2.6.31-rc2.)
> 
> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> 2nd-kernel for enabling a kdump.

I think this description is slightly wrong because kdump will be invoked
from panic, regardless of the panic_on_oops.

Maybe:
 A kdump on oops is enabled if a kernel parameter "oops=panic" ...
         ~~~~~~~

> 
> * Reference
>   The discussion about this patch
>   http://lists.infradead.org/pipermail/kexec/2009-July/003417.html

I'd like to quote your comment:

>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>> been changed to a NULL pointer error instead of calling crash_kexec()
>> since linux-2.6.31-rc1.

So the real problem is that kdump is not triggered by the NULL pointer oops
if !panic_on_oops, isn't it?

It seems that you should report this trouble of sysrq-c as a regression.

> 
> 
> Thanks
> Ken'ichi Ohmichi
> 
> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> Acked-by: Simon Horman <horms at verge.net.au>
> ---
> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>  
>  int kexec_should_crash(struct task_struct *p)
>  {
> +	if (kexec_crash_image)
> +		return 1;
>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>  		return 1;
>  	return 0;

I think kexec cannot crash if there is no image, right?

Then:

 if (kexec_crash_image)
 	return 1;
 return 0;

or

 return (kexec_crash_image) ? 1 : 0;

or

 since crash_kexec() is nop if !kexec_crash_image,
 replace all:
   if (kexec_should_crash(p))
   	crash_kexec(reg);
 at everywhere in kernel to a simple line:
   crash_kexec(reg);
 and remove kexec_should_crash() completely

would be better fix.


Thanks,
H.Seto



From oomichi at mxs.nes.nec.co.jp  Fri Jul 10 03:05:31 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Fri, 10 Jul 2009 16:05:31 +0900
Subject: [PATCH] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A56E069.5040907@jp.fujitsu.com>
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
	<4A56E069.5040907@jp.fujitsu.com>
Message-ID: <4A56E83B.50600@mxs.nes.nec.co.jp>


Hi Seto-san,

Thank you for your comment.

Hidetoshi Seto wrote:
>> This patch enables a kdump if 2nd-kernel is loaded.
>> (The patch is based on linux-2.6.31-rc2.)
>>
>> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
>> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
>> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
>> 2nd-kernel for enabling a kdump.
> 
> I think this description is slightly wrong because kdump will be invoked
> from panic, regardless of the panic_on_oops.
> 
> Maybe:
>  A kdump on oops is enabled if a kernel parameter "oops=panic" ...
>          ~~~~~~~

Right, I should add "on oops" to the above description.


>> * Reference
>>   The discussion about this patch
>>   http://lists.infradead.org/pipermail/kexec/2009-July/003417.html
> 
> I'd like to quote your comment:
> 
>>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>>> been changed to a NULL pointer error instead of calling crash_kexec()
>>> since linux-2.6.31-rc1.
> 
> So the real problem is that kdump is not triggered by the NULL pointer oops
> if !panic_on_oops, isn't it?
>
> It seems that you should report this trouble of sysrq-c as a regression.

I don't think this problem is a regression of sysrq-c.
This change of sysrq-c looks reasonable to me. Because sysrq-c is used
for the test of kdump, and its code path has been changed to the same
path as a kdump on oops (a real problem, not test).
So we can test a kdump by a real oops, that is good to me.
As a result, I could find this problem a kdump is not enabled without
"oops=panic".


>> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
>> Acked-by: Simon Horman <horms at verge.net.au>
>> ---
>> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
>> +++ b/kernel/kexec.c	2009-07-08 12:38:08.000000000 +0900
>> @@ -57,6 +57,8 @@ struct resource crashk_res = {
>>  
>>  int kexec_should_crash(struct task_struct *p)
>>  {
>> +	if (kexec_crash_image)
>> +		return 1;
>>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>>  		return 1;
>>  	return 0;
> 
> I think kexec cannot crash if there is no image, right?
> 
> Then:
> 
>  if (kexec_crash_image)
>  	return 1;
>  return 0;
> 
> or
> 
>  return (kexec_crash_image) ? 1 : 0;
> 
> or
> 
>  since crash_kexec() is nop if !kexec_crash_image,
>  replace all:
>    if (kexec_should_crash(p))
>    	crash_kexec(reg);
>  at everywhere in kernel to a simple line:
>    crash_kexec(reg);
>  and remove kexec_should_crash() completely
> 
> would be better fix.

Good point, I like the first option because it is safe that a caller of
crash_kexec() checks it. That is not a strong opinion ;-)


Thanks
Ken'ichi Ohmichi


From seto.hidetoshi at jp.fujitsu.com  Fri Jul 10 03:52:35 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Fri, 10 Jul 2009 16:52:35 +0900
Subject: [PATCH] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A56E83B.50600@mxs.nes.nec.co.jp>
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
	<4A56E069.5040907@jp.fujitsu.com>
	<4A56E83B.50600@mxs.nes.nec.co.jp>
Message-ID: <4A56F343.7040907@jp.fujitsu.com>

Hi Ohmichi-san,

Ken'ichi Ohmichi wrote:
> Hidetoshi Seto wrote:
>> I'd like to quote your comment:
>>
>>>> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
>>>> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
>>>> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
>>>> been changed to a NULL pointer error instead of calling crash_kexec()
>>>> since linux-2.6.31-rc1.
>> So the real problem is that kdump is not triggered by the NULL pointer oops
>> if !panic_on_oops, isn't it?
>>
>> It seems that you should report this trouble of sysrq-c as a regression.
> 
> I don't think this problem is a regression of sysrq-c.
> This change of sysrq-c looks reasonable to me. Because sysrq-c is used
> for the test of kdump, and its code path has been changed to the same
> path as a kdump on oops (a real problem, not test).
> So we can test a kdump by a real oops, that is good to me.
> As a result, I could find this problem a kdump is not enabled without
> "oops=panic".

Still I believe this is a regression of sysrq-c.
If required function of sysrq-c were "cause a real oops", then it is not
regression.  But as described in Documentation/sysrq.txt, real usage of
sysrq-c is "perform a kexec reboot," i.e. kdump.
So I think sysrq-c should use panic instead of oops if it want to kick
the kdump unconditionally.

However, yes, I agree it is a problem on the kdump's policy that kdump on
oops is not enabled without the option.  I'm not sure how much people want
to enable kdump only on panic while not on oops, but I suppose it will be
negligible.  Or it would be better to introduce kdump_on_oops option or so.


Thanks,
H.Seto



From bijouterie at columbius.com  Fri Jul 10 17:37:17 2009
From: bijouterie at columbius.com (bijouterie)
Date: Fri, 10 Jul 2009 22:37:17 +0100
Subject: nitrations
Message-ID: <20090710222758.4182514feckly@columbius.com>

Best Orgsam Positions - 2 Posiitions That guarantee Explosive Orgasms www.ma29. net. Candidate touts sex witth Pakcers in campaign


From superload at kelway.com  Sun Jul 12 08:04:03 2009
From: superload at kelway.com (Hollmann)
Date: Sun, 12 Jul 2009 12:04:03 -0000
Subject: saxifrage
Message-ID: <227E0B2D7000025735CAC44069214D057B506D@kelway.com>

oHow to Make sex Exciting Again.www_ze44_com


From oda at valinux.co.jp  Mon Jul 13 00:01:41 2009
From: oda at valinux.co.jp (Itsuro ODA)
Date: Mon, 13 Jul 2009 13:01:41 +0900
Subject: [PATCH] fix missing Crash note in /proc/iomem
Message-ID: <20090713112628.9F01.277DD91C@valinux.co.jp>

Hi,

Missing "Crash note" in /proc/iomem (dom 0) happens on the Xen 3.4.*.
This causes a crash dump cannot be analyzed normally.

This patch fixes this problem.
This patch is for linux-2.6.18-xen.hg.

The range of "Crash note" is within the "Hypervisor code and data" 
on the Xen 3.3.* and before. The code assumed this.
It is not true for the Xen 3.4.

== example: before patch: one of two "Crash note" is missing
# cat /proc/iomem 
...
00100000-c779ffff : System RAM
  02000000-09ffffff : Crash kernel
  c7300000-c74aa35f : Hypervisor code and data
    c7456080-c7456213 : Crash note
c77a0000-c77adfff : ACPI Tables
...

== example: after patch: two "Crash note" are showed normally
# cat /proc/iomem 
...
00100000-c779ffff : System RAM
  02000000-09ffffff : Crash kernel
  c7300000-c74aa35f : Hypervisor code and data
    c7456080-c7456213 : Crash note
  c7791c00-c7791df3 : Crash note
c77a0000-c77adfff : ACPI Tables
...

This problem is occured on the x86_64 only. This patch has no bad effect for
other architectures and is backword compatible.

Please apply this patch to the newer dom-0 kernel too.

Thanks.
Itsuro Oda

---
Signed-off-by: Itsuro Oda <oda at valinux.co.jp>

diff -r b086278a4406 drivers/xen/core/machine_kexec.c
--- a/drivers/xen/core/machine_kexec.c	Mon Jun 29 10:57:46 2009 +0100
+++ b/drivers/xen/core/machine_kexec.c	Fri Jul 10 16:57:34 2009 +0900
@@ -144,7 +144,15 @@ void __init xen_machine_kexec_setup_reso
 
 void __init xen_machine_kexec_register_resources(struct resource *res)
 {
+	int k;
+	struct resource *r;
+
 	request_resource(res, &xen_hypervisor_res);
+	for (k = 0; k < xen_max_nr_phys_cpus; k++) {
+		r = xen_phys_cpus + k;
+		if (r->parent == NULL) /* out of xen_hypervisor_res range */
+			request_resource(res, r);
+	} 
 	machine_kexec_register_resources(res);
 }

-- 
Itsuro ODA <oda at valinux.co.jp>



From oomichi at mxs.nes.nec.co.jp  Mon Jul 13 00:33:07 2009
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Mon, 13 Jul 2009 13:33:07 +0900
Subject: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A56E069.5040907@jp.fujitsu.com>
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
	<4A56E069.5040907@jp.fujitsu.com>
Message-ID: <4A5AB903.6090204@mxs.nes.nec.co.jp>


Hi,

This patch is a new version by Seto-san's comment.


Changelog since v1:
* Remove the check code other than kexec_crash_image from kexec_should_crash()
  because a kexec cannot crash if there is no image.


This patch enables a kdump if 2nd-kernel is loaded.
(The patch is based on linux-2.6.31-rc2.)

Now, a kdump on oops is enabled if a kernel parameter "oops=panic"
is specified and 2nd-kernel is loaded. I think that a kdump should
be enabled regardless of "oops=panic" if 2nd-kernel is loaded,
because a system administrator loads 2nd-kernel for enabling a kdump.


* Reference
  The discussion about this patch
  http://lists.infradead.org/pipermail/kexec/2009-July/003417.html
  http://lists.infradead.org/pipermail/kexec/2009-July/003433.html


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
Acked-by: Simon Horman <horms at verge.net.au>
---
--- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
+++ b/kernel/kexec.c	2009-07-13 13:49:03.000000000 +0900
@@ -57,7 +57,7 @@ struct resource crashk_res = {
 
 int kexec_should_crash(struct task_struct *p)
 {
-	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
+	if (kexec_crash_image)
 		return 1;
 	return 0;
 }


From seto.hidetoshi at jp.fujitsu.com  Mon Jul 13 03:48:55 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Mon, 13 Jul 2009 16:48:55 +0900
Subject: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A5AB903.6090204@mxs.nes.nec.co.jp>
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
	<4A56E069.5040907@jp.fujitsu.com>
	<4A5AB903.6090204@mxs.nes.nec.co.jp>
Message-ID: <4A5AE6E7.2000208@jp.fujitsu.com>

Ken'ichi Ohmichi wrote:
> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> Acked-by: Simon Horman <horms at verge.net.au>
> ---
> --- a/kernel/kexec.c	2009-07-08 12:30:26.000000000 +0900
> +++ b/kernel/kexec.c	2009-07-13 13:49:03.000000000 +0900
> @@ -57,7 +57,7 @@ struct resource crashk_res = {
>  
>  int kexec_should_crash(struct task_struct *p)
>  {
> -	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> +	if (kexec_crash_image)
>  		return 1;
>  	return 0;
>  }

Reviewed-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>

Thanks,
H.Seto



From ebiederm at xmission.com  Mon Jul 13 13:06:25 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Mon, 13 Jul 2009 10:06:25 -0700
Subject: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <4A5AB903.6090204@mxs.nes.nec.co.jp> (Ken'ichi Ohmichi's message
	of "Mon\, 13 Jul 2009 13\:33\:07 +0900")
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>
	<4A56E069.5040907@jp.fujitsu.com> <4A5AB903.6090204@mxs.nes.nec.co.jp>
Message-ID: <m14otga4xa.fsf@fess.ebiederm.org>

"Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp> writes:

> Hi,
>
> This patch is a new version by Seto-san's comment.
>
>
> Changelog since v1:
> * Remove the check code other than kexec_crash_image from kexec_should_crash()
>   because a kexec cannot crash if there is no image.
>
>
> This patch enables a kdump if 2nd-kernel is loaded.
> (The patch is based on linux-2.6.31-rc2.)
>
> Now, a kdump on oops is enabled if a kernel parameter "oops=panic"
> is specified and 2nd-kernel is loaded. I think that a kdump should
> be enabled regardless of "oops=panic" if 2nd-kernel is loaded,
> because a system administrator loads 2nd-kernel for enabling a kdump.

The Documentation for sysrq-c certainly needs to be updated.

If I am doing development on a system I like oops's.  All of the
information and nothing goes down.  I can get at /proc/kcore etc.

In a setting where I can't be Johnny on the spot and look at
things a core dump is probably the best I can get.  In that scenario
panic_on_oops sounds good.

As I read the current check it reads:
If we are going to panic and not oops || panic_on_oops
	kexec_should_crash = true;

Which seems a very reasonable implementation of policy.

Eric


From seto.hidetoshi at jp.fujitsu.com  Mon Jul 13 22:04:37 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Tue, 14 Jul 2009 11:04:37 +0900
Subject: [PATCH-v2] kdump: Enable kdump if 2nd-kernel is loaded.
In-Reply-To: <m14otga4xa.fsf@fess.ebiederm.org>
References: <4A55A4AE.3000206@mxs.nes.nec.co.jp>	<4A56E069.5040907@jp.fujitsu.com>
	<4A5AB903.6090204@mxs.nes.nec.co.jp>
	<m14otga4xa.fsf@fess.ebiederm.org>
Message-ID: <4A5BE7B5.7080500@jp.fujitsu.com>

Eric W. Biederman wrote:
> The Documentation for sysrq-c certainly needs to be updated.

No doubt about it.

> If I am doing development on a system I like oops's.  All of the
> information and nothing goes down.  I can get at /proc/kcore etc.
> 
> In a setting where I can't be Johnny on the spot and look at
> things a core dump is probably the best I can get.  In that scenario
> panic_on_oops sounds good.
> 
> As I read the current check it reads:
> If we are going to panic and not oops || panic_on_oops
> 	kexec_should_crash = true;
> 
> Which seems a very reasonable implementation of policy.

If I understand it,

a) panic
b) oops
c) SysRq (from keyboard interrupt)
d) echo c > /proc/sysrq-trigger

   a      b      c      d
common, w/o CONFIG_KEXEC:
 panic  oops   panic   oops  :
 panic  panic  panic   panic : w/ panic_on_oops

A) 2.6.30 + CONFIG_KEXEC:
 panic  oops   -       -     : w/o kdump-image
 panic  panic  -       -     : w/o kdump-image w/ panic_on_oops
 kdump  oops   kdump   kdump : w/ kdump-image
 kdump  kdump  kdump   kdump : w/ kdump-image w/ panic_on_oops

B) 2.6.31-rc1 + CONFIG_KEXEC:
 panic  oops   panic   oops  : w/o kdump-image
 panic  panic  panic   panic : w/o kdump-image w/ panic_on_oops
 kdump  oops   kdump   oops  : w/ kdump-image
 kdump  kdump  kdump   kdump : w/ kdump-image w/ panic_on_oops

C) After this patch + CONFIG_KEXEC:
 panic  oops   panic   oops  : w/o kdump-image
 panic  panic  panic   panic : w/o kdump-image w/ panic_on_oops
 kdump  kdump  kdump   kdump : w/ kdump-image
 kdump  kdump  kdump   kdump : w/ kdump-image w/ panic_on_oops

Ohmichi-san pointed "oops on d) with kdump-image" in B) and suggested
it should be "kdump."
And Eric pointed "kdump on b) without panic_on_oops" in C) and requested
it should be "oops."
(Plus, IMHO, "oops on d) without panic_on_oops" should be "panic.") 

... Right?

Then as I mentioned, use panic in sysrq would be one of solutions.
Are there any better fix?


Thanks,
H.Seto



From seto.hidetoshi at jp.fujitsu.com  Mon Jul 13 23:18:58 2009
From: seto.hidetoshi at jp.fujitsu.com (Hidetoshi Seto)
Date: Tue, 14 Jul 2009 12:18:58 +0900
Subject: [PATCH] kexec: Fix omitting offset in extended crashkernel syntax
Message-ID: <4A5BF922.2000503@jp.fujitsu.com>

Setting
 "crashkernel=512M-2G:64M,2G-:128M"
does not work but it turns to work if it has a trailing-whitespace,
like
 "crashkernel=512M-2G:64M,2G-:128M ".

It was because of a bug in the parser, running over the cmdline.

This patch adds a check of the termination.

Reported-by: Jin Dongming <jin.dongming at np.css.fujitsu.com>
Signed-off-by: Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com>
Tested-by: Jin Dongming <jin.dongming at np.css.fujitsu.com>
---
 kernel/kexec.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index ae1c352..f336e21 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1228,7 +1228,7 @@ static int __init parse_crashkernel_mem(char 			*cmdline,
 	} while (*cur++ == ',');
 
 	if (*crash_size > 0) {
-		while (*cur != ' ' && *cur != '@')
+		while (*cur && *cur != ' ' && *cur != '@')
 			cur++;
 		if (*cur == '@') {
 			cur++;
-- 
1.6.0



From bill at bfccomputing.com  Wed Jul 15 18:23:07 2009
From: bill at bfccomputing.com (Bill McGonigle)
Date: Wed, 15 Jul 2009 18:23:07 -0400
Subject: persisting a ramdisk
Message-ID: <4A5E56CB.4030109@bfccomputing.com>

Hi, all,

This is my first post to the list and I'm new to kexec.

I'm wondering if it's possible to persist a ramdisk across a kexec
'reboot'.  In the normal reboot case, this isn't possible as the BIOS
may do who-knows-what to memory, but if I understand correctly, this
isn't a problem in the kexec case.

I'd imagine there would have to be a certain memory marker or a kernel
command line option so that the new kernel could find the ramdisk.  I
figured this might exist already, but I probably don't know enough to
find what I'm looking for.

The use case here is booting from a LiveCD, fetching a more-current
kernel and tools off the Internet, and then booting into it.  I'm not
really sure if having the kernel on the ramdisk makes it harder or not
(it would still be worthwhile for non-kernel data).  Some of the kboot
docs make me think it could be possible, but I don't understand the
hand-off mechanism for resources handled by the previous kernel.

If anybody knows if this is doable please point me in the right
direction, or to docs I ought to be reading to better understand the
mechanics.

Thanks,
-Bill

-- 
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
http://www.bfccomputing.com/    Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle   Page: 603.442.1833
Email, IM, VOIP: bill at bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf


From deceit at lcnrnurse.com  Fri Jul 17 06:05:02 2009
From: deceit at lcnrnurse.com (Goodwin Braud)
Date: Fri, 17 Jul 2009 10:05:02 -0000
Subject: coddling
Message-ID: <1247824981_slivers@lcnrnurse.com>

A Little Love Tgale About Magic Ltove At First Sight, sex Position Drawings, Non-porn.www[dot]pill22[dot]com


From d222d1 at msn.com  Fri Jul 17 18:53:07 2009
From: d222d1 at msn.com (Mr.Morris Brown)
Date: Sat, 18 Jul 2009 04:23:07 +0530 (IST)
Subject: =?UTF-8?Q?PHISING_Mr=2E_Morris_Brown=2C=28Audit_Manager=29?=
Message-ID: <smtp_4A61361F_3850_0002.eml@144.16.192.220>




-- 
Greetings,

Before I start, I must firstly apologize for this unsolicited proposal to
you. I am aware that this is certainly an unconventional approach to
starting a relationship, But as time goes on you will realize the need for
my action.

 my name is Mr. Morris Brown, Audit Manager of Alpha Bank and account
officer to Late Edward Han, who died with his wife and the only daughter
in an Automobile crash on the 28th January 2001. Before the death of Late
Edward Han, he maintained a fixed deposit account with my Bank (Alpha
Bank UK Ltd) Based on this discovery, I now seek your permission and
support to have you stand in as a next of kin to the Late deceased, as
all documentations will be carefully worked out by me for the release of
these funds, all amounting to the tune of (?20,000,000.00 GB) Twenty
Million British Pounds Sterling Only to any nominated account of your
choice.

 I propose an offer of 40% of the total amount to be yours after the
transfer has been successfully concluded. Let me have your Full Name,
Confidential Telephone, Fax and Mobile Numbers and also your Contact
Address in response to this proposal if you are interested. Please reply
immediately to my private email address:mr.morris_brown at yahoo.com

Thanks and God bless.Sincerely Yours,

  Mr. Morris Brown.
Tel: +44 7045776428


 ?  The attached email has been scanned by CA Gateway Security and has been identified as containing inappropriate content.     Company Spam prevention policy is to identify the message as a potential Spam item and to attach the message to this email.    Content Scanning Information:
Message identified as Phishing by: Phishing score=35, based on Sender Spammy Reputation (M),Generic spam indicator (M), SPF Validation -- Soft Fail


From plush at church-hill.net  Tue Jul 21 19:38:12 2009
From: plush at church-hill.net (Sartell)
Date: Tue, 21 Jul 2009 22:38:12 -0100
Subject: jarrah
Message-ID: <NepgLAJABeDgPut@church-hill.net>

Naughty Tips to Make Her Orgasm -- Keep Her Totally Satisfied Every Single Timme!.www.nu26 .com


From horms at verge.net.au  Tue Jul 21 22:24:34 2009
From: horms at verge.net.au (Simon Horman)
Date: Wed, 22 Jul 2009 12:24:34 +1000
Subject: [ANNOUNCE] kexec-tools 2.0.1-rc1
Message-ID: <20090722022434.GA4980@verge.net.au>

Hi all,

Its been a while since the last release, and there seem
to be enough changes to warrant one, so here goes 2.0.1-rc1.

I'm not aware of any major issues that would prevent this from
becoming 2.0.1. If you know of any, please respond so the
appropriate changes can be included. Testing is, as always,
very welcome.

The release can be downloaded from kernel.org:

http://ftp.kernel.org/pub/linux/kernel/people/horms/kexec-tools/testing/kexec-tools-2.0.1-rc1.tar.gz
http://ftp.kernel.org/pub/linux/kernel/people/horms/kexec-tools/testing/

I have also tagged it in git:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git
http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools.git


A summary of the changes since the previous release,
kexec-tools 2.0.0, is below.

commit 5273e798b25d78ed4e3f51879e8fb2093faa7422
Author: Simon Horman <horms at verge.net.au>
Date:   Wed Jul 22 12:09:50 2009 +1000

    kexec-tools 2.0.1-rc1
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 3444dce25ba125ae6d9522bbd297f78cb31211fb
Author: Simon Horman <horms at verge.net.au>
Date:   Wed Jul 22 12:09:13 2009 +1000

    Include kexec/arch/cris/kexec-cris.h in distribution tarball
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 346ed7a0c89e48f4bffceca8b4c4f50cc4932fc6
Author: Simon Horman <horms at verge.net.au>
Date:   Wed Jul 22 12:08:21 2009 +1000

    Include kexec/arch/sh/crashdump-sh.h in distribution tarball
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 24e8417fff62b3f3d4fbee52d0dd383ba50178a5
Author: Geoff Levand <geoffrey.levand at am.sony.com>
Date:   Mon Jun 22 15:08:49 2009 -0700

    kexec: Fix printed symbol value
    
    Move the print statement so that the variable
    value has been assigned before its value is
    printed.
    
    Signed-off-by: Geoff Levand <geoffrey.levand at am.sony.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 7ca0270ab3e2f1abcc520f59c6795f1b873bddcd
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Mar 18 20:22:51 2009 +0900

    sh: use physical address for zImage entry
    
    Use a physical address for the SuperH zImage entry point.
    This makes the zImage loader behave as the elf loader.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 09e2b3a3f9f6477875da1bfacdcf1f1bb1b4486a
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Mar 18 15:07:46 2009 +0900

    kexec jump: SuperH vmlinux support
    
    Create elf header and modify the kernel command line
    when loading a crash kernel or a kexec jump kernel.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 0cd674d83b07bd5fd1bbd09d40bea2825e44d3d1
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Mar 18 15:07:01 2009 +0900

    kexec jump: use add_segment_phys_virt()
    
    Since /proc/iomem contains physical addresses, use
    add_segment_phys_virt(xxx, 0) instead of add_segment()
    in add_backup_segments().
    
    This fix is needed for kexec jump on SuperH where
    add_segment() only takes virtual addresses.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 958704f7e56f5eefef2d6e13975258400d3fdbfd
Author: Bernhard Walle <bernhard.walle at gmx.de>
Date:   Mon Feb 9 23:53:53 2009 +0100

    Correct email addresses
    
    Since I don't work for SUSE any more and 'bwalle at suse.de' is invalid, correct
    it in the copyright so that people can still contact me.
    
    Signed-off-by: Bernhard Walle <bernhard.walle at gmx.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit ad28e87b60062cfcd423fcdecce56d651c38cc1e
Author: Chandru <chandru at in.ibm.com>
Date:   Wed Feb 4 22:02:03 2009 +0530

    x86_64 : exclude gart memory region in kexec tools
    
    The following patch was discussed sometime back on kexec-tools mailing list.
    http://lists.infradead.org/pipermail/kexec/2008-December/003096.html
    Sending it here again for inclusion into kexec-tools. thanks
    ====================================
    
    Exclude GART memory region and make kexec-tools to not create elf headers to
    it.  Currently it seems like the dump analysis tools do not need a copy of the
    GART memory region, hence ignoring it in kexec-tools. Symtoms of accessing
    this region in kdump kernel included hangs, spurious restarts, and MCE
    (Machine Check Exception) panics in some AMD Opteron systems
    
    Signed-off-by: Chandru S <chandru at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 0f15c4319a6f26d55ad0ddb58c1c43068091c570
Author: Chandru <chandru at in.ibm.com>
Date:   Fri Feb 6 12:07:17 2009 +0530

    powerpc: initialize drconf variables
    
    The initialization of lmb_size and num_of_lmbs got removed as part of the
    'kexec memory ranges dynamic allocation' patch to kexec-tools (which added
    realloc_memory_ranges() code to kexec-tools). These variables are pertinent
    to ppc64 systems with ibm,dynamic-reconfiguration-memory node in device-tree,
    i.e systems with /proc/device-tree/ibm,dynamic-reconfiguration-memory. The
    following patch adds code to initialize the variables back again in kexec-tools.
    Without this patch kexec-tools will think that it needs to save only the memory
    represented in memory@ nodes and will skip the memory in
    /proc/device-tree/ibm,dynamic-reconfiguration-memory node of the device-tree.
    
    Signed-off-by: Chandru S <chandru at linux.vnet.ibm.com>
    Reviewed-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 988a8a9c29230233abf7772bc3dce00603f3011a
Author: Bernhard Walle <bwalle at suse.de>
Date:   Fri Jan 16 19:11:45 2009 +0100

    printf() consolidation
    
    Remove the fprintf(stderr,...) in get_memory_ranges() that adds unnecessary
    output in the normal kexec case that the user don't want to see.
    
    Use dbgprintf() in get_base_ranges() instead of
    
        #ifdef DEBUG
            fprintf(stderr,...)
        #endif
    
    to to make the code more readable.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
    index ad8a31c..8d4e42b 100644
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 95c74405638c786bc76fbca5e4e8427dfe26e907
Author: Bernhard Walle <bwalle at suse.de>
Date:   Fri Jan 16 19:11:34 2009 +0100

    Fix memory corruption when using realloc_memory_ranges()
    
    Because realloc_memory_ranges() makes the old memory invalid, and we return
    a pointer to memory_range in get_memory_ranges(), we need to copy the contents
    in get_memory_ranges().
    
    Some code that calls realloc_memory_ranges() may be triggered by
    get_base_ranges() which is called after get_memory_ranges().
    
    Yes, the memory needs to be deleted somewhere, but I don't know currently
    where it's the best, and since it's not in a loop and memory is deleted
    anyway after program termination I don't want to introduce unneccessary
    complexity. The problem is that get_base_ranges() gets called from
    architecture independent code and that allocation is PPC64-specific here.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
    index b0d8acd..ad8a31c 100644
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 8afb534bf7c538eb3f57595054056289cda97b88
Author: Bernhard Walle <bwalle at suse.de>
Date:   Fri Jan 16 19:11:23 2009 +0100

    Fix typo in realloc_memory_ranges()
    
    The base_memory_range should not become memory_range. We need to realloc
    base_memory_range to not change the contents of memory. That was a copy & paste
    error.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 6d4cdf4f94bf7ad2d1752b553ea948385881ff79
Author: Bernhard Walle <bwalle at suse.de>
Date:   Fri Jan 16 15:06:48 2009 +0100

    Fix missing FILE argument in fprintf()
    
    This fixes the following compiler warning
    
        kexec/arch/i386/crashdump-x86.c: In function 'get_crash_memory_ranges':
        kexec/arch/i386/crashdump-x86.c:144: warning: passing argument 1 of \
            'fprintf' from incompatible pointer type
        kexec/arch/i386/crashdump-x86.c:144: warning: passing argument 2 of \
            'fprintf' makes pointer from integer without a cast
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16
Author: Milton Miller <miltonm at bga.com>
Date:   Fri Jan 2 15:04:48 2009 -0600

    ppc64: cleanups
    
    don't copy purgatory, as elf-load-rel does that for us (like x86_64).
    
    move function declarations from c to h files
    
    remove casts between void  * and various pointers
    
    change some pointers between char and unsigned char *
    
    change args to be vars of the right type instead of casting or
    copying between types
    
    Signed-off-by: Milton Miller <miltonm at bga.com>
    Tested-by: M. Mohan Kumar <mohan at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 969203ab173765b775e617391a2605c073f63410
Author: Milton Miller <miltonm at bga.com>
Date:   Fri Jan 2 15:04:51 2009 -0600

    entry wants to be void *
    
    The kexec info struct defines entry to be a void *, so pass around the
    user supplied value as one.
    
    This fixes the following warning:
    
    gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/arch/ppc64/include  -c -MD -o kexec/kexec.o kexec/kexec.c
    kexec/kexec.c: In function ?my_load?:
    kexec/kexec.c:773: warning: assignment makes pointer from integer without a cast
    
    Signed-off-by: Milton Miller <miltonm at bga.com>
    Tested-by: M. Mohan Kumar <mohan at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 4fcb65c9089c2c9d203402d549c4e11e44021542
Author: Milton Miller <miltonm at bga.com>
Date:   Fri Jan 2 15:04:45 2009 -0600

    ppc64: segments may be reordered
    
    Instead of fetching data from the segment array, remember the address
    when added and find the kernel text from the parsed elf header.
    
    While add_segment (and hence add_buffer) always adds to the end of
    the list of segments, it sorts the previous segments before each
    allocation.  In some layouts, the device tree or initrd will fit
    in a hole below the the kernel.   When that happens, the previus
    code mis-patches purgatory and the kexec fails.
    
    Signed-off-by: Milton Miller <miltonm at bga.com>
    Tested-by: M. Mohan Kumar <mohan at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 79c650e757561b03163da73dfc367f702248ef98
Author: Milton Miller <miltonm at bga.com>
Date:   Fri Jan 2 15:04:42 2009 -0600

    ppc64: update kdump for 2.6.28 relocatable kernel
    
    The kernel updated its ABI to tell the relocatable kernel to run
    where it was loaded.
    
    We now need to set a flag in the kernel image.  Since we only have
    the kernel image avialable as const data to kexec-tools c code, set
    the flag in the copy we put in purgatory, and have it set the flag
    in the kernel (after purgatory has run its checksum).  To simplfy
    the purgatory code we can always copy the flag word back to the
    kernel as the c code made a copy of the original flag value.
    
    Signed-off-by: Milton Miller <miltonm at bga.com>
    Tested-by: M. Mohan Kumar <mohan at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit e8f2de09b52c3f4e23f907a6f6bf837b1f45af50
Author: Milton Miller <miltonm at bga.com>
Date:   Thu Jan 8 06:33:50 2009 -0600

    ppc64: always check number of ranges when adding them
    
    make the idom "always call realloc_memory_ranges when filling a range entry"
    
    kexec was core dumping after using 5 exclude_range pairs when only 3
    were allocated.
    
    also delcare realloc_memory_ranges to take void.
    
    Signed-off-by: Milton Miller <miltonm at bga.com>
    Tested-by: M. Mohan Kumar <mohan at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 14f69fc20bec03f7db1c4f4c0e45d9e73400e9a5
Author: Simon Horman <horms at verge.net.au>
Date:   Tue Nov 4 09:26:02 2008 +1100

    Make x86_setup_jump_back_entry() static with a void argument list
    
    gcc complains because x86_setup_jump_back_entry() has no arguments,
    making the argument list void resolves this.
    
    Also, make the function static as it isn't used in any other files.
    And move the function above where it is used, to eliminate the
    need for a forward-declaration.
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit df0878e64e92d403c4e2e5604cd81d6d1baff169
Author: Bernhard Walle <bwalle at suse.de>
Date:   Wed Nov 26 10:00:52 2008 +0100

    Fix compile warnings in get_memory_ranges()
    
    This patch fixes:
    
            kexec/arch/i386/kexec-x86-common.c: In function ?get_memory_ranges?:
            kexec/arch/i386/kexec-x86-common.c:189: \
                    warning: passing argument 2 of ?parse_iomem_single? from incompatible pointer type
            kexec/arch/i386/kexec-x86-common.c:189: \
                    warning: passing argument 3 of ?parse_iomem_single? from incompatible pointer type
    
    Yes, that was my own code. :-(
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 73a97629eab98f06b2b1a707e9b310d5fd9f9520
Author: Bernhard Walle <bwalle at suse.de>
Date:   Wed Nov 26 10:00:39 2008 +0100

    Don't use /sys/firmware/memmap for Xen
    
    On Xen, we have to use /proc/iomem to retrieve the memory area for the kexec'd
    kernel, not /sys/firmware/memmap. Dom0 kernel gets a E820 map that contains
    only one region:
    
        0000000000000000-0000000018e5e000 (System RAM)
    
    Compared to the /proc/iomem:
    
        00000000-0009cbff : System RAM
        0009cc00-0009ffff : reserved
        000ce000-000d3fff : reserved
        000e0000-000fffff : reserved
        00100000-1fd6ffff : System RAM
          01000000-04ffffff : Crash kernel
          1ec00000-1fbfffff : Hypervisor code and data
            1f0b4680-1f0b4873 : Crash note
            1f0b4900-1f0b4a93 : Crash note
            1f0b4b80-1f0b4d13 : Crash note
            1f0b4e00-1f0b4f93 : Crash note
        ...
    
    Without that patch, /proc/vmcore is empty in the kexec'd kernel and I'm unable
    to copy the crashdump.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit fcd049da6ac36183e2dc69bd1f479d059e8dd9a7
Author: Huang Ying <ying.huang at intel.com>
Date:   Wed Nov 26 14:47:38 2008 +0800

    Fix kexec x86_64 load failed bug
    
    Fix a bug of kexec load on x86_64. Kexec fails to do load on x86_64, with
    error message:
    
      Symbol: cmdline_end not found cannot set
    
    Because kexec/arch/i386/kexec-bzImage.c accesses cmdline_end symbol in
    i386 purgatory, but there is no cmdline_end in x86_64 purgatory, and
    kexec-bzImage.c is used by x86_64 too.
    
    cmdline_end is added into x86_64 purgatory to solve the bug, because kexec
    jump support for x86_64 is planned.
    
    Reported-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Huang Ying <ying.huang at intel.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 9bf8dee9bab15d7f6de8a4cd332e77a1559083e3
Author: Bernhard Walle <bwalle at suse.de>
Date:   Fri Nov 14 10:48:04 2008 +0100

    Fix spell error in help output
    
    This patch just fixes a spell error. Found by Dave Plater.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 186a545ec38c028cadb948310dac4faba4589fd0
Author: Stefan Assmann <sassmann at suse.de>
Date:   Wed Nov 5 10:41:49 2008 +0100

    Add include for offsetof macro
    
    kexec/arch/i386/kexec-elf-x86.c and kexec/arch/x86_64/kexec-elf-x86_64.c
    both use the macro offsetof() which according to the man page requires
    #include <stddef.h>.
    The include is not present at the moment and this patch adds it. This is
    necessary for compatibility with i.e. uClibc.
    
    Signed-off-by: Stefan Assmann <sassmann at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit d182ce5434c7b66569118db0ccfe63e5d8a03687
Author: Maxim Uvarov <muvarov at gmail.com>
Date:   Wed Oct 15 12:46:24 2008 +0400

    ppc64: kexec memory ranges dynamic allocation
    
    Do not count  max_memory_range for allocation. Increase allocation buffers
    when it is needed. This actually allows us to avoid a lot of troubles with
    various device-tree files.
    
    Signed-off-by: Maxim Uvarov <muvarov at gmail.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 2b6a50a16a3de9716c8a34af43b8286e5b58b1f2
Author: Huang Ying <ying.huang at intel.com>
Date:   Wed Oct 29 11:24:30 2008 +0800

    core dump file support for ELF loader
    
    This patch adds core dump file support to ELF file loader. This can be
    used by kexec based hibernation to load hibernated image, which is
    from /proc/vmcore, a core dump file.
    
    Signed-off-by: Huang Ying <ying.huang at intel.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit ceb04ae1223ba5cdd40df744aa73a32b2cc7d879
Author: Huang Ying <ying.huang at intel.com>
Date:   Wed Oct 29 11:24:25 2008 +0800

    kexec jump support for kexec-tools
    
    To support memory backup/restore an option named
    --load-preserve-context is added to kexec. When it is specified
    toggether with --mem-max, most segments for crash dump support are
    loaded, and the memory range between mem_min to mem_max which has no
    segments loaded are loaded as backup segments. To support jump back
    from kexeced, options named --load-jump-back-helper and --entry are
    added to load a helper image with specified entry to jump back.
    
    Signed-off-by: Huang Ying <ying.huang at intel.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 802a8a5e396e06a514251c44454c982bff3c5073
Author: Chandru <chandru at in.ibm.com>
Date:   Fri Oct 17 23:25:54 2008 +0530

    kdump: check flags field from drconf memory
    
    On a powerpc machine when memory is dynamically removed/added from an lpar, the
    corresponding flags field in the drconf memory reflects the same with the bits
    unset/set accordingly. The kernel does a check on these flags while booting.
    Following are the similar changes brought in to kexec-tools.  This makes
    kexec-tools to skip those memory regions that do not belong or are not
    assigned to the current partition ( but are available to dynamically add them
    back ). Without this patch (and with memory remove operation) copying vmcore
    fails with error as
    
    Copying data                       : [ 84 %] readmem: Can't read the dump
    memory(/proc/vmcore). Bad address
    read_pfn: Can't get the page data.
    
    Signed-off-by : Chandru S <chandru at in.ibm.com>
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 39dd40d3e83acbe8ef2f1465e02e8d3e26e6a21d
Author: Jay Lan <jlan at sgi.com>
Date:   Fri Sep 19 19:17:05 2008 -0700

    IA64: better calculate PT_LOAD segment size
    
    This patch combines consecutive PL_LOAD segments into one.
    The end address of the last PL_LOAD segment, calculated by
    adding p_memsz to p_paddr & rounded up to ELF_PAGE_SIZE,
    will be the end address of this loaded_segments[] entry.
    
    This patch fixes the kdump kernel MCA problem caused by under-
    allocation of memory and a "kdump broken on ALtix 350" problem
    reported by Bernhard Walle.
    
    Simon, this patch replaces my previous patch I submitted on the
    underallocation issue.
    
    Signed-off-by: Jay Lan <jlan at sgi.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit a96b5c237919e6761260efa83cc6f9d455c25ac1
Author: Simon Horman <horms at verge.net.au>
Date:   Fri Oct 10 09:30:53 2008 +1100

    Fix declaration of get_dyn_reconf_crash_memory_ranges()
    
    powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.1
    Copyright (C) 2006 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    kexec/arch/ppc64/crashdump-ppc64.c:125: warning: function declaration isn't a prototype
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 84aa7cf2468c2921d61d4cb97c1df670a470ea8b
Author: Bernhard Walle <bwalle at suse.de>
Date:   Thu Oct 9 19:01:25 2008 +0200

    Use return value of count_dyn_reconf_memory_ranges()
    
    This patch fixes the build error
    
        kexec/arch/ppc64/kexec-ppc64.c:140: \
            warning: control reaches end of non-void function
    
    The patch returns 0 on success, and checks when the function is called
    for a non-zero value.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 1d19ca0c4306c3c684cf4d277781975e4ad1c193
Author: Chandru <chandru at in.ibm.com>
Date:   Wed Sep 24 17:19:29 2008 +0530

    kexec/kdump : get details of ibm, dynamic-reconfiguration-memory node of device tree
    
    Get number of  lmb's (logical memory blocks) , size of each lmb from
    ibm,dynamic-memory property , get base memory ranges from
    ibm,dynamic-reconfiguration-memory node.
    
    Signed-off-by: Chandru Siddalingappa <chandru at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit cd8497a9a9e487684679b6747f7ba3f0a557328b
Author: Chandru <chandru at in.ibm.com>
Date:   Wed Sep 24 17:19:18 2008 +0530

    kexec/kdump : add a new linux, usable-drconf-memory node to the device tree
    
    Add a new linux,usable-drconf-memory property to the device tree passed to the
    2nd kernel.  Each entry in the property is of the form: a count followed by so
    many  (base, size) pairs of usable memory regions.  The total number of such
    entries is equal to number of lmb's in ibm,dynamic-memory property.
    
    Signed-off-by: Chandru Siddalingappa <chandru at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 726c130af8b1371aa32dc14f108a3fb1695860bb
Author: Chandru <chandru at in.ibm.com>
Date:   Wed Sep 24 17:19:07 2008 +0530

    kexec/kdump: read crash memory ranges from drconf memory
    
    Get the memory ranges of the 1st kernel excluding the memory reserved for
    kexec/kdump kernel in case of ibm,dynamic-reconfiguration-memory node of
    device tree
    
    Signed-off-by: Chandru Siddalingappa <chandru at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit d9c5b2da1fad4ac9064db4c890e41066f873f6d3
Author: Mohan Kumar M <mohan at in.ibm.com>
Date:   Tue Sep 30 18:26:21 2008 +0530

    Relocatable kdump kernel support in kexec-tools
    
    Relocatable kdump kernel support in kexec-tools
    
    This patch adds relocatable kernel support for kdump in the kexec-tools
    code. A signature (0xfeed1234) is passed in r6 from panic code to the
    purgatory code through kexec_sequence function. The signature is used to
    differentiate between relocatable kdump kernel and non-kdump kernels.
    
    The purgatory code compares the signature and sets the __kdump_flag in
    head_64.S by using the offset with respect to next kernel load address.
    During the boot up, kernel code checks __kdump_flag and if it is set, the
    kernel will behave as relocatable kdump kernel.
    
    Signed-off-by: Mohan Kumar M <mohan at in.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit fc071d2a74ae26d817276e82ab71046e6387cbd1
Author: Simon Horman <horms at verge.net.au>
Date:   Wed Oct 8 15:52:19 2008 +1100

    cris: add cris architecture to configure
    
    # PATH=$PATH:/usr/local/cris/bin/ CC=crisv32-axis-linux-gnu-gcc \
    	./configure --host=crisv32-axis-linux-gnu
    configure: WARNING: If you wanted to set the --build type, don't use --host.
        If a cross compiler is detected then cross compile mode will be used.
    checking build system type... i686-pc-linux-gnu
    checking host system type... cris-axis-linux-gnu
    checking target system type... cris-axis-linux-gnu
    configure: error: unsupported architecture cris
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit b039510932e5b3d9691a5d423c34f7ebb14e5175
Author: Edgar E. Iglesias <edgar.iglesias at axis.com>
Date:   Thu Sep 4 16:08:50 2008 +0200

    cris: Add CRISv32 support
    
    Hello,
    
    I hope this is the correct list to which to send these patches.
    Comments are very welcome.
    
    Thanks,
    Edgar
    
    From: Edgar E. Iglesias <edgar.iglesias at axis.com>
    
    Add a CRISv32 port. Initially only the elf filetype is supported.
    
    Signed-off-by: Edgar E. Iglesias <edgar.iglesias at axis.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 800fe37b7931cb11c47c88bf1fd69aa096d3cebe
Author: Edgar E. Iglesias <edgar.iglesias at axis.com>
Date:   Fri Sep 5 11:25:58 2008 +0200

    cris: add kexc_load syscall
    
    The released toolchain had an old list of syscalls (kexec_load was missing)
    so I had to add a fallback definition:
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit edd13ae1c4965b6f1e8a8e07d8e01d31fef37d55
Author: Simon Horman <horms at verge.net.au>
Date:   Wed Oct 8 15:53:02 2008 +1100

    Only use -fno-zero-initialized-in-bss if it is available
    
    As pointed out by Edgar E. Iglesias, the -fno-zero-initialized-in-bss
    option to gcc is not available in the cris 3.2.1 toolchain.
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 7210dc1f75575412b6c29b004614194b9d3ce956
Author: Simon Horman <horms at verge.net.au>
Date:   Wed Oct 8 17:08:51 2008 +1100

    ia64: use generic put_unaligned()
    
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 4bd67d530f92313fd66bb462d96e3995b8e08af3
Author: Bjorn Helgaas <bjorn.helgaas at hp.com>
Date:   Mon Oct 6 09:24:03 2008 -0600

    ia64: make PA() work for both physical identity-mapped virtual addresses
    
    The EFI Runtime Services Table contains pointers to ia64 function
    descriptors.  On existing, pre-Tiano, firmware, SetVirtualAddressMap()
    converts *all* these pointers from physical to virtual.  On Tiano-based
    firmware, the pointer to the SetVirtualAddressMap() function descriptor
    is not converted, so it remains a physical pointer.
    
    The ia64 kexec purgatory patches the SetVirtualAddressMap() function
    descriptor so that when the new kernel calls SetVirtualAddressMap(), it
    never reaches firmware.  Instead, it calls a dummy function that just
    returns success.
    
    Purgatory runs in physical mode, so it must convert the pointer from the
    RuntimeServicesTable to a physical address.  This patch makes that
    conversion work both for old firmware (where the pointer is an identity-
    mapped virtual address) and new Tiano firmware (where the pointer is a
    physical address).
    
    Without this patch, kexec on Tiano firmware causes an MCA because
    ia64_env_setup() subtracts PAGE_OFFSET from a physical address and ends
    up with an invalid physical address.  Referencing that address causes
    the MCA.
    
    Signed-off-by: Bjorn Helgaas <bjorn.helgaas at hp.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit c466edd86b31a9d34cde3db24b093223108627d2
Author: Jay Lan <jlan at sgi.com>
Date:   Fri Sep 12 13:10:34 2008 -0700

    IA64: do not include uncached memory to vmcore
    
    Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
    is denoted as "System RAM" in /proc/iomem, while memory of attribute
    (EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
    
    The kexec utility then includes uncached memory as part of vmcore.
    The kdump kernel may MCA when it tries to save the vmcore to a disk.
    A normal "cached" access can cause MCAs.
    
    Since kexec assembled memory ranges with memory tagged as "System RAM",
    the uncached memory will be excluded if it is labeled differently.
    
    Simon, since only IA64 will create "Uncached RAM" label, i do not
    make changes to other arch.
    
    Our HP machine in the lab is dead. I am sorry that i can not test
    against other IA64 systems (than SGI's). Feedback is very much
    appreciated.
    
    The corresponding kernel patch is needed to test this kexec patch:
    http://marc.info/?l=linux-ia64&m=122122791230130&w=2
    This patch without the kernel patch will have no effect and do no
    harm.
    
    The kernel patch has been commited as
    "[IA64] kexec fails on systems with blocks of uncached memory".
    
    Signed-off-by: Jay Lan <jlan at sgi.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit b422925d35151caa65471c0f0d774727bde4a347
Author: Geoff Levand <geoffrey.levand at am.sony.com>
Date:   Wed Sep 10 18:40:46 2008 -0700

    Fix ppc64 build warnings
    
    Fix these ppc64 32 bit build warnings:
    
     kexec/arch/ppc64/kexec-zImage-ppc64.c: In function 'zImage_ppc64_load':
     kexec/arch/ppc64/kexec-zImage-ppc64.c:164: warning: cast to pointer from integer of different size
     kexec/arch/ppc64/kexec-elf-ppc64.c: In function 'elf_ppc64_load':
     kexec/arch/ppc64/kexec-elf-ppc64.c:121: warning: integer constant is too large for 'unsigned long' type
     kexec/arch/ppc64/kexec-elf-ppc64.c:237: warning: cast from pointer to integer of different size
     kexec/arch/ppc64/kexec-elf-ppc64.c:276: warning: cast from pointer to integer of different size
     kexec/arch/ppc64/kexec-elf-ppc64.c:283: warning: cast from pointer to integer of different size
     kexec/arch/ppc64/kexec-elf-ppc64.c:287: warning: cast from pointer to integer of different size
     kexec/arch/ppc64/kexec-elf-ppc64.c:341: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'uint64_t'
     kexec/arch/ppc64/kexec-elf-ppc64.c:352: warning: format '%ld' expects type 'long int', but argument 5 has type 'size_t'
     kexec/arch/ppc64/crashdump-ppc64.c:45: warning: integer constant is too large for 'long' type
     kexec/arch/ppc64/crashdump-ppc64.c:46: warning: integer constant is too large for 'long' type
     kexec/arch/ppc64/crashdump-ppc64.c:56: warning: integer constant is too large for 'long' type
     kexec/arch/ppc64/crashdump-ppc64.c:57: warning: integer constant is too large for 'long' type
    
    Tested on PS3 (ppc64) with 32 and 64 bit builds.
    
    Signed-off-by: Geoff Levand <geoffrey.levand at am.sony.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit c1d13f4bd287f48c5fce02c3916b132f618c40fb
Author: Geoff Levand <geoffrey.levand at am.sony.com>
Date:   Wed Sep 10 18:40:42 2008 -0700

    Fix build warnings
    
    Fix these 64 bit build warnings:
    
     kexec/firmware_memmap.c:241: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
     kexec/crashdump-elf.c:160: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'Elf64_Off'
     kexec/crashdump-elf.c:160: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'Elf64_Addr'
     kexec/crashdump-elf.c:160: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'Elf64_Addr'
     kexec/crashdump-elf.c:160: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'Elf64_Xword'
     kexec/crashdump-elf.c:160: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'Elf64_Xword'
    
    Tested on PS3 (ppc64) with 32 and 64 bit builds.
    
    Signed-off-by: Geoff Levand <geoffrey.levand at am.sony.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 011e3d8660ea44b934f6468b70b1411c97a123a8
Author: Paul Mundt <lethal at linux-sh.org>
Date:   Fri Sep 5 11:13:48 2008 +0900

    sh: Add ELF relocation support for R_SH_DIR32/R_SH_REL32 relocs.
    
    Simple handler for the common SHcompact ELF relocations.
    
    Signed-off-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 0723defb5308ac7fce296f8b596bff4df6803f01
Author: Paul Mundt <lethal at linux-sh.org>
Date:   Fri Sep 5 11:13:10 2008 +0900

    kexec/kexec.h: Bring put/get_unaligned() back from the dead.
    
    This re-enables the fairly generic put/get_unaligned() routines in
    kexec.h, while tidying up the variable shadowing clash that results
    when using it in places like machine_apply_elf_rel().
    
    Needed for SH ELF relocations.
    
    IA64 still does its own put_unaligned64(), which should likely also be
    converted over to using put_unaligned() directly.
    
    Signed-off-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit e534a0c9fed2066ed3636a082e67f6fafa779019
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Sep 3 20:38:11 2008 +0900

    sh: Add vmlinux crash dump support
    
    This patch adds SuperH crash dump support. The vmlinux loader is modified
    with crash dump hooks as on other architectures. SuperH does not need any
    backup region, so only the elf header is allocated from the top of the
    reserved memory window. The actual size of the memory window is passed
    to the secondary kernel on the command line using "mem=".
    
    The secondary kernel must be configured to match the reserved memory
    window, change kernel parameters CONFIG_MEMORY_START and CONFIG_MEMORY_SIZE.
    
    Linux-2.6.27 should be usable as primary kernel on SuperH, later kernel
    versions are needed to fully support secondary kernel /proc/vmcore.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit e956e4a66847606e133bcc4b97704aa09441a064
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Sep 3 20:36:42 2008 +0900

    sh: Fix help text spelling
    
    Fix SuperH help text spelling.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 93792363d3455459c7af7c646c0a1d1238c772fb
Author: Maxim Shchetynin <maxim at de.ibm.com>
Date:   Wed Aug 27 10:04:56 2008 +0200

    Let kexec work on IBM QS2x blade servers
    
    Hello,
    
    please have a look at the following patch. This patch allows kexec to work
    on IBM QS2x blades. Would it be possible to apply this patch to a next
    kexec version?
    
    Signed-off-by: Maxim Shchetynin <maxim at de.ibm.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 6eae8c1bc4d43d07c9799b2406ba42b995f2368d
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Aug 27 17:33:20 2008 +1000

    sh: Add vmlinux support
    
    Add SuperH vmlinux support through a zero-page aware elf loader. Only for
    kexec at this point, in the future kdump support will be added.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 61d60261c616d75d6bd380744a78400972dd3e46
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Aug 27 17:33:17 2008 +1000

    sh: Use dynamic zImage load address
    
    Dynamically calculate SuperH zImage load address instead of hardcoding.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit e64db1cf9213d0ef9ce3c3df0ce9e23b1c2d7604
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Aug 27 17:32:31 2008 +1000

    sh: Autodetect zImage zero page address
    
    Autodetect the zero page base address for zImages on SuperH.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit ded6432c225a10c6390c83463471977c18492fff
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Aug 27 17:32:29 2008 +1000

    sh: Add virtual addresses support
    
    Implement virtual-to-physical address conversion functions for SuperH.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 4c3af19e8a98a11effa56fe21d3f557e15017f02
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Aug 27 17:32:26 2008 +1000

    sh: Get system memory ranges from /proc/iomem
    
    Parse contents of /proc/iomem instead of hardcoding RAM ranges.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 4b10f34bdc404f2c174fcb9b6a8638cb2ee96765
Author: Magnus Damm <damm at igel.co.jp>
Date:   Wed Aug 27 17:30:41 2008 +1000

    sh: Add support for sh4al-dsp processors
    
    Add support for sh4al-dsp processors such as sh7722.
    
    Signed-off-by: Magnus Damm <damm at igel.co.jp>
    Acked-by: Paul Mundt <lethal at linux-sh.org>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit cfa1ab96374d80f7c355cda30cd6922f96f20405
Author: Marc Kleine-Budde <mkl at pengutronix.de>
Date:   Sun Aug 24 21:21:36 2008 +0200

    arm: asm/page.h is no longer exported to userspace
    
    In recent kernels "asm/page.h" isn't exported to userspace anymore, thus
    the include is removed.
    
    Further this patch defines _XOPEN_SOURCE, in order to use getpagesize.
    
    Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 76e8efd603bf0134788634d2290490e7e346cca2
Author: Bernhard Walle <bwalle at suse.de>
Date:   Tue Aug 26 11:11:59 2008 +0200

    Update INSTALL
    
    That patch should merge my accidentally written INSTALL file with that
    already present in the git tree.
    
    It adds following items:
    
        - static compilation
        - cross compilation
    
    And updates the instructions to build the auto-generated files to use the
    "bootstrap" script already present.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit ffe7ad89763e21952b44872951fb915bf9e9ca85
Author: Bernhard Walle <bwalle at suse.de>
Date:   Tue Aug 26 11:03:43 2008 +0200

    Add INSTALL to tarball
    
    This patch just adds the installation file to the tarball.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 6abf3ba5dc63ef670010927d5572d38c3ce2a587
Author: Bernhard Walle <bwalle at suse.de>
Date:   Tue Aug 26 10:16:49 2008 +0200

    Move $(LIBS) on the end
    
    To make static compilation work with
    
        LDFLAGS=-static ./configure
        make
    
    we have to move $(LIBS) on the end of the compiler line. Static compilation has
    been requested by "Yinghai Lu" <yhlu.kernel at gmail.com>. Although I don't see the
    practical benefit in most cases, I don't think we should not support it. Since
    kexec does not use name resolution functions of libc, it's valid to use static
    linking.
    
    Tested on x86_64-suse-linux.
    
    Signed-off-by: Bernhard Walle <bwalle at suse.de>
    Signed-off-by: Simon Horman <horms at verge.net.au>

commit 8108aeeef14a2ab40756e90c980ac09687eff007
Author: Simon Horman <horms at verge.net.au>
Date:   Sat Jul 19 10:33:05 2008 +1000

    kexec-tools 2.0.0-git
    
    Add -git to version so it doesn't look like a release.
    This is just so when people build code from git it can
    be identified as such from the version string.
    
    Signed-off-by: Simon Horman <horms at verge.net.au>


From tonywilliams at inbox.com  Sat Jul 25 15:38:09 2009
From: tonywilliams at inbox.com (Tony williams)
Date: Sat, 25 Jul 2009 11:38:09 -0800
Subject: Hello
Message-ID: <B33849988DA.0000003Etonywilliams@inbox.com>

Hello Sir,

I am a little boy of 20 yrs; I am originally come from the Liberia but live in the refugee
camp in Accra Ghana . I came here with my family since 8 yrs after the Liberian war. But
they are late.

I was informed by my late father that the consignment he kept some where was consignment
of money that I am the biological owner of the total money if he is not alive. I went to
the place where he kept the money as consignment and I was introduced to the company
barrister who told me that before I can be able to have the consignment box that I will
have to come with a partner as my relative or as my beneficiary before they will release
the box to me.

The boxes he kept were registered as our family belongings, but the content is 15 million
dollars in each box. Only I and you know the content. If you are willing to stand as my
partner to this box I will be happy, because this box is my only hope to further education
and invest in a good business abroad.

You will receive the 40% percent of the total money if you will stand as my partner to
claim this box from the company where it?s.

I don?t have funds to claim this box from there due to the demurrage it has accumulated in
the company since it was deposited in the company.
I look forward to receive your reply to my email for us to deliberate on the next step to
follow and have these two boxes.

Name Tony williams


From vivianofferplc012 at mchsi.com  Mon Jul 27 12:19:27 2009
From: vivianofferplc012 at mchsi.com (vivianofferplc012 at mchsi.com)
Date: Mon, 27 Jul 2009 16:19:27 +0000
Subject: No subject
Message-ID: <072720091619.9404.4A6DD38F000CCDB2000024BC223045151403010CD2079C080C03BFCDCECF0C049F9D0A000001020E07900790@mchsi.com>

This is a Financial Service Announcement, we offer loan to all in need,ranging from $5000 to $800,000.00 USD. Our interest rate is 3% and our service and terms are dependable. any interested person should apply via email:lapoloanlender at gmail.com



From subscription at netlan.se  Mon Jul 27 18:23:33 2009
From: subscription at netlan.se (Favuzza)
Date: Mon, 27 Jul 2009 21:23:33 -0100
Subject: crepitant
Message-ID: <15d0c97a08e77d0f294265a120090727211653@netlan.se>

22 Nights of Erotic Linegrie Fun.www.molopo. net


From lethal at linux-sh.org  Mon Jul 27 18:37:58 2009
From: lethal at linux-sh.org (Paul Mundt)
Date: Tue, 28 Jul 2009 07:37:58 +0900
Subject: [PATCH] kexec: Handle datarootdir for newer autoconf versions.
Message-ID: <20090727223758.GA22668@linux-sh.org>

This fixes up the:

config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir setting

warning when producing the output Makefile.

Signed-off-by: Paul Mundt <lethal at linux-sh.org>

---

 Makefile.in |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.in b/Makefile.in
index 6b4c954..cb0faae 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -10,6 +10,7 @@ bindir		= @bindir@
 sbindir		= @sbindir@
 libexecdir	= @libexecdir@
 datadir		= @datadir@
+datarootdir	= @datarootdir@
 sysconfdir	= @sysconfdir@
 sharedstatedir	= @sharedstatedir@
 localstatedir	= @localstatedir@


From horms at verge.net.au  Mon Jul 27 20:23:25 2009
From: horms at verge.net.au (Simon Horman)
Date: Tue, 28 Jul 2009 10:23:25 +1000
Subject: [PATCH] kexec: Handle datarootdir for newer autoconf versions.
In-Reply-To: <20090727223758.GA22668@linux-sh.org>
References: <20090727223758.GA22668@linux-sh.org>
Message-ID: <20090728002324.GB20230@verge.net.au>

On Tue, Jul 28, 2009 at 07:37:58AM +0900, Paul Mundt wrote:
> This fixes up the:
> 
> config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir setting
> 
> warning when producing the output Makefile.

Thanks, applied.


From nijsure.subodh at gmail.com  Tue Jul 28 11:13:52 2009
From: nijsure.subodh at gmail.com (Subodh Nijsure)
Date: Tue, 28 Jul 2009 08:13:52 -0700
Subject: kexecing ELF image built by wraplinux or mkelf
Message-ID: <110c8b2e0907280813n2bcf24daxdce75b07f35beee8@mail.gmail.com>

I am trying to boot ELF image that is combined kernel + ramdisk. I
have tried to use wraplinux tool to wrap these two image but kexec
doesn't seem to boot the combined image.

To keep things simple I have decided to first just wrap bzImage

wraplinux -E --output vmlinux.wrap ./arch/i386/boot/bzImage

readelf -S vmlinux.wrap
There are 5 section headers, starting at offset 0x1f4098:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] setup             PROGBITS        00010000 000080 002a00 00 WAX  0   0 16
  [ 2] reloc             PROGBITS        00012a00 002a80 0005bc 00 WAX  0   0 16
  [ 3] kernel            PROGBITS        00100000 003040 1f1038 00   A  0   0 16
  [ 4] .shstrtab         STRTAB          00000000 1f4078 00001e 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

I am trying to load this image in my existing kernel using following
command line ( i instrumented the kexec a bit to print info structure
to see if kexec is reading the elf image correctly

kexec  --type=elf-x86 --args-elf --reuse-cmdline  ./vmlinux.wrap

kexec_load: entry = 0x17d8 flags = 0
nr_segments = 4
segment[0].buf   = 0x806f7b0
segment[0].bufsz = 7060
segment[0].mem   = 0x1000
segment[0].memsz = 9000
segment[1].buf   = 0x8076818
segment[1].bufsz = ec
segment[1].mem   = 0xa000
segment[1].memsz = 1000
segment[2].buf   = 0xb79f6088
segment[2].bufsz = 2fbc
segment[2].mem   = 0x10000
segment[2].memsz = 3000
segment[3].buf   = 0xb79f9048
segment[3].bufsz = 1f1038
segment[3].mem   = 0x100000
segment[3].memsz = 1f2000

I follow this my kexec -e and my machine "hangs".

Anybody has tried booting output of wraplinux using kexec? I have had
similar problems with mkelf-linux tool chain as well...

/Subodh


