Dave Young suggested to me to explain the problem in more detail,
so here is the revised commit description. The patch is now in -mm,
so I copied Cc list from -mm version. Also I added Corey Minyard's
Tested-by and Reviewed-by.
From: Hidehiro Kawai
Subject:
Dave Young suggested to me to explain the problem in more detail,
so here is the revised commit description. The patch is now in -mm,
so I copied Cc list from -mm version. Also I added Corey Minyard's
Tested-by and Reviewed-by.
From: Hidehiro Kawai
Subject: mips/panic: replace smp_send_stop()
Here is the revised commit description reflecting Dave's
comment. Cc list was copied from -mm version.
From: Hidehiro Kawai
Subject: x86/panic: replace smp_send_stop() with kdump friendly version in
panic path
This patch fixes a problem reported by Daniel Walker
Here is the revised commit description reflecting Dave's
comment. Cc list was copied from -mm version.
From: Hidehiro Kawai
Subject: x86/panic: replace smp_send_stop() with kdump friendly version in
panic path
This patch fixes a problem reported by Daniel Walker
Hi Xunlei,
> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, September 20, 2016 4:40 PM
> On 2016/08/15/ at 19:22, Hidehiro Kawai wrote:
> > Hi Dave,
> >
> > Thank you for the review.
> >
> >> From: Dave Young [mailto:dyo...@redhat.com]
> >> Sent: Friday, August 12, 2016 12:17 PM
>
Hi Xunlei,
> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, September 20, 2016 4:40 PM
> On 2016/08/15/ at 19:22, Hidehiro Kawai wrote:
> > Hi Dave,
> >
> > Thank you for the review.
> >
> >> From: Dave Young [mailto:dyo...@redhat.com]
> >> Sent: Friday, August 12, 2016 12:17 PM
>
> From: Corey Minyard [mailto:cminy...@mvista.com]
> Sent: Tuesday, August 16, 2016 3:02 AM
> On 08/15/2016 12:06 PM, Corey Minyard wrote:
> > On 08/15/2016 06:35 AM, 河合英宏 / KAWAI,HIDEHIRO wrote:
> >> Hi Corey,
> >>
> >>> From: Corey Minyard [mailto:cm
> From: Corey Minyard [mailto:cminy...@mvista.com]
> Sent: Tuesday, August 16, 2016 3:02 AM
> On 08/15/2016 12:06 PM, Corey Minyard wrote:
> > On 08/15/2016 06:35 AM, 河合英宏 / KAWAI,HIDEHIRO wrote:
> >> Hi Corey,
> >>
> >>> From: Corey Minyard [mailto:cm
Hi Corey,
> From: Corey Minyard [mailto:cminy...@mvista.com]
> Sent: Friday, August 12, 2016 10:56 PM
> I'll try to test this, but I have one comment inline...
Thank you very much!
> On 08/11/2016 10:17 PM, Dave Young wrote:
> > On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:
[snip]
> >> diff
Hi Corey,
> From: Corey Minyard [mailto:cminy...@mvista.com]
> Sent: Friday, August 12, 2016 10:56 PM
> I'll try to test this, but I have one comment inline...
Thank you very much!
> On 08/11/2016 10:17 PM, Dave Young wrote:
> > On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:
[snip]
> >> diff
Hi Dave,
Thank you for the review.
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Friday, August 12, 2016 12:17 PM
>
> Thanks for the update.
> On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:
> > Daniel Walker reported problems which happens when
> > crash_kexec_post_notifiers kernel
Hi Dave,
Thank you for the review.
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Friday, August 12, 2016 12:17 PM
>
> Thanks for the update.
> On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:
> > Daniel Walker reported problems which happens when
> > crash_kexec_post_notifiers kernel
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Tuesday, July 19, 2016 3:52 PM
> Hi,
> On 07/19/16 at 05:51am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi,
> >
> > > From: 'Dave Young' [mailto:dyo...@redhat.com]
> > > Sent: Monday, July 18, 2016 6:02 PM
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Tuesday, July 19, 2016 3:52 PM
> Hi,
> On 07/19/16 at 05:51am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi,
> >
> > > From: 'Dave Young' [mailto:dyo...@redhat.com]
> > > Sent: Monday, July 18, 2016 6:02 PM
Hi,
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Monday, July 18, 2016 6:02 PM
> On 07/15/16 at 11:50am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for your reply.
> >
> > > From: 'Dave Young' [mailto:dyo...@redhat.com]
>
Hi,
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Monday, July 18, 2016 6:02 PM
> On 07/15/16 at 11:50am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for your reply.
> >
> > > From: 'Dave Young' [mailto:dyo...@redhat.com]
>
Hi Dave,
Thanks for your reply.
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Wednesday, July 13, 2016 11:04 AM
>
> On 07/12/16 at 02:49am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for the comments.
> >
> > > From: Dav
Hi Dave,
Thanks for your reply.
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Wednesday, July 13, 2016 11:04 AM
>
> On 07/12/16 at 02:49am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for the comments.
> >
> > > From: Dav
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xunlei Pang
> Sent: Tuesday, July 12, 2016 3:57 PM
> On 2016/07/12 at 11:56, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi Xunlei,
> >
> > Thanks for the review.
> &g
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xunlei Pang
> Sent: Tuesday, July 12, 2016 3:57 PM
> On 2016/07/12 at 11:56, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Hi Xunlei,
> >
> > Thanks for the review.
> &g
Hi Xunlei,
Thanks for the review.
> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, July 12, 2016 12:12 PM
> On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If
Hi Xunlei,
Thanks for the review.
> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, July 12, 2016 12:12 PM
> On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If
Hi Dave,
Thanks for the comments.
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Monday, July 11, 2016 5:35 PM
>
> On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If
Hi Dave,
Thanks for the comments.
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Monday, July 11, 2016 5:35 PM
>
> On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If
> From: Phil Pokorny [mailto:ppoko...@penguincomputing.com]
>
> While you are in drivers/watchdog/hpwdt.c replacing panic() with
> nmi_panic() can you also fix a few more of the broken strings? The
> Linux style guide specfiically says NOT to break strings that are user
> visible because it
> From: Phil Pokorny [mailto:ppoko...@penguincomputing.com]
>
> While you are in drivers/watchdog/hpwdt.c replacing panic() with
> nmi_panic() can you also fix a few more of the broken strings? The
> Linux style guide specfiically says NOT to break strings that are user
> visible because it
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Thu, Mar 03, 2016 at 07:57:44PM +0900, Hidehiro Kawai wrote:
> > Change nmi_panic() macro to a normal function for the portability.
>
> portability?
I wanted to say encapsulating things into a function makes modules
only have to know about the
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Thu, Mar 03, 2016 at 07:57:44PM +0900, Hidehiro Kawai wrote:
> > Change nmi_panic() macro to a normal function for the portability.
>
> portability?
I wanted to say encapsulating things into a function makes modules
only have to know about the
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Wed, Mar 02, 2016 at 02:18:24PM +0100, Michal Hocko wrote:
> > On Wed 02-03-16 19:36:26, Hidehiro Kawai wrote:
> > [...]
> > > +void nmi_panic(struct pt_regs *regs, const char *fmt, ...)
> >
> > Do we really need vargs? All the current
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Wed, Mar 02, 2016 at 02:18:24PM +0100, Michal Hocko wrote:
> > On Wed 02-03-16 19:36:26, Hidehiro Kawai wrote:
> > [...]
> > > +void nmi_panic(struct pt_regs *regs, const char *fmt, ...)
> >
> > Do we really need vargs? All the current
Hi Borislav,
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Tue, Mar 01, 2016 at 10:50:37AM +0900, Hidehiro Kawai wrote:
> > Export panic_cpu and nmi_panic_self_stop symbols for modules which
> > use nmi_panic() macro.
> >
> > Signed-off-by: Hidehiro Kawai
>
Hi Borislav,
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Tue, Mar 01, 2016 at 10:50:37AM +0900, Hidehiro Kawai wrote:
> > Export panic_cpu and nmi_panic_self_stop symbols for modules which
> > use nmi_panic() macro.
> >
> > Signed-off-by: Hidehiro Kawai
> > Cc: Andrew Morton
> > Cc:
Hi Corey,
Thanks for the review.
> Sure, this is a good idea.
>
> Acked-by: Corey Minyard
>
> Note that nmi_panic() came in commit 1717f2096b5 (panic, x86: Fix
> re-entrance problem due to panic on NMI) and then the regs field
> was added in the commit you reference.
Hi Corey,
Thanks for the review.
> Sure, this is a good idea.
>
> Acked-by: Corey Minyard
>
> Note that nmi_panic() came in commit 1717f2096b5 (panic, x86: Fix
> re-entrance problem due to panic on NMI) and then the regs field
> was added in the commit you reference.
Yes. So, I'll change the
Hi Guenter,
Thanks for the review.
> On 02/29/2016 05:50 PM, Hidehiro Kawai wrote:
> > commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even
> > if looping in NMI context") introduced nmi_panic() which prevents
> > concurrent/recursive execution of panic(). It also saves registers
Hi Guenter,
Thanks for the review.
> On 02/29/2016 05:50 PM, Hidehiro Kawai wrote:
> > commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even
> > if looping in NMI context") introduced nmi_panic() which prevents
> > concurrent/recursive execution of panic(). It also saves registers
> From: Borislav Petkov [mailto:b...@alien8.de]
[...]
> Looks better.
>
> Did some comments cleanup and nmi_panic() macro reformatting so that it
> is more readable and ended up applying this:
Thanks a lot!
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
> ---
> From: Hidehiro Kawai
> From: Borislav Petkov [mailto:b...@alien8.de]
[...]
> Looks better.
>
> Did some comments cleanup and nmi_panic() macro reformatting so that it
> is more readable and ended up applying this:
Thanks a lot!
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
> ---
> From: Hidehiro Kawai
Hi Steven,
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> > > + */
> > > + while (!raw_spin_trylock(_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs
Hi Steven,
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> > > + */
> > > + while (!raw_spin_trylock(_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs
> On Thu, Dec 03, 2015 at 02:01:38AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > On Wed, Dec 02, 2015 at 11:57:38AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > We can do so, but I think resetting panic_cpu always would be
> > > > simpler and safer.
> >
>
> On Thu, Dec 03, 2015 at 02:01:38AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > On Wed, Dec 02, 2015 at 11:57:38AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > We can do so, but I think resetting panic_cpu always would be
> > > > simpler and safer.
> >
>
> @@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs)
> }
>
> /* Non-CPU-specific NMI: NMI sources can be processed on any CPU */
> - raw_spin_lock(_reason_lock);
> +
> + /*
> + * Another CPU may be processing panic routines with holding
> + *
> On Wed, Dec 02, 2015 at 11:57:38AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > We can do so, but I think resetting panic_cpu always would be
> > simpler and safer.
I'll state in detail.
When we call crash_kexec() without entering panic() and return from
it, panic() should be ca
Hello Borislav,
Sorry, I haven't replied to this mail yet.
> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote:
...
> > +void crash_kexec(struct pt_regs *regs)
> > +{
> > + int old_cpu, this_cpu;
> > +
> > + /*
> > +* Only one CPU is allowed to execute the crash_kexec() code
Hello Borislav,
Sorry, I haven't replied to this mail yet.
> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote:
...
> > +void crash_kexec(struct pt_regs *regs)
> > +{
> > + int old_cpu, this_cpu;
> > +
> > + /*
> > +* Only one CPU is allowed to execute the crash_kexec() code
> On Wed, Dec 02, 2015 at 11:57:38AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > We can do so, but I think resetting panic_cpu always would be
> > simpler and safer.
I'll state in detail.
When we call crash_kexec() without entering panic() and return from
it, panic() should be ca
> @@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs)
> }
>
> /* Non-CPU-specific NMI: NMI sources can be processed on any CPU */
> - raw_spin_lock(_reason_lock);
> +
> + /*
> + * Another CPU may be processing panic routines with holding
> + *
> On Fri, Nov 20, 2015 at 06:36:50PM +0900, Hidehiro Kawai wrote:
> > This patch introduces new boot option, apic_extnmi:
> >
> > apic_extnmi={ bsp | all | none}
> >
> > The default value is "bsp" and this is the current behavior; only
> > BSP receives external NMI. "all" allows external NMIs to
> On Wed, Nov 25, 2015 at 09:46:37AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
...
> > I prefer this, but we might want to add some more prefix or suffix.
> > For example, "conditionally_run_crash_nmi_callback".
>
> That's unnecessary IMO. If you need t
> On Wed, Nov 25, 2015 at 05:51:59AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > `Infinite loop in NMI context' can happen:
> > > >
> > > > a. when a cpu panics on NMI while another cpu is processing panic
> > > > b. when a cpu received an ext
> On Fri, Nov 20, 2015 at 06:36:50PM +0900, Hidehiro Kawai wrote:
> > This patch introduces new boot option, apic_extnmi:
> >
> > apic_extnmi={ bsp | all | none}
> >
> > The default value is "bsp" and this is the current behavior; only
> > BSP receives external NMI. "all" allows external NMIs to
> On Wed, Nov 25, 2015 at 09:46:37AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
...
> > I prefer this, but we might want to add some more prefix or suffix.
> > For example, "conditionally_run_crash_nmi_callback".
>
> That's unnecessary IMO. If you need t
> On Wed, Nov 25, 2015 at 05:51:59AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > `Infinite loop in NMI context' can happen:
> > > >
> > > > a. when a cpu panics on NMI while another cpu is processing panic
> > > > b. when a cpu received an ext
> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote:
> > Currently, panic() and crash_kexec() can be called at the same time.
> > For example (x86 case):
> >
> > CPU 0:
> > oops_end()
> > crash_kexec()
> > mutex_trylock() // acquired
> > nmi_shootdown_cpus() //
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> >
> > > + */
> > > + while (!raw_spin_trylock(_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs broadcasted on every core but
> > we're *not* crash dumping, we
> On Fri, Nov 20, 2015 at 06:36:46PM +0900, Hidehiro Kawai wrote:
> > nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI
> > to non-panic cpus to stop them while saving their register
>
>...to stop them and save their register...
Thanks for the correction.
> >
> On Fri, Nov 20, 2015 at 06:36:46PM +0900, Hidehiro Kawai wrote:
> > nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI
> > to non-panic cpus to stop them while saving their register
>
>...to stop them and save their register...
Thanks for the correction.
> >
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> >
> > > + */
> > > + while (!raw_spin_trylock(_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs broadcasted on every core but
> > we're *not* crash dumping, we
> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote:
> > Currently, panic() and crash_kexec() can be called at the same time.
> > For example (x86 case):
> >
> > CPU 0:
> > oops_end()
> > crash_kexec()
> > mutex_trylock() // acquired
> > nmi_shootdown_cpus() //
Hi,
> On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote:
> > If panic on NMI happens just after panic() on the same CPU, panic()
> > is recursively called. As the result, it stalls after failing to
> > acquire panic_lock.
> >
> > To avoid this problem, don't call panic() in NMI
Hi,
> On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote:
> > If panic on NMI happens just after panic() on the same CPU, panic()
> > is recursively called. As the result, it stalls after failing to
> > acquire panic_lock.
> >
> > To avoid this problem, don't call panic() in NMI
Hi,
> I just have a look at this thread. I am wondering why we don't use
> existing is_kdump_kernel() directly to disable external NMI if it's
> in kdump kernel. Then no need to introduce another boot option "noextnmi"
> which is used only for kdump kernel.
As I stated in another mail, there is
Hi,
> I just have a look at this thread. I am wondering why we don't use
> existing is_kdump_kernel() directly to disable external NMI if it's
> in kdump kernel. Then no need to introduce another boot option "noextnmi"
> which is used only for kdump kernel.
As I stated in another mail, there is
> > By the way, I have a pending patch which expands this option like
> > this:
> >
> > apic_extnmi={ bsp | all | none }
> >
> > If apic_extnmi=all is specified, external NMIs are broadcast to
> > all CPUs. This raises the successful rate of kernel panic in the case
> > where an external NMI
> * Thomas Gleixner wrote:
>
> > Borislav,
> >
> > On Mon, 5 Oct 2015, Borislav Petkov wrote:
> > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > That's different from my point of view. I'm not going to pass
> >
> * Thomas Gleixner <t...@linutronix.de> wrote:
>
> > Borislav,
> >
> > On Mon, 5 Oct 2015, Borislav Petkov wrote:
> > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > That's different from my point of view. I'm
> > By the way, I have a pending patch which expands this option like
> > this:
> >
> > apic_extnmi={ bsp | all | none }
> >
> > If apic_extnmi=all is specified, external NMIs are broadcast to
> > all CPUs. This raises the successful rate of kernel panic in the case
> > where an external NMI
> On Fri, 25 Sep 2015, Hidehiro Kawai wrote:
>
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI. This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by NMI.
> >
> >
Hello, Boris
Sorry for the late reply.
> On Mon, Oct 05, 2015 at 09:21:02AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > So, the problem for you is that "noextnmi" option is visible and effective
> > in the first kernel, isn't it?
>
> No, such an option shouldn't exis
> On Fri, 25 Sep 2015, Hidehiro Kawai wrote:
>
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI. This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by NMI.
> >
> >
Hello, Boris
Sorry for the late reply.
> On Mon, Oct 05, 2015 at 09:21:02AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > So, the problem for you is that "noextnmi" option is visible and effective
> > in the first kernel, isn't it?
>
> No, such an option shouldn't exis
> On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > That's different from my point of view. I'm not going to pass
> > some data from the first kernel to the second kernel. I'm just going to
> > provide a configurable option for the second kernel to
> On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > That's different from my point of view. I'm not going to pass
> > some data from the first kernel to the second kernel. I'm just going to
> > provide a configurable option for the second kernel to
> On Fri, Oct 02, 2015 at 12:58:02AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > On Thu, Oct 01, 2015 at 10:24:19AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > But how do we check if the starting kernel is a dump capture kernel?
> > >
> > > How does that fi
> On Fri, Oct 02, 2015 at 12:58:02AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > On Thu, Oct 01, 2015 at 10:24:19AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > > But how do we check if the starting kernel is a dump capture kernel?
> > >
> > > How does that fi
> On Thu, Oct 01, 2015 at 10:24:19AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > But how do we check if the starting kernel is a dump capture kernel?
>
> How does that first kernel pass info to the capture kernel?
As I described in the previous mail, You just have t
> On Thu, Oct 01, 2015 at 07:01:50AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > I suppose that a sever which uses this feature will equip a BMC
> > and BMC mandatorily supports hard reset command for the server.
> > If the HA clustering software detects no response from
> On Thu, Oct 01, 2015 at 02:33:18AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > > > This patch introduces new boot option "noextnmi" which disables
> > > > external NMI. This option is
> On Thu, Oct 01, 2015 at 07:01:50AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > I suppose that a sever which uses this feature will equip a BMC
> > and BMC mandatorily supports hard reset command for the server.
> > If the HA clustering software detects no response from
> On Thu, Oct 01, 2015 at 02:33:18AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > > > This patch introduces new boot option "noextnmi" which disables
> > > > external NMI. This option is
> On Thu, Oct 01, 2015 at 10:24:19AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > But how do we check if the starting kernel is a dump capture kernel?
>
> How does that first kernel pass info to the capture kernel?
As I described in the previous mail, You just have t
> On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI. This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by
> On Mon, Sep 28, 2015 at 07:08:19AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg'
> > > atomic_xchg(_cpu, -1);
> > > ^
> >
> > I changed to use atomic_xchg() inst
> On Fri, Sep 25, 2015 at 08:28:07PM +0900, Hidehiro Kawai wrote:
> > --- a/arch/x86/kernel/reboot.c
> > +++ b/arch/x86/kernel/reboot.c
> > @@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
> > static nmi_shootdown_cb shootdown_callback;
> >
> > static atomic_t
> On Fri, Sep 25, 2015 at 12:13:55PM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the
> > previoius discussion, but it still exists. So, I didn't change
> > anything about panic_on_unrecovered_nmi.
> >
>
>
> On Fri, Sep 25, 2015 at 12:13:55PM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the
> > previoius discussion, but it still exists. So, I didn't change
> > anything about panic_on_unrecovered_nmi.
> >
>
>
> On Fri, Sep 25, 2015 at 08:28:07PM +0900, Hidehiro Kawai wrote:
> > --- a/arch/x86/kernel/reboot.c
> > +++ b/arch/x86/kernel/reboot.c
> > @@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
> > static nmi_shootdown_cb shootdown_callback;
> >
> > static atomic_t
> On Mon, Sep 28, 2015 at 07:08:19AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg'
> > > atomic_xchg(_cpu, -1);
> > > ^
> >
> > I changed to use atomic_xchg() inst
> On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI. This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by
> Hi Hidehiro,
>
> [auto build test results on v4.3-rc2 -- if it's inappropriate base, please
> ignore]
>
> config: ia64-allyesconfig (attached as .config)
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
>
> Hi Hidehiro,
>
> [auto build test results on v4.3-rc2 -- if it's inappropriate base, please
> ignore]
>
> config: ia64-allyesconfig (attached as .config)
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
>
> Hi Hidehiro,
>
> [auto build test results on v4.3-rc2 -- if it's inappropriate base, please
> ignore]
>
> config: x86_64-allnoconfig (attached as .config)
> reproduce:
> git checkout 0077681103150af584e5e592c0238fd010654c26
> # save the attached .config to linux build tree
> make
> Hi Hidehiro,
>
> [auto build test results on v4.3-rc2 -- if it's inappropriate base, please
> ignore]
>
> config: x86_64-allnoconfig (attached as .config)
> reproduce:
> git checkout 0077681103150af584e5e592c0238fd010654c26
> # save the attached .config to linux build tree
> make
Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the
previoius discussion, but it still exists. So, I didn't change
anything about panic_on_unrecovered_nmi.
Thanks,
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
> From: Hidehiro Kawai
Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the
previoius discussion, but it still exists. So, I didn't change
anything about panic_on_unrecovered_nmi.
Thanks,
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
> From: Hidehiro Kawai
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> On Mon, Aug 31, 2015 at 08:53:11AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > I understand your question. I don't intend to permit the recursive
> > > call of crash_kexec() as for 'old_cpu != this_cpu' check. That is
&
Hello Peter,
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of 河合英宏 / KAWAI,
>
> Hi,
>
> > From: Peter Zijlstra [mailto:pet...@infradead.org]
> >
> > On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI,HI
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> On Mon, Aug 31, 2015 at 08:53:11AM +, 河合英宏 / KAWAI,HIDEHIRO wrote:
> > > I understand your question. I don't intend to permit the recursive
> > > call of crash_kexec() as for 'old_cpu != this_cpu' check. That is
&
Hello Peter,
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of 河合英宏 / KAWAI,
>
> Hi,
>
> > From: Peter Zijlstra [mailto:pet...@infradead.org]
> >
> > On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI,HI
1 - 100 of 232 matches
Mail list logo