> 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.
> >
>
> > > --- a/arch/x86/kernel/nmi.c
>
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.
>
> > --- a/arch/x86/kernel/nmi.c
> > +++ b/arch
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 [mailto:hidehiro.kawai...@hitachi.c
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().
V4:
- Improve comments in io_check_error() and panic
4 matches
Mail list logo