Hi,
> From: Michal Hocko [mailto:mho...@kernel.org]
> On Fri 31-07-15 11:23:00, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > > There is a timeout of 1000ms in nmi_shootdown_cpus(), so I don't know
> > > > why CPU 130 waits so long. I'll try to consider fo
On Fri 31-07-15 11:23:00, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > From: Michal Hocko [mailto:mho...@kernel.org]
[...]
> > I am saying that watchdog_overflow_callback might trigger on more CPUs
> > and panic from NMI context as well. So this is not reduced to the NMI
> > button sends NMI to more CPUs.
>
>
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Thu 30-07-15 11:55:52, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> [...]
> > > Could you point me to the code which does that, please? Maybe we are
> > > missing that in our 3.0 kernel. I was quite surpri
On Thu 30-07-15 11:55:52, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > From: Michal Hocko [mailto:mho...@kernel.org]
[...]
> > Could you point me to the code which does that, please? Maybe we are
> > missing that in our 3.0 kernel. I was quite surprised to see this
> > behavior as well.
>
> Please see the sni
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Thu 30-07-15 01:45:35, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > >
> > > On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> [...]
> > > > #define nmi_panic(fmt, ...)
Hi,
> -Original Message-
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Thu 30-07-15 07:33:15, 河合英宏 / KAWAI，HIDEHIRO wrote:
> [...]
> > Are you using SGI UV? On that platform, NMIs may be delivered to
> > all cpus because LVT1 of all cpus are not masked as follows:
>
> This is C
On Thu 30-07-15 07:33:15, 河合英宏 / KAWAI，HIDEHIRO wrote:
[...]
> Are you using SGI UV? On that platform, NMIs may be delivered to
> all cpus because LVT1 of all cpus are not masked as follows:
This is Compute Blade 520XB1 from Hitachi with 240 cpus.
--
Michal Hocko
SUSE Labs
--
To unsubscribe fro
On Thu 30-07-15 01:45:35, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Hi,
>
> > From: Michal Hocko [mailto:mho...@kernel.org]
> >
> > On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
[...]
> > > #define nmi_panic(fmt, ...)\
> > >do {
Hi Michal,
> From: 河合英宏 / KAWAI，HIDEHIRO [mailto:hidehiro.kawai...@hitachi.com]
> > When I was testing my
> > previous approach (on 3.0 based kernel) I had basically the same thing
> > (one NMI to process panic) and others to return. This led to a strange
> > behavior when the NMI button triggered
Hi,
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > Hi,
> > > >
> > > > > From: linux-kernel-ow...@vger.kernel.org
>
On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > From: Michal Hocko [mailto:mho...@kernel.org]
> > On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > Hi,
> > >
> > > > From: linux-kernel-ow...@vger.kernel.org
> > > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hide
> From: Michal Hocko [mailto:mho...@kernel.org]
> On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: linux-kernel-ow...@vger.kernel.org
> > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> > > (2015/07/27 23:34), Michal Hocko wrote:
> > > > On
On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Hi,
>
> > From: linux-kernel-ow...@vger.kernel.org
> > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> > (2015/07/27 23:34), Michal Hocko wrote:
> > > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> [...]
> > > T
Hi,
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> (2015/07/27 23:34), Michal Hocko wrote:
> > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
[...]
> > The check could be also relaxed a bit and nmi_panic would
> > return onl
On Tue 28-07-15 11:02:11, Hidehiro Kawai wrote:
[...]
> > Something like
> [...]
> > +void nmi_panic(const char *fmt, ...)
>
> Since we can't directly pass variable arguments to a subroutine,
Sure, I was just too lazy to finish this as it was just an illustration
of the idea.
> we have to use a
Hi,
Thanks for the review.
(2015/07/27 23:34), Michal Hocko wrote:
> On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> [...]
>> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
>> index d05bd2e..5b32d81 100644
>> --- a/arch/x86/kernel/nmi.c
>> +++ b/arch/x86/kernel/nmi.c
>> @@ -230,7 +2
On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
[...]
> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
> index d05bd2e..5b32d81 100644
> --- a/arch/x86/kernel/nmi.c
> +++ b/arch/x86/kernel/nmi.c
> @@ -230,7 +230,8 @@ void unregister_nmi_handler(unsigned int type, const char
> *name)
>
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 context if
we've already entered panic().
V2:
- Use atomic_cmpxchg() instead of current spin_t
18 matches
Mail list logo
