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: 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 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: 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 --- --- 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 > --- > --- 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 >> --- >> --- 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 > Thanks > Ken'ichi Ohmichi > > >> Signed-off-by: Ken'ichi Ohmichi > >> --- > >> --- 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) : <> : 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] : <> : 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 Cc: Vivek Goyal Cc: Haren Myneni 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 Cc: Vivek Goyal Cc: Haren Myneni 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 #include #include +#include +#include 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 Cc: Vivek Goyal Cc: Haren Myneni 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 Cc: Vivek Goyal Cc: Haren Myneni 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 Cc: Vivek Goyal Cc: Haren Myneni 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 Cc: Vivek Goyal Cc: Haren Myneni 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 Cc: Vivek Goyal Cc: Haren Myneni 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 > >> Thanks >> Ken'ichi Ohmichi >> >>>> Signed-off-by: Ken'ichi Ohmichi >>>> --- >>>> --- 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 > > > >> Thanks > >> Ken'ichi Ohmichi > >> > >>>> Signed-off-by: Ken'ichi Ohmichi > >>>> --- > >>>> --- 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 >>> >>>> Thanks >>>> Ken'ichi Ohmichi >>>> >>>>>> Signed-off-by: Ken'ichi Ohmichi >>>>>> --- >>>>>> --- 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 Acked-by: Simon Horman --- --- 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 > Acked-by: Simon Horman > --- > --- 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 >> Acked-by: Simon Horman >> --- >> --- 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 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 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 Acked-by: Simon Horman --- --- 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 > Acked-by: Simon Horman > --- > --- 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 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: "Ken'ichi Ohmichi" 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: References: <4A55A4AE.3000206@mxs.nes.nec.co.jp> <4A56E069.5040907@jp.fujitsu.com> <4A5AB903.6090204@mxs.nes.nec.co.jp> 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 Signed-off-by: Hidetoshi Seto Tested-by: Jin Dongming --- 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: -- 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: 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 Date: Wed Jul 22 12:09:50 2009 +1000 kexec-tools 2.0.1-rc1 Signed-off-by: Simon Horman commit 3444dce25ba125ae6d9522bbd297f78cb31211fb Author: Simon Horman Date: Wed Jul 22 12:09:13 2009 +1000 Include kexec/arch/cris/kexec-cris.h in distribution tarball Signed-off-by: Simon Horman commit 346ed7a0c89e48f4bffceca8b4c4f50cc4932fc6 Author: Simon Horman Date: Wed Jul 22 12:08:21 2009 +1000 Include kexec/arch/sh/crashdump-sh.h in distribution tarball Signed-off-by: Simon Horman commit 24e8417fff62b3f3d4fbee52d0dd383ba50178a5 Author: Geoff Levand 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 Signed-off-by: Simon Horman commit 7ca0270ab3e2f1abcc520f59c6795f1b873bddcd Author: Magnus Damm 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 Signed-off-by: Simon Horman commit 09e2b3a3f9f6477875da1bfacdcf1f1bb1b4486a Author: Magnus Damm 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 Signed-off-by: Simon Horman commit 0cd674d83b07bd5fd1bbd09d40bea2825e44d3d1 Author: Magnus Damm 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 Signed-off-by: Simon Horman commit 958704f7e56f5eefef2d6e13975258400d3fdbfd Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit ad28e87b60062cfcd423fcdecce56d651c38cc1e Author: Chandru 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 Signed-off-by: Simon Horman commit 0f15c4319a6f26d55ad0ddb58c1c43068091c570 Author: Chandru 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 Reviewed-by: Bernhard Walle Signed-off-by: Simon Horman commit 988a8a9c29230233abf7772bc3dce00603f3011a Author: Bernhard Walle 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 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 Signed-off-by: Simon Horman commit 95c74405638c786bc76fbca5e4e8427dfe26e907 Author: Bernhard Walle 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 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 Signed-off-by: Simon Horman commit 8afb534bf7c538eb3f57595054056289cda97b88 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit 6d4cdf4f94bf7ad2d1752b553ea948385881ff79 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16 Author: Milton Miller 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 Tested-by: M. Mohan Kumar Signed-off-by: Simon Horman commit 969203ab173765b775e617391a2605c073f63410 Author: Milton Miller 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 Tested-by: M. Mohan Kumar Signed-off-by: Simon Horman commit 4fcb65c9089c2c9d203402d549c4e11e44021542 Author: Milton Miller 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 Tested-by: M. Mohan Kumar Signed-off-by: Simon Horman commit 79c650e757561b03163da73dfc367f702248ef98 Author: Milton Miller 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 Tested-by: M. Mohan Kumar Signed-off-by: Simon Horman commit e8f2de09b52c3f4e23f907a6f6bf837b1f45af50 Author: Milton Miller 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 Tested-by: M. Mohan Kumar Signed-off-by: Simon Horman commit 14f69fc20bec03f7db1c4f4c0e45d9e73400e9a5 Author: Simon Horman 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 commit df0878e64e92d403c4e2e5604cd81d6d1baff169 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit 73a97629eab98f06b2b1a707e9b310d5fd9f9520 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit fcd049da6ac36183e2dc69bd1f479d059e8dd9a7 Author: Huang Ying 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 Signed-off-by: Huang Ying Signed-off-by: Simon Horman commit 9bf8dee9bab15d7f6de8a4cd332e77a1559083e3 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit 186a545ec38c028cadb948310dac4faba4589fd0 Author: Stefan Assmann 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 . 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 Signed-off-by: Simon Horman commit d182ce5434c7b66569118db0ccfe63e5d8a03687 Author: Maxim Uvarov 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 Signed-off-by: Simon Horman commit 2b6a50a16a3de9716c8a34af43b8286e5b58b1f2 Author: Huang Ying 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 Signed-off-by: Simon Horman commit ceb04ae1223ba5cdd40df744aa73a32b2cc7d879 Author: Huang Ying 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 Signed-off-by: Simon Horman commit 802a8a5e396e06a514251c44454c982bff3c5073 Author: Chandru 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 Signed-off-by: Simon Horman commit 39dd40d3e83acbe8ef2f1465e02e8d3e26e6a21d Author: Jay Lan 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 Signed-off-by: Simon Horman commit a96b5c237919e6761260efa83cc6f9d455c25ac1 Author: Simon Horman 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 commit 84aa7cf2468c2921d61d4cb97c1df670a470ea8b Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit 1d19ca0c4306c3c684cf4d277781975e4ad1c193 Author: Chandru 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 Signed-off-by: Simon Horman commit cd8497a9a9e487684679b6747f7ba3f0a557328b Author: Chandru 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 Signed-off-by: Simon Horman commit 726c130af8b1371aa32dc14f108a3fb1695860bb Author: Chandru 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 Signed-off-by: Simon Horman commit d9c5b2da1fad4ac9064db4c890e41066f873f6d3 Author: Mohan Kumar M 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 Signed-off-by: Simon Horman commit fc071d2a74ae26d817276e82ab71046e6387cbd1 Author: Simon Horman 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 commit b039510932e5b3d9691a5d423c34f7ebb14e5175 Author: Edgar E. Iglesias 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 Add a CRISv32 port. Initially only the elf filetype is supported. Signed-off-by: Edgar E. Iglesias Signed-off-by: Simon Horman commit 800fe37b7931cb11c47c88bf1fd69aa096d3cebe Author: Edgar E. Iglesias 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 commit edd13ae1c4965b6f1e8a8e07d8e01d31fef37d55 Author: Simon Horman 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 commit 7210dc1f75575412b6c29b004614194b9d3ce956 Author: Simon Horman Date: Wed Oct 8 17:08:51 2008 +1100 ia64: use generic put_unaligned() Signed-off-by: Simon Horman commit 4bd67d530f92313fd66bb462d96e3995b8e08af3 Author: Bjorn Helgaas 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 Signed-off-by: Simon Horman commit c466edd86b31a9d34cde3db24b093223108627d2 Author: Jay Lan 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 Signed-off-by: Simon Horman commit b422925d35151caa65471c0f0d774727bde4a347 Author: Geoff Levand 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 Signed-off-by: Simon Horman commit c1d13f4bd287f48c5fce02c3916b132f618c40fb Author: Geoff Levand 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 Signed-off-by: Simon Horman commit 011e3d8660ea44b934f6468b70b1411c97a123a8 Author: Paul Mundt 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 Signed-off-by: Simon Horman commit 0723defb5308ac7fce296f8b596bff4df6803f01 Author: Paul Mundt 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 Signed-off-by: Simon Horman commit e534a0c9fed2066ed3636a082e67f6fafa779019 Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit e956e4a66847606e133bcc4b97704aa09441a064 Author: Magnus Damm Date: Wed Sep 3 20:36:42 2008 +0900 sh: Fix help text spelling Fix SuperH help text spelling. Signed-off-by: Magnus Damm Signed-off-by: Simon Horman commit 93792363d3455459c7af7c646c0a1d1238c772fb Author: Maxim Shchetynin 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 Signed-off-by: Simon Horman commit 6eae8c1bc4d43d07c9799b2406ba42b995f2368d Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit 61d60261c616d75d6bd380744a78400972dd3e46 Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit e64db1cf9213d0ef9ce3c3df0ce9e23b1c2d7604 Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit ded6432c225a10c6390c83463471977c18492fff Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit 4c3af19e8a98a11effa56fe21d3f557e15017f02 Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit 4b10f34bdc404f2c174fcb9b6a8638cb2ee96765 Author: Magnus Damm 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 Acked-by: Paul Mundt Signed-off-by: Simon Horman commit cfa1ab96374d80f7c355cda30cd6922f96f20405 Author: Marc Kleine-Budde 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 Signed-off-by: Simon Horman commit 76e8efd603bf0134788634d2290490e7e346cca2 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit ffe7ad89763e21952b44872951fb915bf9e9ca85 Author: Bernhard Walle 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 Signed-off-by: Simon Horman commit 6abf3ba5dc63ef670010927d5572d38c3ce2a587 Author: Bernhard Walle 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" . 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 Signed-off-by: Simon Horman commit 8108aeeef14a2ab40756e90c980ac09687eff007 Author: Simon Horman 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 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: 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 --- 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