All of lore.kernel.org
 help / color / mirror / Atom feed
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 -

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.