[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070306113225.GA22561@elte.hu>
Date: Tue, 6 Mar 2007 12:32:26 +0100
From: Ingo Molnar <mingo@...e.hu>
To: "Michael S. Tsirkin" <mst@...lanox.co.il>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Adrian Bunk <bunk@...sta.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
Emil Karlson <jkarlson@...hut.fi>,
Soeren Sonnenburg <kernel@....de>, Len Brown <lenb@...nel.org>
Subject: Re: [5/6] 2.6.21-rc2: known regressions
* Michael S. Tsirkin <mst@...lanox.co.il> wrote:
> > > Not yet for me unfortunately, although this seems to help.
> > > Is this the patch I should have applied?
> > > http://lkml.org/lkml/2007/3/5/445
> > >
> > > With this applied, on resume I get *some* screen output soon after
> > > resume (e.g. with s2ram I get several characters on VGA, X starts
> > > drawing some windows) but then the crescent symbol starts blinking
> > > again and the system hangs.
> >
> > could you try this via s2ram on a text console, to see whether the
> > kernel spits out any warning before it locks up?
>
> Yes, that's what I did. Unfortunately only a couple of characters were
> shown before it locked up.
>
> I still need to check what does this do in the NO_HZ configuration.
>
> BTW, Ingo, can you suspend/resume any number of times with this patch?
yeah, i can now suspend/resume an arbitrary number of times, vga,
network, SATA all works fine after that. (i tried it 5 times)
i also have the patch below applied - but i dont think it should make a
difference to your case. (maybe it does though) I've attached my config
as well.
Ingo
------>
From: Thomas Gleixner <tglx@...utronix.de>
The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable
clocksource and clock event sources are registered. The switch to high
resolution mode happens inside of the TIMER_SOFTIRQ, but runs the
softirq afterwards. That way the tick emulation timer, which was set up
in the switch to highres might be executed in the softirq context, which
is a BUG. The rbtree has not to be touched by the softirq after the
highres switch.
This BUG was observed by Andres Salomon, who provided the information to
debug it.
Return early from the softirq, when the switch was sucessful.
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
kernel/hrtimer.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -540,19 +540,19 @@ static inline int hrtimer_enqueue_reprog
/*
* Switch to high resolution mode
*/
-static void hrtimer_switch_to_hres(void)
+static int hrtimer_switch_to_hres(void)
{
struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
unsigned long flags;
if (base->hres_active)
- return;
+ return 1;
local_irq_save(flags);
if (tick_init_highres()) {
local_irq_restore(flags);
- return;
+ return 0;
}
base->hres_active = 1;
base->clock_base[CLOCK_REALTIME].resolution = KTIME_HIGH_RES;
@@ -565,13 +565,14 @@ static void hrtimer_switch_to_hres(void)
local_irq_restore(flags);
printk(KERN_INFO "Switched to high resolution mode on CPU %d\n",
smp_processor_id());
+ return 1;
}
#else
static inline int hrtimer_hres_active(void) { return 0; }
static inline int hrtimer_is_hres_enabled(void) { return 0; }
-static inline void hrtimer_switch_to_hres(void) { }
+static inline int hrtimer_switch_to_hres(void) { return 0; }
static inline void hrtimer_force_reprogram(struct hrtimer_cpu_base *base) { }
static inline int hrtimer_enqueue_reprogram(struct hrtimer *timer,
struct hrtimer_clock_base *base)
@@ -1173,7 +1174,8 @@ void hrtimer_run_queues(void)
* deadlock vs. xtime_lock.
*/
if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))
- hrtimer_switch_to_hres();
+ if (hrtimer_switch_to_hres())
+ return;
hrtimer_get_softirq_time(cpu_base);
View attachment ".config" of type "text/plain" (77229 bytes)
Powered by blists - more mailing lists