From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_around instead of apic_write
Date: Wed, 28 May 2008 22:32:12 +0400 [thread overview]
Message-ID: <20080528183212.GD6910@cvg> (raw)
In-Reply-To: <Pine.LNX.4.55.0805281828210.29522@cliff.in.clinika.pl>
[Maciej W. Rozycki - Wed, May 28, 2008 at 06:47:56PM +0100]
| On Wed, 28 May 2008, Cyrill Gorcunov wrote:
|
| > Thanks a lot, Maciej!!! Could you please explain me how did you find
| > that? 'cause reporter said that with nmi_watchdog=2 it works and with
| > nmi_watchdog=1 it stalls? Maybe I should better make this function
| > the same as 64bit version has? I.e. set nmi_watchdog = NMI_NONE by default?
|
| Well, nmi_watchdog=1 is the I/O APIC watchdog and if no watchdog has been
| specified at the command line, the piece of code you have moved selects
| between the local and the I/O APIC watchdog based on availability of the
| former. So in this case the local watchdog must have been unavailable as
| it works if requested explicitly.
|
| No piece of code in nmi_watchdog_default() touches peripheral hardware
| and native_smp_prepare_cpus() is called early enough the system is still
| running UP and no APIC setup has happened yet, so any interference with
| running hardware can be excluded.
|
| Random lock-ups are a typical symptom of the NMI watchdog interfering
| with SMM firmware -- of course in the context of the watchdog being
| suspected in the first place -- there may be plenty of other reasons of
| random lock-ups. Obviously this is the SMM firmware asking for trouble
| explicitly, because NMIs are disabled by the processor upon entering the
| SMM and it is the SMI handler that unmasks the NMI explicitly (with an
| IRET, which shouldn't be used in the SMM mode at all) -- otherwise it
| wouldn't even notice the watchdog running, but there you go.
|
| As a rule of thumb any piece of firmware that has a possibility to run
| from an OS context should not use interrupts of any kind, because it is
| quite likely it cannot handle them in the way the OS expects them to be
| handled. It is as simple as that, but perhaps too simple for some to
| comprehend. :(
|
| Maciej
|
oh... :( i think i just restore old behaviour for now. Thanks for explanation!
- Cyrill -
next prev parent reply other threads:[~2008-05-28 18:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080524153630.669797039@gmail.com>
2008-05-24 15:36 ` [patch 01/11] x86: nmi - unify die_nmi() interface Cyrill Gorcunov
2008-05-24 15:36 ` [patch 02/11] x86: nmi - die_nmi() output message unification Cyrill Gorcunov
2008-05-24 15:36 ` [patch 03/11] x86: nmi_64.c - move do_nmi(), stop_nmi() and restart_nmi() implementation to traps_64.c Cyrill Gorcunov
2008-05-24 15:36 ` [patch 04/11] x86: nmi_32.c - add "panic" option Cyrill Gorcunov
2008-05-24 15:36 ` [patch 05/11] x86: nmi_32.c - add nmi_watchdog_default helper Cyrill Gorcunov
2008-05-24 15:36 ` [patch 06/11] x86: nmi_32/64.c - use apic_write_around instead of apic_write Cyrill Gorcunov
2008-05-28 15:35 ` Maciej W. Rozycki
2008-05-28 16:04 ` Cyrill Gorcunov
2008-05-28 16:13 ` Maciej W. Rozycki
2008-05-28 16:25 ` Cyrill Gorcunov
2008-05-28 17:09 ` Maciej W. Rozycki
2008-05-28 17:16 ` Cyrill Gorcunov
2008-05-28 17:47 ` Maciej W. Rozycki
2008-05-28 18:32 ` Cyrill Gorcunov [this message]
2008-05-24 15:36 ` [patch 07/11] x86: nmi_32.c - unknown_nmi_panic_callback should always panic on being called Cyrill Gorcunov
2008-05-24 15:36 ` [patch 08/11] x86: nmi_64.c - use for_each_possible_cpu helper instead of for statement Cyrill Gorcunov
2008-05-24 15:36 ` [patch 09/11] x86: nmi_32.c cleanup - use for_each_online_cpu helper Cyrill Gorcunov
2008-05-24 15:36 ` [patch 10/11] x86: nmi_32/64.c - add helper functions to hide mode-specific data Cyrill Gorcunov
2008-05-24 15:36 ` [patch 11/11] x86: nmi_32/64.c - merge down nmi_32.c and nmi_64.c to nmi.c Cyrill Gorcunov
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=20080528183212.GD6910@cvg \
--to=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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