public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Don Zickus <dzickus@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Len Brown <len.brown@intel.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Yong Zhang <yong.zhang0@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	Andy Grover <andy.grover@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: acpi_os_stall() and touch_nmi_watchdog() (was Re: [PATCH] fix BUG using smp_processor_id() in touch_nmi_watchdog and touch_softlockup_watchdog)
Date: Thu, 26 Aug 2010 13:17:39 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1008261210420.4686@localhost.localdomain> (raw)
In-Reply-To: <20100819204256.3380bf6f.akpm@linux-foundation.org>

acpi_os_stall() is used in two ways.

The typical way is what triggered this e-mail thread.
It implements the AML "Stall()" operator, and is called
with interrupts enabled with durations <= 100 usec.
So one would expect it to be identical to udelay().

The exception case is when ACPICA calls it with interrupts off
and huge durations when we wrote the poweroff or sleep
register, yet we find outselves still running...

Apparently akpm added touch_nmi_watchdog() to keep the
watchdog from firing in this exception case.

Is it useful to have the watchdog running when
we are waiting for firmware to poweroff the machine?
If no, maybe we should turn it off as part of the shutdown
process rather than using yet another invocation
of touch_nmi_watchdog()?

Is calling delay() with IRQs disabled the best thing
we can do after we ask the firmware to cut power
and it takes a long time?

thanks,
Len Brown, Intel Open Source Technology Center

  parent reply	other threads:[~2010-08-26 17:18 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-13 10:21 fix BUG: using smp_processor_id() in touch_nmi_watchdog and touch_softlockup_watchdog Sergey Senozhatsky
2010-08-16  8:22 ` Peter Zijlstra
2010-08-16 13:34   ` Don Zickus
2010-08-16 13:46     ` Peter Zijlstra
2010-08-16 14:08       ` [PATCH] fix BUG " Sergey Senozhatsky
2010-08-16 14:30         ` Don Zickus
2010-08-17  4:27           ` Yong Zhang
2010-08-17  2:59         ` Frederic Weisbecker
2010-08-17  3:16           ` Yong Zhang
2010-08-17  8:39             ` Sergey Senozhatsky
2010-08-17  9:05               ` Yong Zhang
2010-08-17  9:24                 ` Sergey Senozhatsky
2010-08-17  9:37                   ` Yong Zhang
2010-08-17 10:28                     ` Sergey Senozhatsky
2010-08-17 12:48                       ` Yong Zhang
2010-08-17 10:39                     ` Sergey Senozhatsky
2010-08-17 12:56                       ` Yong Zhang
2010-08-17 13:13                       ` Don Zickus
2010-08-18  2:48                         ` Frederic Weisbecker
2010-08-18 20:01                           ` Andrew Morton
2010-08-19  2:27                             ` Don Zickus
2010-08-20  2:57                             ` Don Zickus
2010-08-20  3:42                               ` Andrew Morton
2010-08-20 12:34                                 ` Don Zickus
2010-08-26 17:17                                 ` Len Brown [this message]
2010-08-20 15:02                               ` Yong Zhang
2010-08-26 10:14                               ` Maxim Levitsky
2010-08-26 14:40                                 ` Don Zickus
2010-08-17  7:56           ` [PATCH] fix BUG using smp_processor_id() in touch_nmi_watchdog and touch_softlockup_watchdog (v2) Sergey Senozhatsky
2010-08-16 14:12       ` fix BUG: using smp_processor_id() in touch_nmi_watchdog and touch_softlockup_watchdog Don Zickus
2010-08-16 14:29         ` Peter Zijlstra
2010-08-16 14:06     ` Yong Zhang
2010-08-18 19:33 ` Andrew Morton
2010-08-18 21:44   ` Cyrill Gorcunov
2010-09-22  9:00   ` [PATCH] avoid second smp_processor_id() call in __touch_watchdog Sergey Senozhatsky
2010-09-22 14:41     ` Don Zickus
2010-09-22 16:27     ` Frederic Weisbecker
2010-09-22 16:39       ` Peter Zijlstra
2010-09-22 16:47         ` Frederic Weisbecker
2010-09-24 19:34     ` Don Zickus
2010-09-25 17:43       ` Sergey Senozhatsky

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=alpine.LFD.2.00.1008261210420.4686@localhost.localdomain \
    --to=lenb@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andy.grover@oracle.com \
    --cc=dzickus@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=yong.zhang0@gmail.com \
    /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