From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Soeren Sonnenburg <kernel@nn7.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Len Brown <len.brown@intel.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: [patch] high-res timers: UP resume fix
Date: Sat, 7 Apr 2007 10:12:44 +0200 [thread overview]
Message-ID: <20070407081244.GA28284@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0704061552380.6730@woody.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> In fact, I have a theory.. Your backtrace is:
>
> [<c0119637>] smp_apic_timer_interrupt+0x57/0x90
> [<c0142d30>] retrigger_next_event+0x0/0xb0
> [<c0104d30>] apic_timer_interrupt+0x28/0x30
> [<c0142d30>] retrigger_next_event+0x0/0xb0
> [<c0140068>] __kfifo_put+0x8/0x90
> [<c0130fe5>] on_each_cpu+0x35/0x60
> [<c0143538>] clock_was_set+0x18/0x20
> [<c0135cdc>] timekeeping_resume+0x7c/0xa0
> [<c02aabe1>] __sysdev_resume+0x11/0x80
> [<c02ab0c7>] sysdev_resume+0x47/0x80
> [<c02b0b05>] device_power_up+0x5/0x10
>
> and the thing is, I don't think we should have interrupt enabled at
> this point in time! I susect that the timer resume enables interrupts
> too early! We should be doing the whole "device_power_up()" sequence
> with irq's off, I think..
yeah, i think you are right. timekeeping_resume() itself does not
re-enable interrupts, it's clock_was_set() that does it implicitly:
void clock_was_set(void)
{
/* Retrigger the CPU local events everywhere */
on_each_cpu(retrigger_next_event, NULL, 0, 1);
}
on_each_cpu() is safe on SMP during resume 'bootup', because we only
have a single CPU at that point, and smp_call_function() does:
spin_lock(&call_lock);
cpus = num_online_cpus() - 1;
if (!cpus) {
spin_unlock(&call_lock);
so we just return. Note that the built-in warning of smp_call_function()
does not trigger because it's done too late:
/* Can deadlock when called with interrupts disabled */
WARN_ON(irqs_disabled());
we should move this up to the head of the function. But for this bug in
question to trigger we'd have to use an UP kernel, which has this code
for on_each_cpu():
#define on_each_cpu(func,info,retry,wait) \
({ \
local_irq_disable(); \
func(info); \
local_irq_enable(); \
ouch!
the solution is this: what we want to call here in timekeeping_resume is
not clock_was_set() but retrigger_next_event() for the current CPU. The
patch below should fix it. Soeren, can you confirm that you are using a
!CONFIG_SMP kernel, and if yes, does the patch below fix the resume
problem for you?
Ingo
---------------------------->
Subject: [patch] high-res timers: UP resume fix
From: Ingo Molnar <mingo@elte.hu>
Soeren Sonnenburg reported that upon resume he is getting
this backtrace:
[<c0119637>] smp_apic_timer_interrupt+0x57/0x90
[<c0142d30>] retrigger_next_event+0x0/0xb0
[<c0104d30>] apic_timer_interrupt+0x28/0x30
[<c0142d30>] retrigger_next_event+0x0/0xb0
[<c0140068>] __kfifo_put+0x8/0x90
[<c0130fe5>] on_each_cpu+0x35/0x60
[<c0143538>] clock_was_set+0x18/0x20
[<c0135cdc>] timekeeping_resume+0x7c/0xa0
[<c02aabe1>] __sysdev_resume+0x11/0x80
[<c02ab0c7>] sysdev_resume+0x47/0x80
[<c02b0b05>] device_power_up+0x5/0x10
it turns out that on UP we mistakenly re-enable interrupts,
so do the timer retrigger only on the current CPU.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/linux/hrtimer.h | 3 +++
kernel/hrtimer.c | 12 ++++++++++++
2 files changed, 15 insertions(+)
Index: linux/include/linux/hrtimer.h
===================================================================
--- linux.orig/include/linux/hrtimer.h
+++ linux/include/linux/hrtimer.h
@@ -206,6 +206,7 @@ struct hrtimer_cpu_base {
struct clock_event_device;
extern void clock_was_set(void);
+extern void hres_timers_resume(void);
extern void hrtimer_interrupt(struct clock_event_device *dev);
/*
@@ -236,6 +237,8 @@ static inline ktime_t hrtimer_cb_get_tim
*/
static inline void clock_was_set(void) { }
+static inline void hres_timers_resume(void) { }
+
/*
* In non high resolution mode the time reference is taken from
* the base softirq time variable.
Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -459,6 +459,18 @@ void clock_was_set(void)
}
/*
+ * During resume we might have to reprogram the high resolution timer
+ * interrupt (on the local CPU):
+ */
+void hres_timers_resume(void)
+{
+ WARN_ON_ONCE(num_online_cpus() > 1);
+
+ /* Retrigger the CPU local events: */
+ retrigger_next_event(NULL);
+}
+
+/*
* Check, whether the timer is on the callback pending list
*/
static inline int hrtimer_cb_pending(const struct hrtimer *timer)
next prev parent reply other threads:[~2007-04-07 8:12 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-06 2:50 Linux 2.6.21-rc6 Linus Torvalds
2007-04-06 21:40 ` tg3: unable to handle null pointer dereference [Re: Linux 2.6.21-rc6] Nishanth Aravamudan
2007-04-06 22:57 ` Michael Chan
2007-04-07 0:36 ` tg3: unable to handle null pointer dereference David Miller
2007-04-07 1:53 ` Nishanth Aravamudan
2007-04-06 22:44 ` Linux 2.6.21-rc6 - regressions update Soeren Sonnenburg
2007-04-06 23:04 ` Linus Torvalds
2007-04-07 8:12 ` Ingo Molnar [this message]
2007-04-07 8:25 ` [patch] high-res timers: UP resume fix Ingo Molnar
2007-04-07 8:48 ` Thomas Gleixner
2007-04-07 8:50 ` Ingo Molnar
2007-04-07 9:48 ` Rafael J. Wysocki
2007-04-07 9:47 ` Ingo Molnar
2007-04-07 9:51 ` Thomas Gleixner
2007-04-07 9:53 ` Rafael J. Wysocki
2007-04-11 14:00 ` Pavel Machek
2007-04-07 8:51 ` Thomas Gleixner
2007-04-07 9:49 ` [patch] high-res timers: " Ingo Molnar
2007-04-07 10:02 ` Rafael J. Wysocki
2007-04-07 10:05 ` [patch, take #3] " Ingo Molnar
2007-04-07 10:45 ` Soeren Sonnenburg
2007-04-08 15:57 ` Linux 2.6.21-rc6 - regressions update Soeren Sonnenburg
2007-04-07 8:48 ` Linux 2.6.21-rc6 Michal Piotrowski
2007-04-07 18:37 ` Randy Dunlap
2007-04-07 18:46 ` Linus Torvalds
2007-04-07 18:50 ` Randy Dunlap
2007-04-07 18:51 ` Linus Torvalds
2007-04-07 20:58 ` Gene Heskett
2007-04-08 23:09 ` Andrew Morton
2007-04-09 0:42 ` Greg KH
2007-04-09 0:59 ` Jeff Garzik
2007-04-10 7:57 ` Chris Wedgwood
2007-04-11 7:38 ` Ingo Molnar
2007-04-10 3:32 ` Dmitry Torokhov
2007-04-10 14:35 ` Jeff Chua
2007-04-10 15:35 ` Linus Torvalds
2007-04-12 4:16 ` Jeff Chua
2007-04-12 9:55 ` [new 2.6.21-rc6 crash] BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Ingo Molnar
2007-04-12 15:14 ` Linux 2.6.21-rc6 Mattia Dongili
2007-04-12 17:02 ` Mattia Dongili
2007-04-12 18:26 ` Maxim Levitsky
2007-04-13 8:52 ` Mattia Dongili
2007-04-13 21:29 ` Tobias Diedrich
2007-04-13 23:50 ` Adrian Bunk
2007-04-14 6:50 ` Tobias Diedrich
2007-04-14 8:16 ` Tobias Diedrich
2007-04-14 9:05 ` Rafael J. Wysocki
2007-04-14 10:32 ` Tobias Diedrich
2007-04-14 12:26 ` Adrian Bunk
2007-04-14 12:09 ` Tobias Diedrich
2007-04-14 12:24 ` Tobias Diedrich
2007-04-14 12:31 ` Tobias Diedrich
2007-04-14 13:00 ` Adrian Bunk
2007-04-14 18:28 ` Rafael J. Wysocki
2007-04-14 19:56 ` Tobias Diedrich
2007-04-14 20:23 ` Rafael J. Wysocki
2007-04-14 20:25 ` Adrian Bunk
2007-04-14 20:38 ` Rafael J. Wysocki
2007-04-14 21:35 ` Tobias Diedrich
2007-04-14 21:58 ` Rafael J. Wysocki
2007-04-15 7:38 ` Tobias Diedrich
2007-04-15 8:02 ` Tobias Diedrich
2007-04-15 11:16 ` Rafael J. Wysocki
2007-04-15 14:19 ` Dmitry Torokhov
2007-04-15 15:52 ` Rafael J. Wysocki
2007-04-15 18:50 ` Tobias Diedrich
2007-04-15 19:37 ` Rafael J. Wysocki
2007-04-15 15:14 ` [linux-pm] " David Brownell
2007-04-15 16:37 ` Rafael J. Wysocki
2007-04-15 17:53 ` David Brownell
2007-04-15 19:40 ` Tobias Diedrich
2007-04-15 19:54 ` Rafael J. Wysocki
2007-04-25 17:14 ` Tobias Diedrich
2007-04-25 19:36 ` Rafael J. Wysocki
2007-04-25 20:09 ` Tobias Diedrich
2007-04-14 0:36 ` [1/3] 2.6.21-rc6: known regressions Adrian Bunk
2007-04-14 0:38 ` [2/3] " Adrian Bunk
2007-04-14 0:38 ` [3/3] " Adrian Bunk
2007-04-14 1:57 ` Antonino A. Daplas
2007-04-15 16:26 ` Marcus Better
2007-04-15 23:08 ` Antonino A. Daplas
2007-04-16 6:23 ` Marcus Better
2007-04-16 6:45 ` Antonino A. Daplas
2007-04-17 8:17 ` Marcus Better
2007-04-17 9:27 ` Antonino A. Daplas
2007-04-17 11:54 ` Marcus Better
2007-04-24 15:33 ` Pavel Machek
2007-04-14 7:24 ` Tobias Doerffel
2007-04-14 7:40 ` Dave Jones
2007-04-15 17:15 ` Jeff Chua
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=20070407081244.GA28284@elte.hu \
--to=mingo@elte.hu \
--cc=kernel@nn7.de \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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