mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>, Kirill Korotaev <dev@sw.ru>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] NMI watchdog config option (was: Re: [PATCH] NMI lockup and AltSysRq-P dumping calltraces on _all_ cpus via NMI IPI)
Date: Tue, 17 May 2005 07:01:40 -0700	[thread overview]
Message-ID: <293160000.1116338500@[10.10.2.4]> (raw)
In-Reply-To: <20050517001542.40e6c6b7.akpm@osdl.org>



--Andrew Morton <akpm@osdl.org> wrote (on Tuesday, May 17, 2005 00:15:42 -0700):

> Kirill Korotaev <dev@sw.ru> wrote:
>> 
>> BTW, why NMI watchdog is disabled by default?
> 
> There was a significantly large string of reports of dying PCs in the
> 2.4.early timeframe.  These machines would mysteriously lock up after
> considerable periods of time and the problem was cured by disabling the NMI
> watchdog.  Nobody was ever able to solve it, so we changed it to default to
> off.
> 
> So much has changed in there that we might have fixed it by accident, and I
> do recall a couple of fundamental and subtle NMI bugs being fixed.  So
> yeah, it might be worth enabling it by default again.  Care to send a patch
> which does that?

There are some unfixable machine issues - for instance, the IBM
Netfinity 8500R corrupts one of the registers (ebx?) every time we get
an NMI for us, and panics. Probably other boxes you mention above have
similar issues? But it's not our code that's at fault ...

In light of this, I don't think it's a good idea to enable NMI by default,
at least not without a blacklist function of some sort?

M.


  parent reply	other threads:[~2005-05-17 14:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-11 15:57 [PATCH] NMI lockup and AltSysRq-P dumping calltraces on _all_ cpus via NMI IPI Kirill Korotaev
2005-05-16 22:34 ` Martin J. Bligh
2005-05-17  7:04   ` [PATCH] NMI watchdog config option (was: Re: [PATCH] NMI lockup and AltSysRq-P dumping calltraces on _all_ cpus via NMI IPI) Kirill Korotaev
2005-05-17  7:15     ` Andrew Morton
2005-05-17 10:41       ` Kirill Korotaev
2005-05-17 14:01       ` Martin J. Bligh [this message]
2005-05-17 22:16         ` Andrew Morton
2005-05-17 22:26           ` Martin J. Bligh
2005-05-17 17:30       ` Valdis.Kletnieks
2005-05-17 15:48     ` Linus Torvalds
2005-05-17 15:59       ` Maciej W. Rozycki
2005-05-17 16:32         ` Linus Torvalds
2005-05-17 17:04           ` Maciej W. Rozycki
2005-05-17 17:20             ` Linus Torvalds
2005-05-17 17:44               ` Maciej W. Rozycki
2005-05-17 17:25     ` Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='293160000.1116338500@[10.10.2.4]' \
    --to=martin.bligh@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dev@sw.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®