All of lore.kernel.org
 help / color / mirror / Atom feed
* [ANNOUNCE] 3.0-rt6
@ 2011-07-28 21:43 Thomas Gleixner
  2011-07-28 22:33 ` Madovsky
                   ` (8 more replies)
  0 siblings, 9 replies; 29+ messages in thread
From: Thomas Gleixner @ 2011-07-28 21:43 UTC (permalink / raw)
  To: LKML; +Cc: linux-rt-users, Peter Zijlstra, Paul E. McKenney

Dear RT Folks,

I'm pleased to announce the 3.0-rt6 release.

Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)

  * pin_cpu fix (Yong Zhang)

  * Various compile fixes (Yong Zhang & myself)

  * Serial fix for omap

  * Clocksource lockless watchdog reset

  * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
    related to NO_HZ, which is still disabled. Paul is working on it!)

  * KGDB work^Whackaround (Jason Wessel)

    The kgdb workaround is really a hack and wants to be replaced by a
    proper overhaul for the console/tty maze.
    See: kgb-serial-hackaround.patch

As I said yesterday, I'm preparing for vanishing from the net. 

Please keep on testing and sending patches. Peter Zijlstra kindly
volunteered to cover for me. He'll pick up stuff and eventually push
out releases when a reasonable number of sane patches hits his inbox.

If you reply to that mail, please keep the Cc list intact to make sure
that all interested folks see it. It does not matter whether you are
subscribed to a particular mailing list or not. Just keep your fingers
away from the Cc list unless you have a very good reason to do
so. Hint for GUI mail "client" users: Hit "Reply to all" ....

For all those who are addicted to roadmaps, here is the roadmap I'm
caring about for the next two weeks:

  http://maps.google.com/maps?q=Fuchsenloch,+Schlier&hl=en&z=16

For the curious: Fuchsenloch == Fox hole. IOW: The place where fox and
rabbit say Good Night to each other.

And for those who care about estimates, here are my momentary
favourite Dilberts on this topic:

   http://dilbert.com/strips/comic/1995-11-10/
   http://dilbert.com/strips/comic/2010-05-05/

Patch against 3.0 can be found here:

  http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt6.patch.bz2

The split quilt queue is available at:

  http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt6.tar.bz2

Delta patch against 3.0-rt4 below.

Thanks,

	tglx
----
 arch/arm/include/asm/mmu.h       |    2 +-
 drivers/tty/serial/8250.c        |   13 +++++++++----
 drivers/tty/serial/omap-serial.c |    8 +++-----
 include/linux/kdb.h              |    2 ++
 init/Kconfig                     |    2 +-
 kernel/cpu.c                     |    4 +++-
 kernel/debug/kdb/kdb_io.c        |    6 ++----
 kernel/hrtimer.c                 |    4 +---
 kernel/time/clocksource.c        |   38 ++++++++++++++++++--------------------
 localversion-rt                  |    2 +-
 10 files changed, 41 insertions(+), 40 deletions(-)

Index: linux-2.6/arch/arm/include/asm/mmu.h
===================================================================
--- linux-2.6.orig/arch/arm/include/asm/mmu.h
+++ linux-2.6/arch/arm/include/asm/mmu.h
@@ -16,7 +16,7 @@ typedef struct {
 
 /* init_mm.context.id_lock should be initialized. */
 #define INIT_MM_CONTEXT(name)                                                 \
-	.context.id_lock    = __SPIN_LOCK_UNLOCKED(name.context.id_lock),
+	.context.id_lock    = __RAW_SPIN_LOCK_UNLOCKED(name.context.id_lock),
 #else
 #define ASID(mm)	(0)
 #endif
Index: linux-2.6/drivers/tty/serial/8250.c
===================================================================
--- linux-2.6.orig/drivers/tty/serial/8250.c
+++ linux-2.6/drivers/tty/serial/8250.c
@@ -38,6 +38,7 @@
 #include <linux/nmi.h>
 #include <linux/mutex.h>
 #include <linux/slab.h>
+#include <linux/kdb.h>
 
 #include <asm/io.h>
 #include <asm/irq.h>
@@ -2894,10 +2895,14 @@ serial8250_console_write(struct console 
 
 	touch_nmi_watchdog();
 
-	if (up->port.sysrq || oops_in_progress)
-		locked = spin_trylock_irqsave(&up->port.lock, flags);
-	else
-		spin_lock_irqsave(&up->port.lock, flags);
+	if (unlikely(in_kdb_printk())) {
+		locked = 0;
+	} else {
+		if (up->port.sysrq || oops_in_progress)
+			locked = spin_trylock_irqsave(&up->port.lock, flags);
+		else
+			spin_lock_irqsave(&up->port.lock, flags);
+	}
 
 	/*
 	 *	First save the IER then disable the interrupts
Index: linux-2.6/init/Kconfig
===================================================================
--- linux-2.6.orig/init/Kconfig
+++ linux-2.6/init/Kconfig
@@ -493,7 +493,7 @@ config TREE_RCU_TRACE
 
 config RCU_BOOST
 	bool "Enable RCU priority boosting"
-	depends on RT_MUTEXES && PREEMPT_RCU && !RT_PREEMPT_FULL
+	depends on RT_MUTEXES && PREEMPT_RCU
 	default n
 	help
 	  This option boosts the priority of preempted RCU readers that
Index: linux-2.6/kernel/cpu.c
===================================================================
--- linux-2.6.orig/kernel/cpu.c
+++ linux-2.6/kernel/cpu.c
@@ -75,9 +75,11 @@ static DEFINE_PER_CPU(struct hotplug_pcp
  */
 void pin_current_cpu(void)
 {
-	struct hotplug_pcp *hp = &__get_cpu_var(hotplug_pcp);
+	struct hotplug_pcp *hp;
 
 retry:
+	hp = &__get_cpu_var(hotplug_pcp);
+
 	if (!hp->unplug || hp->refcount || preempt_count() > 1 ||
 	    hp->unplug == current || (current->flags & PF_STOMPER)) {
 		hp->refcount++;
Index: linux-2.6/kernel/hrtimer.c
===================================================================
--- linux-2.6.orig/kernel/hrtimer.c
+++ linux-2.6/kernel/hrtimer.c
@@ -1294,11 +1294,9 @@ static void __run_hrtimer(struct hrtimer
 	timer->state &= ~HRTIMER_STATE_CALLBACK;
 }
 
-
-#ifdef CONFIG_PREEMPT_RT_BASE
-
 static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
 
+#ifdef CONFIG_PREEMPT_RT_BASE
 static void hrtimer_rt_reprogram(int restart, struct hrtimer *timer,
 				 struct hrtimer_clock_base *base)
 {
Index: linux-2.6/localversion-rt
===================================================================
--- linux-2.6.orig/localversion-rt
+++ linux-2.6/localversion-rt
@@ -1 +1 @@
--rt4
+-rt6
Index: linux-2.6/kernel/time/clocksource.c
===================================================================
--- linux-2.6.orig/kernel/time/clocksource.c
+++ linux-2.6/kernel/time/clocksource.c
@@ -186,6 +186,7 @@ static struct timer_list watchdog_timer;
 static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
 static DEFINE_SPINLOCK(watchdog_lock);
 static int watchdog_running;
+static atomic_t watchdog_reset_pending;
 
 static int clocksource_watchdog_kthread(void *data);
 static void __clocksource_change_rating(struct clocksource *cs, int rating);
@@ -247,12 +248,14 @@ static void clocksource_watchdog(unsigne
 	struct clocksource *cs;
 	cycle_t csnow, wdnow;
 	int64_t wd_nsec, cs_nsec;
-	int next_cpu;
+	int next_cpu, reset_pending;
 
 	spin_lock(&watchdog_lock);
 	if (!watchdog_running)
 		goto out;
 
+	reset_pending = atomic_read(&watchdog_reset_pending);
+
 	list_for_each_entry(cs, &watchdog_list, wd_list) {
 
 		/* Clocksource already marked unstable? */
@@ -268,7 +271,8 @@ static void clocksource_watchdog(unsigne
 		local_irq_enable();
 
 		/* Clocksource initialized ? */
-		if (!(cs->flags & CLOCK_SOURCE_WATCHDOG)) {
+		if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
+		    atomic_read(&watchdog_reset_pending)) {
 			cs->flags |= CLOCK_SOURCE_WATCHDOG;
 			cs->wd_last = wdnow;
 			cs->cs_last = csnow;
@@ -283,8 +287,11 @@ static void clocksource_watchdog(unsigne
 		cs->cs_last = csnow;
 		cs->wd_last = wdnow;
 
+		if (atomic_read(&watchdog_reset_pending))
+			continue;
+
 		/* Check the deviation from the watchdog clocksource. */
-		if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) {
+		if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
 			clocksource_unstable(cs, cs_nsec - wd_nsec);
 			continue;
 		}
@@ -303,6 +310,13 @@ static void clocksource_watchdog(unsigne
 	}
 
 	/*
+	 * We only clear the watchdog_reset_pending, when we did a
+	 * full cycle through all clocksources.
+	 */
+	if (reset_pending)
+		atomic_dec(&watchdog_reset_pending);
+
+	/*
 	 * Cycle through CPUs to check if the CPUs stay synchronized
 	 * to each other.
 	 */
@@ -344,23 +358,7 @@ static inline void clocksource_reset_wat
 
 static void clocksource_resume_watchdog(void)
 {
-	unsigned long flags;
-
-	/*
-	 * We use trylock here to avoid a potential dead lock when
-	 * kgdb calls this code after the kernel has been stopped with
-	 * watchdog_lock held. When watchdog_lock is held we just
-	 * return and accept, that the watchdog might trigger and mark
-	 * the monitored clock source (usually TSC) unstable.
-	 *
-	 * This does not affect the other caller clocksource_resume()
-	 * because at this point the kernel is UP, interrupts are
-	 * disabled and nothing can hold watchdog_lock.
-	 */
-	if (!spin_trylock_irqsave(&watchdog_lock, flags))
-		return;
-	clocksource_reset_watchdog();
-	spin_unlock_irqrestore(&watchdog_lock, flags);
+	atomic_inc(&watchdog_reset_pending);
 }
 
 static void clocksource_enqueue_watchdog(struct clocksource *cs)
Index: linux-2.6/drivers/tty/serial/omap-serial.c
===================================================================
--- linux-2.6.orig/drivers/tty/serial/omap-serial.c
+++ linux-2.6/drivers/tty/serial/omap-serial.c
@@ -947,13 +947,12 @@ serial_omap_console_write(struct console
 	unsigned int ier;
 	int locked = 1;
 
-	local_irq_save(flags);
 	if (up->port.sysrq)
 		locked = 0;
 	else if (oops_in_progress)
-		locked = spin_trylock(&up->port.lock);
+		locked = spin_trylock_irqsave(&up->port.lock, flags);
 	else
-		spin_lock(&up->port.lock);
+		spin_lock_irqsave(&up->port.lock, flags);
 
 	/*
 	 * First save the IER then disable the interrupts
@@ -980,8 +979,7 @@ serial_omap_console_write(struct console
 		check_modem_status(up);
 
 	if (locked)
-		spin_unlock(&up->port.lock);
-	local_irq_restore(flags);
+		spin_unlock_irqrestore(&up->port.lock, flags);
 }
 
 static int __init
Index: linux-2.6/include/linux/kdb.h
===================================================================
--- linux-2.6.orig/include/linux/kdb.h
+++ linux-2.6/include/linux/kdb.h
@@ -153,12 +153,14 @@ extern int kdb_register(char *, kdb_func
 extern int kdb_register_repeat(char *, kdb_func_t, char *, char *,
 			       short, kdb_repeat_t);
 extern int kdb_unregister(char *);
+#define in_kdb_printk() (kdb_trap_printk)
 #else /* ! CONFIG_KGDB_KDB */
 #define kdb_printf(...)
 #define kdb_init(x)
 #define kdb_register(...)
 #define kdb_register_repeat(...)
 #define kdb_uregister(x)
+#define in_kdb_printk() (0)
 #endif	/* CONFIG_KGDB_KDB */
 enum {
 	KDB_NOT_INITIALIZED,
Index: linux-2.6/kernel/debug/kdb/kdb_io.c
===================================================================
--- linux-2.6.orig/kernel/debug/kdb/kdb_io.c
+++ linux-2.6/kernel/debug/kdb/kdb_io.c
@@ -539,7 +539,6 @@ int vkdb_printf(const char *fmt, va_list
 	int diag;
 	int linecount;
 	int logging, saved_loglevel = 0;
-	int saved_trap_printk;
 	int got_printf_lock = 0;
 	int retlen = 0;
 	int fnd, len;
@@ -550,8 +549,6 @@ int vkdb_printf(const char *fmt, va_list
 	unsigned long uninitialized_var(flags);
 
 	preempt_disable();
-	saved_trap_printk = kdb_trap_printk;
-	kdb_trap_printk = 0;
 
 	/* Serialize kdb_printf if multiple cpus try to write at once.
 	 * But if any cpu goes recursive in kdb, just print the output,
@@ -807,7 +804,6 @@ kdb_print_out:
 	} else {
 		__release(kdb_printf_lock);
 	}
-	kdb_trap_printk = saved_trap_printk;
 	preempt_enable();
 	return retlen;
 }
@@ -817,9 +813,11 @@ int kdb_printf(const char *fmt, ...)
 	va_list ap;
 	int r;
 
+	kdb_trap_printk++;
 	va_start(ap, fmt);
 	r = vkdb_printf(fmt, ap);
 	va_end(ap);
+	kdb_trap_printk--;
 
 	return r;
 }

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
@ 2011-07-28 22:33 ` Madovsky
  2011-07-28 23:33 ` Peter W. Morreale
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 29+ messages in thread
From: Madovsky @ 2011-07-28 22:33 UTC (permalink / raw)
  To: linux-rt-users


----- Original Message ----- 
From: "Thomas Gleixner" <tglx@linutronix.de>
To: "LKML" <linux-kernel@vger.kernel.org>
Cc: "linux-rt-users" <linux-rt-users@vger.kernel.org>; "Peter Zijlstra" 
<peterz@infradead.org>; "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Sent: Thursday, July 28, 2011 5:43 PM
Subject: [ANNOUNCE] 3.0-rt6


> Dear RT Folks,
>
> I'm pleased to announce the 3.0-rt6 release.
>
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
>
>  * pin_cpu fix (Yong Zhang)
>
>  * Various compile fixes (Yong Zhang & myself)
>
>  * Serial fix for omap
>
>  * Clocksource lockless watchdog reset
>
>  * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>    related to NO_HZ, which is still disabled. Paul is working on it!)
>
>  * KGDB work^Whackaround (Jason Wessel)
>
>    The kgdb workaround is really a hack and wants to be replaced by a
>    proper overhaul for the console/tty maze.
>    See: kgb-serial-hackaround.patch
>
> As I said yesterday, I'm preparing for vanishing from the net.
>
> Please keep on testing and sending patches. Peter Zijlstra kindly
> volunteered to cover for me. He'll pick up stuff and eventually push
> out releases when a reasonable number of sane patches hits his inbox.
>
> If you reply to that mail, please keep the Cc list intact to make sure
> that all interested folks see it. It does not matter whether you are
> subscribed to a particular mailing list or not. Just keep your fingers
> away from the Cc list unless you have a very good reason to do
> so. Hint for GUI mail "client" users: Hit "Reply to all" ....
>
> For all those who are addicted to roadmaps, here is the roadmap I'm
> caring about for the next two weeks:
>
>  http://maps.google.com/maps?q=Fuchsenloch,+Schlier&hl=en&z=16
>
> For the curious: Fuchsenloch == Fox hole. IOW: The place where fox and
> rabbit say Good Night to each other.
>
> And for those who care about estimates, here are my momentary
> favourite Dilberts on this topic:
>
>   http://dilbert.com/strips/comic/1995-11-10/
>   http://dilbert.com/strips/comic/2010-05-05/
>
> Patch against 3.0 can be found here:
>
> 
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt6.patch.bz2
>
> The split quilt queue is available at:
>
> 
> http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt6.tar.bz2
>
> Delta patch against 3.0-rt4 below.
>
> Thanks,
>
> tglx
> ----
> arch/arm/include/asm/mmu.h       |    2 +-
> drivers/tty/serial/8250.c        |   13 +++++++++----
> drivers/tty/serial/omap-serial.c |    8 +++-----
> include/linux/kdb.h              |    2 ++
> init/Kconfig                     |    2 +-
> kernel/cpu.c                     |    4 +++-
> kernel/debug/kdb/kdb_io.c        |    6 ++----
> kernel/hrtimer.c                 |    4 +---
> kernel/time/clocksource.c        |   38 
> ++++++++++++++++++--------------------
> localversion-rt                  |    2 +-
> 10 files changed, 41 insertions(+), 40 deletions(-)
>
> Index: linux-2.6/arch/arm/include/asm/mmu.h
> ===================================================================
> --- linux-2.6.orig/arch/arm/include/asm/mmu.h
> +++ linux-2.6/arch/arm/include/asm/mmu.h
> @@ -16,7 +16,7 @@ typedef struct {
>
> /* init_mm.context.id_lock should be initialized. */
> #define INIT_MM_CONTEXT(name) 
> \
> - .context.id_lock    = __SPIN_LOCK_UNLOCKED(name.context.id_lock),
> + .context.id_lock    = __RAW_SPIN_LOCK_UNLOCKED(name.context.id_lock),
> #else
> #define ASID(mm) (0)
> #endif
> Index: linux-2.6/drivers/tty/serial/8250.c
> ===================================================================
> --- linux-2.6.orig/drivers/tty/serial/8250.c
> +++ linux-2.6/drivers/tty/serial/8250.c
> @@ -38,6 +38,7 @@
> #include <linux/nmi.h>
> #include <linux/mutex.h>
> #include <linux/slab.h>
> +#include <linux/kdb.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
> @@ -2894,10 +2895,14 @@ serial8250_console_write(struct console
>
>  touch_nmi_watchdog();
>
> - if (up->port.sysrq || oops_in_progress)
> - locked = spin_trylock_irqsave(&up->port.lock, flags);
> - else
> - spin_lock_irqsave(&up->port.lock, flags);
> + if (unlikely(in_kdb_printk())) {
> + locked = 0;
> + } else {
> + if (up->port.sysrq || oops_in_progress)
> + locked = spin_trylock_irqsave(&up->port.lock, flags);
> + else
> + spin_lock_irqsave(&up->port.lock, flags);
> + }
>
>  /*
>  * First save the IER then disable the interrupts
> Index: linux-2.6/init/Kconfig
> ===================================================================
> --- linux-2.6.orig/init/Kconfig
> +++ linux-2.6/init/Kconfig
> @@ -493,7 +493,7 @@ config TREE_RCU_TRACE
>
> config RCU_BOOST
>  bool "Enable RCU priority boosting"
> - depends on RT_MUTEXES && PREEMPT_RCU && !RT_PREEMPT_FULL
> + depends on RT_MUTEXES && PREEMPT_RCU
>  default n
>  help
>    This option boosts the priority of preempted RCU readers that
> Index: linux-2.6/kernel/cpu.c
> ===================================================================
> --- linux-2.6.orig/kernel/cpu.c
> +++ linux-2.6/kernel/cpu.c
> @@ -75,9 +75,11 @@ static DEFINE_PER_CPU(struct hotplug_pcp
>  */
> void pin_current_cpu(void)
> {
> - struct hotplug_pcp *hp = &__get_cpu_var(hotplug_pcp);
> + struct hotplug_pcp *hp;
>
> retry:
> + hp = &__get_cpu_var(hotplug_pcp);
> +
>  if (!hp->unplug || hp->refcount || preempt_count() > 1 ||
>      hp->unplug == current || (current->flags & PF_STOMPER)) {
>  hp->refcount++;
> Index: linux-2.6/kernel/hrtimer.c
> ===================================================================
> --- linux-2.6.orig/kernel/hrtimer.c
> +++ linux-2.6/kernel/hrtimer.c
> @@ -1294,11 +1294,9 @@ static void __run_hrtimer(struct hrtimer
>  timer->state &= ~HRTIMER_STATE_CALLBACK;
> }
>
> -
> -#ifdef CONFIG_PREEMPT_RT_BASE
> -
> static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
>
> +#ifdef CONFIG_PREEMPT_RT_BASE
> static void hrtimer_rt_reprogram(int restart, struct hrtimer *timer,
>  struct hrtimer_clock_base *base)
> {
> Index: linux-2.6/localversion-rt
> ===================================================================
> --- linux-2.6.orig/localversion-rt
> +++ linux-2.6/localversion-rt
> @@ -1 +1 @@
> --rt4
> +-rt6
> Index: linux-2.6/kernel/time/clocksource.c
> ===================================================================
> --- linux-2.6.orig/kernel/time/clocksource.c
> +++ linux-2.6/kernel/time/clocksource.c
> @@ -186,6 +186,7 @@ static struct timer_list watchdog_timer;
> static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
> static DEFINE_SPINLOCK(watchdog_lock);
> static int watchdog_running;
> +static atomic_t watchdog_reset_pending;
>
> static int clocksource_watchdog_kthread(void *data);
> static void __clocksource_change_rating(struct clocksource *cs, int 
> rating);
> @@ -247,12 +248,14 @@ static void clocksource_watchdog(unsigne
>  struct clocksource *cs;
>  cycle_t csnow, wdnow;
>  int64_t wd_nsec, cs_nsec;
> - int next_cpu;
> + int next_cpu, reset_pending;
>
>  spin_lock(&watchdog_lock);
>  if (!watchdog_running)
>  goto out;
>
> + reset_pending = atomic_read(&watchdog_reset_pending);
> +
>  list_for_each_entry(cs, &watchdog_list, wd_list) {
>
>  /* Clocksource already marked unstable? */
> @@ -268,7 +271,8 @@ static void clocksource_watchdog(unsigne
>  local_irq_enable();
>
>  /* Clocksource initialized ? */
> - if (!(cs->flags & CLOCK_SOURCE_WATCHDOG)) {
> + if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
> +     atomic_read(&watchdog_reset_pending)) {
>  cs->flags |= CLOCK_SOURCE_WATCHDOG;
>  cs->wd_last = wdnow;
>  cs->cs_last = csnow;
> @@ -283,8 +287,11 @@ static void clocksource_watchdog(unsigne
>  cs->cs_last = csnow;
>  cs->wd_last = wdnow;
>
> + if (atomic_read(&watchdog_reset_pending))
> + continue;
> +
>  /* Check the deviation from the watchdog clocksource. */
> - if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) {
> + if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
>  clocksource_unstable(cs, cs_nsec - wd_nsec);
>  continue;
>  }
> @@ -303,6 +310,13 @@ static void clocksource_watchdog(unsigne
>  }
>
>  /*
> + * We only clear the watchdog_reset_pending, when we did a
> + * full cycle through all clocksources.
> + */
> + if (reset_pending)
> + atomic_dec(&watchdog_reset_pending);
> +
> + /*
>  * Cycle through CPUs to check if the CPUs stay synchronized
>  * to each other.
>  */
> @@ -344,23 +358,7 @@ static inline void clocksource_reset_wat
>
> static void clocksource_resume_watchdog(void)
> {
> - unsigned long flags;
> -
> - /*
> - * We use trylock here to avoid a potential dead lock when
> - * kgdb calls this code after the kernel has been stopped with
> - * watchdog_lock held. When watchdog_lock is held we just
> - * return and accept, that the watchdog might trigger and mark
> - * the monitored clock source (usually TSC) unstable.
> - *
> - * This does not affect the other caller clocksource_resume()
> - * because at this point the kernel is UP, interrupts are
> - * disabled and nothing can hold watchdog_lock.
> - */
> - if (!spin_trylock_irqsave(&watchdog_lock, flags))
> - return;
> - clocksource_reset_watchdog();
> - spin_unlock_irqrestore(&watchdog_lock, flags);
> + atomic_inc(&watchdog_reset_pending);
> }
>
> static void clocksource_enqueue_watchdog(struct clocksource *cs)
> Index: linux-2.6/drivers/tty/serial/omap-serial.c
> ===================================================================
> --- linux-2.6.orig/drivers/tty/serial/omap-serial.c
> +++ linux-2.6/drivers/tty/serial/omap-serial.c
> @@ -947,13 +947,12 @@ serial_omap_console_write(struct console
>  unsigned int ier;
>  int locked = 1;
>
> - local_irq_save(flags);
>  if (up->port.sysrq)
>  locked = 0;
>  else if (oops_in_progress)
> - locked = spin_trylock(&up->port.lock);
> + locked = spin_trylock_irqsave(&up->port.lock, flags);
>  else
> - spin_lock(&up->port.lock);
> + spin_lock_irqsave(&up->port.lock, flags);
>
>  /*
>  * First save the IER then disable the interrupts
> @@ -980,8 +979,7 @@ serial_omap_console_write(struct console
>  check_modem_status(up);
>
>  if (locked)
> - spin_unlock(&up->port.lock);
> - local_irq_restore(flags);
> + spin_unlock_irqrestore(&up->port.lock, flags);
> }
>
> static int __init
> Index: linux-2.6/include/linux/kdb.h
> ===================================================================
> --- linux-2.6.orig/include/linux/kdb.h
> +++ linux-2.6/include/linux/kdb.h
> @@ -153,12 +153,14 @@ extern int kdb_register(char *, kdb_func
> extern int kdb_register_repeat(char *, kdb_func_t, char *, char *,
>         short, kdb_repeat_t);
> extern int kdb_unregister(char *);
> +#define in_kdb_printk() (kdb_trap_printk)
> #else /* ! CONFIG_KGDB_KDB */
> #define kdb_printf(...)
> #define kdb_init(x)
> #define kdb_register(...)
> #define kdb_register_repeat(...)
> #define kdb_uregister(x)
> +#define in_kdb_printk() (0)
> #endif /* CONFIG_KGDB_KDB */
> enum {
>  KDB_NOT_INITIALIZED,
> Index: linux-2.6/kernel/debug/kdb/kdb_io.c
> ===================================================================
> --- linux-2.6.orig/kernel/debug/kdb/kdb_io.c
> +++ linux-2.6/kernel/debug/kdb/kdb_io.c
> @@ -539,7 +539,6 @@ int vkdb_printf(const char *fmt, va_list
>  int diag;
>  int linecount;
>  int logging, saved_loglevel = 0;
> - int saved_trap_printk;
>  int got_printf_lock = 0;
>  int retlen = 0;
>  int fnd, len;
> @@ -550,8 +549,6 @@ int vkdb_printf(const char *fmt, va_list
>  unsigned long uninitialized_var(flags);
>
>  preempt_disable();
> - saved_trap_printk = kdb_trap_printk;
> - kdb_trap_printk = 0;
>
>  /* Serialize kdb_printf if multiple cpus try to write at once.
>  * But if any cpu goes recursive in kdb, just print the output,
> @@ -807,7 +804,6 @@ kdb_print_out:
>  } else {
>  __release(kdb_printf_lock);
>  }
> - kdb_trap_printk = saved_trap_printk;
>  preempt_enable();
>  return retlen;
> }
> @@ -817,9 +813,11 @@ int kdb_printf(const char *fmt, ...)
>  va_list ap;
>  int r;
>
> + kdb_trap_printk++;
>  va_start(ap, fmt);
>  r = vkdb_printf(fmt, ap);
>  va_end(ap);
> + kdb_trap_printk--;
>
>  return r;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

incredible RT team, months without any update and now everyday an update.... 
great !!! :D 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
  2011-07-28 22:33 ` Madovsky
@ 2011-07-28 23:33 ` Peter W. Morreale
  2011-07-29  0:56   ` Thomas Gleixner
  2011-07-29  6:05 ` Mike Galbraith
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 29+ messages in thread
From: Peter W. Morreale @ 2011-07-28 23:33 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

On Thu, 2011-07-28 at 23:43 +0200, Thomas Gleixner wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.0-rt6 release.
> 
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
> 
>   * pin_cpu fix (Yong Zhang)
> 
>   * Various compile fixes (Yong Zhang & myself)
> 
>   * Serial fix for omap
> 
>   * Clocksource lockless watchdog reset
> 
>   * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>     related to NO_HZ, which is still disabled. Paul is working on it!)
> 
>   * KGDB work^Whackaround (Jason Wessel)
> 
>     The kgdb workaround is really a hack and wants to be replaced by a
>     proper overhaul for the console/tty maze.
>     See: kgb-serial-hackaround.patch
> 
> As I said yesterday, I'm preparing for vanishing from the net. 
> 
> Please keep on testing and sending patches. Peter Zijlstra kindly
> volunteered to cover for me. He'll pick up stuff and eventually push
> out releases when a reasonable number of sane patches hits his inbox.
> 
> If you reply to that mail, please keep the Cc list intact to make sure
> that all interested folks see it. It does not matter whether you are
> subscribed to a particular mailing list or not. Just keep your fingers
> away from the Cc list unless you have a very good reason to do
> so. Hint for GUI mail "client" users: Hit "Reply to all" ....
> 
> For all those who are addicted to roadmaps, here is the roadmap I'm
> caring about for the next two weeks:
> 
>   http://maps.google.com/maps?q=Fuchsenloch,+Schlier&hl=en&z=16
> 
> For the curious: Fuchsenloch == Fox hole. IOW: The place where fox and
> rabbit say Good Night to each other.
> 
> And for those who care about estimates, here are my momentary
> favourite Dilberts on this topic:
> 
>    http://dilbert.com/strips/comic/1995-11-10/
>    http://dilbert.com/strips/comic/2010-05-05/
> 
> Patch against 3.0 can be found here:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt6.patch.bz2
> 
> The split quilt queue is available at:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt6.tar.bz2
> 

Hummm this url doesn't seem to work, looking at the dir, I only see
patches-3.0-rt6.tar.bz2.sign 


script issue?

Best,
-PWM


> Delta patch against 3.0-rt4 below.
> 
> Thanks,
> 
> 	tglx
> ----
>  arch/arm/include/asm/mmu.h       |    2 +-
>  drivers/tty/serial/8250.c        |   13 +++++++++----
>  drivers/tty/serial/omap-serial.c |    8 +++-----
>  include/linux/kdb.h              |    2 ++
>  init/Kconfig                     |    2 +-
>  kernel/cpu.c                     |    4 +++-
>  kernel/debug/kdb/kdb_io.c        |    6 ++----
>  kernel/hrtimer.c                 |    4 +---
>  kernel/time/clocksource.c        |   38 ++++++++++++++++++--------------------
>  localversion-rt                  |    2 +-
>  10 files changed, 41 insertions(+), 40 deletions(-)
> 
> Index: linux-2.6/arch/arm/include/asm/mmu.h
> ===================================================================
> --- linux-2.6.orig/arch/arm/include/asm/mmu.h
> +++ linux-2.6/arch/arm/include/asm/mmu.h
> @@ -16,7 +16,7 @@ typedef struct {
>  
>  /* init_mm.context.id_lock should be initialized. */
>  #define INIT_MM_CONTEXT(name)                                                 \
> -	.context.id_lock    = __SPIN_LOCK_UNLOCKED(name.context.id_lock),
> +	.context.id_lock    = __RAW_SPIN_LOCK_UNLOCKED(name.context.id_lock),
>  #else
>  #define ASID(mm)	(0)
>  #endif
> Index: linux-2.6/drivers/tty/serial/8250.c
> ===================================================================
> --- linux-2.6.orig/drivers/tty/serial/8250.c
> +++ linux-2.6/drivers/tty/serial/8250.c
> @@ -38,6 +38,7 @@
>  #include <linux/nmi.h>
>  #include <linux/mutex.h>
>  #include <linux/slab.h>
> +#include <linux/kdb.h>
>  
>  #include <asm/io.h>
>  #include <asm/irq.h>
> @@ -2894,10 +2895,14 @@ serial8250_console_write(struct console 
>  
>  	touch_nmi_watchdog();
>  
> -	if (up->port.sysrq || oops_in_progress)
> -		locked = spin_trylock_irqsave(&up->port.lock, flags);
> -	else
> -		spin_lock_irqsave(&up->port.lock, flags);
> +	if (unlikely(in_kdb_printk())) {
> +		locked = 0;
> +	} else {
> +		if (up->port.sysrq || oops_in_progress)
> +			locked = spin_trylock_irqsave(&up->port.lock, flags);
> +		else
> +			spin_lock_irqsave(&up->port.lock, flags);
> +	}
>  
>  	/*
>  	 *	First save the IER then disable the interrupts
> Index: linux-2.6/init/Kconfig
> ===================================================================
> --- linux-2.6.orig/init/Kconfig
> +++ linux-2.6/init/Kconfig
> @@ -493,7 +493,7 @@ config TREE_RCU_TRACE
>  
>  config RCU_BOOST
>  	bool "Enable RCU priority boosting"
> -	depends on RT_MUTEXES && PREEMPT_RCU && !RT_PREEMPT_FULL
> +	depends on RT_MUTEXES && PREEMPT_RCU
>  	default n
>  	help
>  	  This option boosts the priority of preempted RCU readers that
> Index: linux-2.6/kernel/cpu.c
> ===================================================================
> --- linux-2.6.orig/kernel/cpu.c
> +++ linux-2.6/kernel/cpu.c
> @@ -75,9 +75,11 @@ static DEFINE_PER_CPU(struct hotplug_pcp
>   */
>  void pin_current_cpu(void)
>  {
> -	struct hotplug_pcp *hp = &__get_cpu_var(hotplug_pcp);
> +	struct hotplug_pcp *hp;
>  
>  retry:
> +	hp = &__get_cpu_var(hotplug_pcp);
> +
>  	if (!hp->unplug || hp->refcount || preempt_count() > 1 ||
>  	    hp->unplug == current || (current->flags & PF_STOMPER)) {
>  		hp->refcount++;
> Index: linux-2.6/kernel/hrtimer.c
> ===================================================================
> --- linux-2.6.orig/kernel/hrtimer.c
> +++ linux-2.6/kernel/hrtimer.c
> @@ -1294,11 +1294,9 @@ static void __run_hrtimer(struct hrtimer
>  	timer->state &= ~HRTIMER_STATE_CALLBACK;
>  }
>  
> -
> -#ifdef CONFIG_PREEMPT_RT_BASE
> -
>  static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
>  
> +#ifdef CONFIG_PREEMPT_RT_BASE
>  static void hrtimer_rt_reprogram(int restart, struct hrtimer *timer,
>  				 struct hrtimer_clock_base *base)
>  {
> Index: linux-2.6/localversion-rt
> ===================================================================
> --- linux-2.6.orig/localversion-rt
> +++ linux-2.6/localversion-rt
> @@ -1 +1 @@
> --rt4
> +-rt6
> Index: linux-2.6/kernel/time/clocksource.c
> ===================================================================
> --- linux-2.6.orig/kernel/time/clocksource.c
> +++ linux-2.6/kernel/time/clocksource.c
> @@ -186,6 +186,7 @@ static struct timer_list watchdog_timer;
>  static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
>  static DEFINE_SPINLOCK(watchdog_lock);
>  static int watchdog_running;
> +static atomic_t watchdog_reset_pending;
>  
>  static int clocksource_watchdog_kthread(void *data);
>  static void __clocksource_change_rating(struct clocksource *cs, int rating);
> @@ -247,12 +248,14 @@ static void clocksource_watchdog(unsigne
>  	struct clocksource *cs;
>  	cycle_t csnow, wdnow;
>  	int64_t wd_nsec, cs_nsec;
> -	int next_cpu;
> +	int next_cpu, reset_pending;
>  
>  	spin_lock(&watchdog_lock);
>  	if (!watchdog_running)
>  		goto out;
>  
> +	reset_pending = atomic_read(&watchdog_reset_pending);
> +
>  	list_for_each_entry(cs, &watchdog_list, wd_list) {
>  
>  		/* Clocksource already marked unstable? */
> @@ -268,7 +271,8 @@ static void clocksource_watchdog(unsigne
>  		local_irq_enable();
>  
>  		/* Clocksource initialized ? */
> -		if (!(cs->flags & CLOCK_SOURCE_WATCHDOG)) {
> +		if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
> +		    atomic_read(&watchdog_reset_pending)) {
>  			cs->flags |= CLOCK_SOURCE_WATCHDOG;
>  			cs->wd_last = wdnow;
>  			cs->cs_last = csnow;
> @@ -283,8 +287,11 @@ static void clocksource_watchdog(unsigne
>  		cs->cs_last = csnow;
>  		cs->wd_last = wdnow;
>  
> +		if (atomic_read(&watchdog_reset_pending))
> +			continue;
> +
>  		/* Check the deviation from the watchdog clocksource. */
> -		if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) {
> +		if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
>  			clocksource_unstable(cs, cs_nsec - wd_nsec);
>  			continue;
>  		}
> @@ -303,6 +310,13 @@ static void clocksource_watchdog(unsigne
>  	}
>  
>  	/*
> +	 * We only clear the watchdog_reset_pending, when we did a
> +	 * full cycle through all clocksources.
> +	 */
> +	if (reset_pending)
> +		atomic_dec(&watchdog_reset_pending);
> +
> +	/*
>  	 * Cycle through CPUs to check if the CPUs stay synchronized
>  	 * to each other.
>  	 */
> @@ -344,23 +358,7 @@ static inline void clocksource_reset_wat
>  
>  static void clocksource_resume_watchdog(void)
>  {
> -	unsigned long flags;
> -
> -	/*
> -	 * We use trylock here to avoid a potential dead lock when
> -	 * kgdb calls this code after the kernel has been stopped with
> -	 * watchdog_lock held. When watchdog_lock is held we just
> -	 * return and accept, that the watchdog might trigger and mark
> -	 * the monitored clock source (usually TSC) unstable.
> -	 *
> -	 * This does not affect the other caller clocksource_resume()
> -	 * because at this point the kernel is UP, interrupts are
> -	 * disabled and nothing can hold watchdog_lock.
> -	 */
> -	if (!spin_trylock_irqsave(&watchdog_lock, flags))
> -		return;
> -	clocksource_reset_watchdog();
> -	spin_unlock_irqrestore(&watchdog_lock, flags);
> +	atomic_inc(&watchdog_reset_pending);
>  }
>  
>  static void clocksource_enqueue_watchdog(struct clocksource *cs)
> Index: linux-2.6/drivers/tty/serial/omap-serial.c
> ===================================================================
> --- linux-2.6.orig/drivers/tty/serial/omap-serial.c
> +++ linux-2.6/drivers/tty/serial/omap-serial.c
> @@ -947,13 +947,12 @@ serial_omap_console_write(struct console
>  	unsigned int ier;
>  	int locked = 1;
>  
> -	local_irq_save(flags);
>  	if (up->port.sysrq)
>  		locked = 0;
>  	else if (oops_in_progress)
> -		locked = spin_trylock(&up->port.lock);
> +		locked = spin_trylock_irqsave(&up->port.lock, flags);
>  	else
> -		spin_lock(&up->port.lock);
> +		spin_lock_irqsave(&up->port.lock, flags);
>  
>  	/*
>  	 * First save the IER then disable the interrupts
> @@ -980,8 +979,7 @@ serial_omap_console_write(struct console
>  		check_modem_status(up);
>  
>  	if (locked)
> -		spin_unlock(&up->port.lock);
> -	local_irq_restore(flags);
> +		spin_unlock_irqrestore(&up->port.lock, flags);
>  }
>  
>  static int __init
> Index: linux-2.6/include/linux/kdb.h
> ===================================================================
> --- linux-2.6.orig/include/linux/kdb.h
> +++ linux-2.6/include/linux/kdb.h
> @@ -153,12 +153,14 @@ extern int kdb_register(char *, kdb_func
>  extern int kdb_register_repeat(char *, kdb_func_t, char *, char *,
>  			       short, kdb_repeat_t);
>  extern int kdb_unregister(char *);
> +#define in_kdb_printk() (kdb_trap_printk)
>  #else /* ! CONFIG_KGDB_KDB */
>  #define kdb_printf(...)
>  #define kdb_init(x)
>  #define kdb_register(...)
>  #define kdb_register_repeat(...)
>  #define kdb_uregister(x)
> +#define in_kdb_printk() (0)
>  #endif	/* CONFIG_KGDB_KDB */
>  enum {
>  	KDB_NOT_INITIALIZED,
> Index: linux-2.6/kernel/debug/kdb/kdb_io.c
> ===================================================================
> --- linux-2.6.orig/kernel/debug/kdb/kdb_io.c
> +++ linux-2.6/kernel/debug/kdb/kdb_io.c
> @@ -539,7 +539,6 @@ int vkdb_printf(const char *fmt, va_list
>  	int diag;
>  	int linecount;
>  	int logging, saved_loglevel = 0;
> -	int saved_trap_printk;
>  	int got_printf_lock = 0;
>  	int retlen = 0;
>  	int fnd, len;
> @@ -550,8 +549,6 @@ int vkdb_printf(const char *fmt, va_list
>  	unsigned long uninitialized_var(flags);
>  
>  	preempt_disable();
> -	saved_trap_printk = kdb_trap_printk;
> -	kdb_trap_printk = 0;
>  
>  	/* Serialize kdb_printf if multiple cpus try to write at once.
>  	 * But if any cpu goes recursive in kdb, just print the output,
> @@ -807,7 +804,6 @@ kdb_print_out:
>  	} else {
>  		__release(kdb_printf_lock);
>  	}
> -	kdb_trap_printk = saved_trap_printk;
>  	preempt_enable();
>  	return retlen;
>  }
> @@ -817,9 +813,11 @@ int kdb_printf(const char *fmt, ...)
>  	va_list ap;
>  	int r;
>  
> +	kdb_trap_printk++;
>  	va_start(ap, fmt);
>  	r = vkdb_printf(fmt, ap);
>  	va_end(ap);
> +	kdb_trap_printk--;
>  
>  	return r;
>  }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 23:33 ` Peter W. Morreale
@ 2011-07-29  0:56   ` Thomas Gleixner
  0 siblings, 0 replies; 29+ messages in thread
From: Thomas Gleixner @ 2011-07-29  0:56 UTC (permalink / raw)
  To: Peter W. Morreale; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

On Thu, 28 Jul 2011, Peter W. Morreale wrote:
> On Thu, 2011-07-28 at 23:43 +0200, Thomas Gleixner wrote:
> > The split quilt queue is available at:
> > 
> >   http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt6.tar.bz2
> > 
> 
> Hummm this url doesn't seem to work, looking at the dir, I only see
> patches-3.0-rt6.tar.bz2.sign 
> 
> 
> script issue?

Nope. Pilot error. Should be fixed when the mirrors have synced in a
few minutes.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
  2011-07-28 22:33 ` Madovsky
  2011-07-28 23:33 ` Peter W. Morreale
@ 2011-07-29  6:05 ` Mike Galbraith
  2011-07-29 14:03 ` Paul E. McKenney
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 29+ messages in thread
From: Mike Galbraith @ 2011-07-29  6:05 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

FYI, I took rt6 for a very brief ride on a 64 core DL980 this morning.
Didn't have time to play with it, was just taking a peek at rt future,
so this is only an fyi (vs proper bug report with circles and arrows),
and probably not a very useful one.

After boot (bloated distro config), ksoftirqd was eating ~20% on all
CPUs, and the guy below was at 100%.  While watching, box started
spewing this endlessly, with the same trace shown for all CPUs.

I'll poke it with sharp sticks when I have time (dream on) to tinker,
but the bug will likely have died of old age before then.

I booted the box with intel_idle.max_cstate=1 fwtw. 
 
[  338.747588] NMI backtrace for cpu 63
[  338.747590] CPU 63 
[  338.747591] Modules linked in: autofs4 edd nfs lockd fscache auth_rpcgss nfs_acl sunrpc af_packet mperf loop dm_mod sr_mod iTCO_wdt shpchp joydev serio_raw cdrom i7core_edac iTCO_vendor_support bnx2 pci_hotplug hpwdt pcspkr hpilo sg edac_core netxen_nic container acpi_power_meter button usbhid radeon uhci_hcd ttm drm_kms_helper drm ehci_hcd usbcore i2c_algo_bit fan thermal processor thermal_sys ata_generic hpsa
[  338.747608] 
[  338.747610] Pid: 0, comm: kworker/0:1 Not tainted 3.0.0-rt6 #3 Hewlett-Packard ProLiant DL980 G7
[  338.747613] RIP: 0010:[<ffffffff8147f596>]  [<ffffffff8147f596>] _raw_spin_lock_irqsave+0x36/0x40
[  338.747619] RSP: 0018:ffff88027f5e3ea0  EFLAGS: 00000093
[  338.747620] RAX: 000000000000ca7f RBX: ffff880274ccc080 RCX: 000000000000ca68
[  338.747622] RDX: 0000000000000013 RSI: 000000000000003f RDI: ffff880274ccc0f8
[  338.747624] RBP: 000000000000003f R08: 0000000000000001 R09: 00000000000017d6
[  338.747626] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
[  338.747628] R13: ffff880274ccc0f8 R14: 0000000000000001 R15: 000000000000043f
[  338.747630] FS:  0000000000000000(0000) GS:ffff88027f5e0000(0000) knlGS:0000000000000000
[  338.747632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  338.747633] CR2: 00000000006c2000 CR3: 0000000001a06000 CR4: 00000000000006e0
[  338.747635] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  338.747636] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  338.747638] Process kworker/0:1 (pid: 0, threadinfo ffff880274ca8000, task ffff880274c91790)
[  338.747639] Stack:
[  338.747640]  ffffffff810b12f6 ffff88027f5e3f48 ffff880274c57100 ffff88027f5ef540
[  338.747644]  ffff88027f5ef540 ffff88027f5ef540 0000000000000062 0000000000000000
[  338.747649]  ffffffff8103f4bc ffffffff81008e15 ffff88027f5ef540 ffff880274c57638
[  338.747653] Call Trace:
[  338.747654]  <IRQ> 
[  338.747658]  [<ffffffff810b12f6>] ? cpupri_set+0x76/0x150
[  338.747662]  [<ffffffff8103f4bc>] ? enqueue_task_rt+0x2fc/0x320
[  338.747665]  [<ffffffff81008e15>] ? sched_clock+0x5/0x10
[  338.747668]  [<ffffffff8103bf41>] ? activate_task+0x21/0x30
[  338.747672]  [<ffffffff81044ef4>] ? try_to_wake_up+0x294/0x330
[  338.747675]  [<ffffffff810524e5>] ? irq_exit+0x55/0x60
[  338.747678]  [<ffffffff8101d228>] ? smp_apic_timer_interrupt+0x68/0xa0
[  338.747681]  [<ffffffff81485873>] ? apic_timer_interrupt+0x13/0x20
[  338.747682]  <EOI> 
[  338.747685]  [<ffffffff8106dc3e>] ? __hrtimer_start_range_ns+0x13e/0x2b0
[  338.747689]  [<ffffffff81269051>] ? intel_idle+0xc1/0x120
[  338.747692]  [<ffffffff81269030>] ? intel_idle+0xa0/0x120
[  338.747695]  [<ffffffff81357961>] ? cpuidle_idle_call+0x81/0x100
[  338.747699]  [<ffffffff810011cf>] ? cpu_idle+0x4f/0x80
[  338.747702]  [<ffffffff81478877>] ? start_secondary+0x22c/0x231
[  338.747704] Code: 66 66 90 66 66 90 65 48 8b 04 25 c8 95 00 00 83 80 44 e0 ff ff 01 b8 00 00 01 00 f0 0f c1 07 0f b7 c8 c1 e8 10 39 c1 74 07 f3 90 <0f> b7 0f eb f5 48 89 d0 c3 90 fa 66 66 90 66 66 90 65 48 8b 04 
[  338.747717] Call Trace:
[  338.747718]  <IRQ>  [<ffffffff810b12f6>] ? cpupri_set+0x76/0x150
[  338.747723]  [<ffffffff8103f4bc>] ? enqueue_task_rt+0x2fc/0x320
[  338.747726]  [<ffffffff81008e15>] ? sched_clock+0x5/0x10
[  338.747729]  [<ffffffff8103bf41>] ? activate_task+0x21/0x30
[  338.747732]  [<ffffffff81044ef4>] ? try_to_wake_up+0x294/0x330
[  338.747735]  [<ffffffff810524e5>] ? irq_exit+0x55/0x60
[  338.747737]  [<ffffffff8101d228>] ? smp_apic_timer_interrupt+0x68/0xa0
[  338.747740]  [<ffffffff81485873>] ? apic_timer_interrupt+0x13/0x20
[  338.747742]  <EOI>  [<ffffffff8106dc3e>] ? __hrtimer_start_range_ns+0x13e/0x2b0
[  338.747747]  [<ffffffff81269051>] ? intel_idle+0xc1/0x120
[  338.747750]  [<ffffffff81269030>] ? intel_idle+0xa0/0x120
[  338.747753]  [<ffffffff81357961>] ? cpuidle_idle_call+0x81/0x100
[  338.747756]  [<ffffffff810011cf>] ? cpu_idle+0x4f/0x80
[  338.747759]  [<ffffffff81478877>] ? start_secondary+0x22c/0x231



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
                   ` (2 preceding siblings ...)
  2011-07-29  6:05 ` Mike Galbraith
@ 2011-07-29 14:03 ` Paul E. McKenney
  2011-07-29 15:57 ` [ANNOUNCE] 3.0-rt6 (kgdb working) Darren Hart
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 29+ messages in thread
From: Paul E. McKenney @ 2011-07-29 14:03 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra

On Thu, Jul 28, 2011 at 11:43:16PM +0200, Thomas Gleixner wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.0-rt6 release.
> 
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
> 
>   * pin_cpu fix (Yong Zhang)
> 
>   * Various compile fixes (Yong Zhang & myself)
> 
>   * Serial fix for omap
> 
>   * Clocksource lockless watchdog reset
> 
>   * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>     related to NO_HZ, which is still disabled. Paul is working on it!)

Once I remembered to fill in the CONFIG_INITRAMFS_SOURCE kernel parameter,
-rt6 booted just fine with CONFIG_RCU_BOOST=y and CONFIG_NO_HZ=y.
(Before that, the init process was whining bitterly about life in
general and segmentation faults in particular.)  There are dyntick-idle
periods happening, as can be seen from the first one-third of debugfs's
rcu/rcudata file:

rcu_preempt:
  0 c=225221 g=225222 pq=1 pqc=225221 qp=1 dt=7363/1/0 df=387 of=0 ri=0 ql=2 qs=..W. kt=0/W/0 ktl=96cc b=10 ci=2148054 co=0 ca=0
  1 c=225221 g=225222 pq=1 pqc=225221 qp=1 dt=11677/1/0 df=1381 of=0 ri=0 ql=0 qs=.... kt=0/W/1 ktl=ba97 b=10 ci=1089926 co=0 ca=0

The dt= fields count the number of times the corresponding CPU has
transitioned to and from dyntick-idle mode.  There is also some RCU
priority boosting happening:

0:7 tasks=TN.. kt=W ntb=3 neb=0 nnb=3 j=1182 bt=12fc
     balk: nt=0 egt=1750 bt=37 nb=2 ny=311044 nos=0

The ntb= field tells us that there have been three priority-boost events,
and nnb= tells us that they have all been for normal (as opposed to
expedited) grace periods.  You need CONFIG_RCU_TRACE=y to enable these,
in case you want to see them yourself.

This has survived 45 minutes of rcutorture thus far.

It might well be that a two-CPU 32-bit x86 environment is especially
kind to -rt, but I nevertheless propose the following patch.

							Thanx, Paul

------------------------------------------------------------------------

nohz: Enable CONFIG_NO_HZ in -rt kernel builds

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---

 Kconfig |    1 -
 1 file changed, 1 deletion(-)

diff -urpNa -X dontdiff linux-3.0-rt5/kernel/time/Kconfig linux-3.0-rt6/kernel/time/Kconfig
--- linux-3.0-rt5/kernel/time/Kconfig	2011-07-28 15:47:04.000000000 -0700
+++ linux-3.0-rt6/kernel/time/Kconfig	2011-07-29 04:31:06.000000000 -0700
@@ -7,7 +7,6 @@ config TICK_ONESHOT
 config NO_HZ
 	bool "Tickless System (Dynamic Ticks)"
 	depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
-	depends on !PREEMPT_RT_FULL
 	select TICK_ONESHOT
 	help
 	  This option enables a tickless system: timer interrupts will

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6 (kgdb working)
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
                   ` (3 preceding siblings ...)
  2011-07-29 14:03 ` Paul E. McKenney
@ 2011-07-29 15:57 ` Darren Hart
  2011-07-30 15:49   ` Remy Bohmer
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 29+ messages in thread
From: Darren Hart @ 2011-07-29 15:57 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney, Jason Wessel



On 07/28/2011 02:43 PM, Thomas Gleixner wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.0-rt6 release.
> 
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
> 
>   * pin_cpu fix (Yong Zhang)
> 
>   * Various compile fixes (Yong Zhang & myself)
> 
>   * Serial fix for omap
> 
>   * Clocksource lockless watchdog reset
> 
>   * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>     related to NO_HZ, which is still disabled. Paul is working on it!)
> 
>   * KGDB work^Whackaround (Jason Wessel)
> 
>     The kgdb workaround is really a hack and wants to be replaced by a
>     proper overhaul for the console/tty maze.
>     See: kgb-serial-hackaround.patch

I just confirmed that this resolves the issue I was seeing while trying
to single step through futex_requeue() on a 2 socket E5680.

Thanks Thomas and Jason,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
@ 2011-07-30 15:49   ` Remy Bohmer
  2011-07-28 23:33 ` Peter W. Morreale
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 29+ messages in thread
From: Remy Bohmer @ 2011-07-30 15:49 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

Hi,

2011/7/28 Thomas Gleixner <tglx@linutronix.de>:
> Dear RT Folks,
>
> I'm pleased to announce the 3.0-rt6 release.
>
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
>
>  * pin_cpu fix (Yong Zhang)
>
>  * Various compile fixes (Yong Zhang & myself)
>
>  * Serial fix for omap
>
>  * Clocksource lockless watchdog reset
>
>  * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>    related to NO_HZ, which is still disabled. Paul is working on it!)
>
>  * KGDB work^Whackaround (Jason Wessel)
>
>    The kgdb workaround is really a hack and wants to be replaced by a
>    proper overhaul for the console/tty maze.
>    See: kgb-serial-hackaround.patch
>
> As I said yesterday, I'm preparing for vanishing from the net.
>
> Please keep on testing and sending patches. Peter Zijlstra kindly
> volunteered to cover for me. He'll pick up stuff and eventually push
> out releases when a reasonable number of sane patches hits his inbox.

I got rt5 booting yesterday on a ARM core (Atmel AT91):
* LCD driver broken, booting stops during initialising driver (seems
to be broken in mainstream too)
* Strange issue with finding files in a directory. (currently checking
if it is RT-patch related.)
* Furthermore, the board feels slow... Can be perception only, need to
check it out...
* The patch (http://www.spinics.net/lists/arm-kernel/msg45022.html)
that solved the problem at https://lkml.org/lkml/2007/11/26/73 is no
longer part of the RT-patch. I Need to test if it is still needed...

Kind regards,

Remy

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
@ 2011-07-30 15:49   ` Remy Bohmer
  0 siblings, 0 replies; 29+ messages in thread
From: Remy Bohmer @ 2011-07-30 15:49 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

Hi,

2011/7/28 Thomas Gleixner <tglx@linutronix.de>:
> Dear RT Folks,
>
> I'm pleased to announce the 3.0-rt6 release.
>
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
>
>  * pin_cpu fix (Yong Zhang)
>
>  * Various compile fixes (Yong Zhang & myself)
>
>  * Serial fix for omap
>
>  * Clocksource lockless watchdog reset
>
>  * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>    related to NO_HZ, which is still disabled. Paul is working on it!)
>
>  * KGDB work^Whackaround (Jason Wessel)
>
>    The kgdb workaround is really a hack and wants to be replaced by a
>    proper overhaul for the console/tty maze.
>    See: kgb-serial-hackaround.patch
>
> As I said yesterday, I'm preparing for vanishing from the net.
>
> Please keep on testing and sending patches. Peter Zijlstra kindly
> volunteered to cover for me. He'll pick up stuff and eventually push
> out releases when a reasonable number of sane patches hits his inbox.

I got rt5 booting yesterday on a ARM core (Atmel AT91):
* LCD driver broken, booting stops during initialising driver (seems
to be broken in mainstream too)
* Strange issue with finding files in a directory. (currently checking
if it is RT-patch related.)
* Furthermore, the board feels slow... Can be perception only, need to
check it out...
* The patch (http://www.spinics.net/lists/arm-kernel/msg45022.html)
that solved the problem at https://lkml.org/lkml/2007/11/26/73 is no
longer part of the RT-patch. I Need to test if it is still needed...

Kind regards,

Remy
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-30 15:49   ` Remy Bohmer
  (?)
@ 2011-07-30 20:21   ` Remy Bohmer
  2011-08-07 10:44     ` Remy Bohmer
  -1 siblings, 1 reply; 29+ messages in thread
From: Remy Bohmer @ 2011-07-30 20:21 UTC (permalink / raw)
  To: Thomas Gleixner, Peter Zijlstra; +Cc: LKML, linux-rt-users, Paul E. McKenney

Hi,

2011/7/30 Remy Bohmer <linux@bohmer.net>:
>> Please keep on testing and sending patches. Peter Zijlstra kindly
>> volunteered to cover for me. He'll pick up stuff and eventually push
>> out releases when a reasonable number of sane patches hits his inbox.
>
> I got rt5 booting yesterday on a ARM core (Atmel AT91):
> * LCD driver broken, booting stops during initialising driver (seems
> to be broken in mainstream too)

Still need to debug this one.

> * Strange issue with finding files in a directory. (currently checking
> if it is RT-patch related.)

It seems that the busybox (v1.17.1) mount for loopback devices is
broken on linux-3.0. The util-linux-ng mount still works.
This is NOT a RT-patch issue.

> * Furthermore, the board feels slow... Can be perception only, need to
> check it out...

This seems to be caused by the fact that the IRQ-thread of the
ttyS0/dbgu usart is running in thread context now.
Previously it was shared with the timer interrupt and as such running
in hard-irq context. It therefor felt faster.
The debug usart now frequently misses some characters, since it only
has a 1 byte 'fifo' and the interrupt handler thread cannot keep up
with the 115200 baudrate on this board. (at91sam9261ek). The
atmel-serial driver needs an update to use threaded interrupts, and
read the fifo in hard-irq context. Maybe I pick this one up as well.

> * The patch (http://www.spinics.net/lists/arm-kernel/msg45022.html)
> that solved the problem at https://lkml.org/lkml/2007/11/26/73 is no
> longer part of the RT-patch. I Need to test if it is still needed...

Not tested yet.

Furthermore, I built a patch to add a sched_clock implementation for
the TC-based clocksource driver since the default jiffies based
sched_clock stopped running for some reason during boot. (jiffies do
not seem to be properly updated)
This patch conflicts with the RT-patch since the RT-patch touches the
same files. Should it go to mainline directly, or go via the RT-tree
first? (I will post the patch tomorrow)

Kind regards,

Remy

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
                   ` (5 preceding siblings ...)
  2011-07-30 15:49   ` Remy Bohmer
@ 2011-08-01  8:42 ` Rolando Martins
  2011-08-01 10:34   ` Mike Galbraith
  2011-08-01 11:06   ` Peter Zijlstra
  2011-08-04  6:34 ` Fernando Lopez-Lezcano
  2011-08-04 16:34   ` Tim Sander
  8 siblings, 2 replies; 29+ messages in thread
From: Rolando Martins @ 2011-08-01  8:42 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

Hi Peter,
is there any progress on the CONFIG_RT_GROUP_SCHED front?
I don't know if this is related, but in 33-rt if I used a low (=100)
cpu_runtime_us and cpu_period_us then I would get some freezes
(something that does not happen in 2.6.39).

Thanks,
Rolando


On Thu, Jul 28, 2011 at 10:43 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.0-rt6 release.
>
> Changes versus 3.0-rt4 (I pushed out a rt5 w/o announce)
>
>  * pin_cpu fix (Yong Zhang)
>
>  * Various compile fixes (Yong Zhang & myself)
>
>  * Serial fix for omap
>
>  * Clocksource lockless watchdog reset
>
>  * Reenabled CONFIG_RCU_BOOST (problem is unreproducible and maybe
>    related to NO_HZ, which is still disabled. Paul is working on it!)
>
>  * KGDB work^Whackaround (Jason Wessel)
>
>    The kgdb workaround is really a hack and wants to be replaced by a
>    proper overhaul for the console/tty maze.
>    See: kgb-serial-hackaround.patch
>
> As I said yesterday, I'm preparing for vanishing from the net.
>
> Please keep on testing and sending patches. Peter Zijlstra kindly
> volunteered to cover for me. He'll pick up stuff and eventually push
> out releases when a reasonable number of sane patches hits his inbox.
>
> If you reply to that mail, please keep the Cc list intact to make sure
> that all interested folks see it. It does not matter whether you are
> subscribed to a particular mailing list or not. Just keep your fingers
> away from the Cc list unless you have a very good reason to do
> so. Hint for GUI mail "client" users: Hit "Reply to all" ....
>
> For all those who are addicted to roadmaps, here is the roadmap I'm
> caring about for the next two weeks:
>
>  http://maps.google.com/maps?q=Fuchsenloch,+Schlier&hl=en&z=16
>
> For the curious: Fuchsenloch == Fox hole. IOW: The place where fox and
> rabbit say Good Night to each other.
>
> And for those who care about estimates, here are my momentary
> favourite Dilberts on this topic:
>
>   http://dilbert.com/strips/comic/1995-11-10/
>   http://dilbert.com/strips/comic/2010-05-05/
>
> Patch against 3.0 can be found here:
>
>  http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt6.patch.bz2
>
> The split quilt queue is available at:
>
>  http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt6.tar.bz2
>
> Delta patch against 3.0-rt4 below.
>
> Thanks,
>
>        tglx
> ----
>  arch/arm/include/asm/mmu.h       |    2 +-
>  drivers/tty/serial/8250.c        |   13 +++++++++----
>  drivers/tty/serial/omap-serial.c |    8 +++-----
>  include/linux/kdb.h              |    2 ++
>  init/Kconfig                     |    2 +-
>  kernel/cpu.c                     |    4 +++-
>  kernel/debug/kdb/kdb_io.c        |    6 ++----
>  kernel/hrtimer.c                 |    4 +---
>  kernel/time/clocksource.c        |   38 ++++++++++++++++++--------------------
>  localversion-rt                  |    2 +-
>  10 files changed, 41 insertions(+), 40 deletions(-)
>
> Index: linux-2.6/arch/arm/include/asm/mmu.h
> ===================================================================
> --- linux-2.6.orig/arch/arm/include/asm/mmu.h
> +++ linux-2.6/arch/arm/include/asm/mmu.h
> @@ -16,7 +16,7 @@ typedef struct {
>
>  /* init_mm.context.id_lock should be initialized. */
>  #define INIT_MM_CONTEXT(name)                                                 \
> -       .context.id_lock    = __SPIN_LOCK_UNLOCKED(name.context.id_lock),
> +       .context.id_lock    = __RAW_SPIN_LOCK_UNLOCKED(name.context.id_lock),
>  #else
>  #define ASID(mm)       (0)
>  #endif
> Index: linux-2.6/drivers/tty/serial/8250.c
> ===================================================================
> --- linux-2.6.orig/drivers/tty/serial/8250.c
> +++ linux-2.6/drivers/tty/serial/8250.c
> @@ -38,6 +38,7 @@
>  #include <linux/nmi.h>
>  #include <linux/mutex.h>
>  #include <linux/slab.h>
> +#include <linux/kdb.h>
>
>  #include <asm/io.h>
>  #include <asm/irq.h>
> @@ -2894,10 +2895,14 @@ serial8250_console_write(struct console
>
>        touch_nmi_watchdog();
>
> -       if (up->port.sysrq || oops_in_progress)
> -               locked = spin_trylock_irqsave(&up->port.lock, flags);
> -       else
> -               spin_lock_irqsave(&up->port.lock, flags);
> +       if (unlikely(in_kdb_printk())) {
> +               locked = 0;
> +       } else {
> +               if (up->port.sysrq || oops_in_progress)
> +                       locked = spin_trylock_irqsave(&up->port.lock, flags);
> +               else
> +                       spin_lock_irqsave(&up->port.lock, flags);
> +       }
>
>        /*
>         *      First save the IER then disable the interrupts
> Index: linux-2.6/init/Kconfig
> ===================================================================
> --- linux-2.6.orig/init/Kconfig
> +++ linux-2.6/init/Kconfig
> @@ -493,7 +493,7 @@ config TREE_RCU_TRACE
>
>  config RCU_BOOST
>        bool "Enable RCU priority boosting"
> -       depends on RT_MUTEXES && PREEMPT_RCU && !RT_PREEMPT_FULL
> +       depends on RT_MUTEXES && PREEMPT_RCU
>        default n
>        help
>          This option boosts the priority of preempted RCU readers that
> Index: linux-2.6/kernel/cpu.c
> ===================================================================
> --- linux-2.6.orig/kernel/cpu.c
> +++ linux-2.6/kernel/cpu.c
> @@ -75,9 +75,11 @@ static DEFINE_PER_CPU(struct hotplug_pcp
>  */
>  void pin_current_cpu(void)
>  {
> -       struct hotplug_pcp *hp = &__get_cpu_var(hotplug_pcp);
> +       struct hotplug_pcp *hp;
>
>  retry:
> +       hp = &__get_cpu_var(hotplug_pcp);
> +
>        if (!hp->unplug || hp->refcount || preempt_count() > 1 ||
>            hp->unplug == current || (current->flags & PF_STOMPER)) {
>                hp->refcount++;
> Index: linux-2.6/kernel/hrtimer.c
> ===================================================================
> --- linux-2.6.orig/kernel/hrtimer.c
> +++ linux-2.6/kernel/hrtimer.c
> @@ -1294,11 +1294,9 @@ static void __run_hrtimer(struct hrtimer
>        timer->state &= ~HRTIMER_STATE_CALLBACK;
>  }
>
> -
> -#ifdef CONFIG_PREEMPT_RT_BASE
> -
>  static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
>
> +#ifdef CONFIG_PREEMPT_RT_BASE
>  static void hrtimer_rt_reprogram(int restart, struct hrtimer *timer,
>                                 struct hrtimer_clock_base *base)
>  {
> Index: linux-2.6/localversion-rt
> ===================================================================
> --- linux-2.6.orig/localversion-rt
> +++ linux-2.6/localversion-rt
> @@ -1 +1 @@
> --rt4
> +-rt6
> Index: linux-2.6/kernel/time/clocksource.c
> ===================================================================
> --- linux-2.6.orig/kernel/time/clocksource.c
> +++ linux-2.6/kernel/time/clocksource.c
> @@ -186,6 +186,7 @@ static struct timer_list watchdog_timer;
>  static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
>  static DEFINE_SPINLOCK(watchdog_lock);
>  static int watchdog_running;
> +static atomic_t watchdog_reset_pending;
>
>  static int clocksource_watchdog_kthread(void *data);
>  static void __clocksource_change_rating(struct clocksource *cs, int rating);
> @@ -247,12 +248,14 @@ static void clocksource_watchdog(unsigne
>        struct clocksource *cs;
>        cycle_t csnow, wdnow;
>        int64_t wd_nsec, cs_nsec;
> -       int next_cpu;
> +       int next_cpu, reset_pending;
>
>        spin_lock(&watchdog_lock);
>        if (!watchdog_running)
>                goto out;
>
> +       reset_pending = atomic_read(&watchdog_reset_pending);
> +
>        list_for_each_entry(cs, &watchdog_list, wd_list) {
>
>                /* Clocksource already marked unstable? */
> @@ -268,7 +271,8 @@ static void clocksource_watchdog(unsigne
>                local_irq_enable();
>
>                /* Clocksource initialized ? */
> -               if (!(cs->flags & CLOCK_SOURCE_WATCHDOG)) {
> +               if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
> +                   atomic_read(&watchdog_reset_pending)) {
>                        cs->flags |= CLOCK_SOURCE_WATCHDOG;
>                        cs->wd_last = wdnow;
>                        cs->cs_last = csnow;
> @@ -283,8 +287,11 @@ static void clocksource_watchdog(unsigne
>                cs->cs_last = csnow;
>                cs->wd_last = wdnow;
>
> +               if (atomic_read(&watchdog_reset_pending))
> +                       continue;
> +
>                /* Check the deviation from the watchdog clocksource. */
> -               if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) {
> +               if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
>                        clocksource_unstable(cs, cs_nsec - wd_nsec);
>                        continue;
>                }
> @@ -303,6 +310,13 @@ static void clocksource_watchdog(unsigne
>        }
>
>        /*
> +        * We only clear the watchdog_reset_pending, when we did a
> +        * full cycle through all clocksources.
> +        */
> +       if (reset_pending)
> +               atomic_dec(&watchdog_reset_pending);
> +
> +       /*
>         * Cycle through CPUs to check if the CPUs stay synchronized
>         * to each other.
>         */
> @@ -344,23 +358,7 @@ static inline void clocksource_reset_wat
>
>  static void clocksource_resume_watchdog(void)
>  {
> -       unsigned long flags;
> -
> -       /*
> -        * We use trylock here to avoid a potential dead lock when
> -        * kgdb calls this code after the kernel has been stopped with
> -        * watchdog_lock held. When watchdog_lock is held we just
> -        * return and accept, that the watchdog might trigger and mark
> -        * the monitored clock source (usually TSC) unstable.
> -        *
> -        * This does not affect the other caller clocksource_resume()
> -        * because at this point the kernel is UP, interrupts are
> -        * disabled and nothing can hold watchdog_lock.
> -        */
> -       if (!spin_trylock_irqsave(&watchdog_lock, flags))
> -               return;
> -       clocksource_reset_watchdog();
> -       spin_unlock_irqrestore(&watchdog_lock, flags);
> +       atomic_inc(&watchdog_reset_pending);
>  }
>
>  static void clocksource_enqueue_watchdog(struct clocksource *cs)
> Index: linux-2.6/drivers/tty/serial/omap-serial.c
> ===================================================================
> --- linux-2.6.orig/drivers/tty/serial/omap-serial.c
> +++ linux-2.6/drivers/tty/serial/omap-serial.c
> @@ -947,13 +947,12 @@ serial_omap_console_write(struct console
>        unsigned int ier;
>        int locked = 1;
>
> -       local_irq_save(flags);
>        if (up->port.sysrq)
>                locked = 0;
>        else if (oops_in_progress)
> -               locked = spin_trylock(&up->port.lock);
> +               locked = spin_trylock_irqsave(&up->port.lock, flags);
>        else
> -               spin_lock(&up->port.lock);
> +               spin_lock_irqsave(&up->port.lock, flags);
>
>        /*
>         * First save the IER then disable the interrupts
> @@ -980,8 +979,7 @@ serial_omap_console_write(struct console
>                check_modem_status(up);
>
>        if (locked)
> -               spin_unlock(&up->port.lock);
> -       local_irq_restore(flags);
> +               spin_unlock_irqrestore(&up->port.lock, flags);
>  }
>
>  static int __init
> Index: linux-2.6/include/linux/kdb.h
> ===================================================================
> --- linux-2.6.orig/include/linux/kdb.h
> +++ linux-2.6/include/linux/kdb.h
> @@ -153,12 +153,14 @@ extern int kdb_register(char *, kdb_func
>  extern int kdb_register_repeat(char *, kdb_func_t, char *, char *,
>                               short, kdb_repeat_t);
>  extern int kdb_unregister(char *);
> +#define in_kdb_printk() (kdb_trap_printk)
>  #else /* ! CONFIG_KGDB_KDB */
>  #define kdb_printf(...)
>  #define kdb_init(x)
>  #define kdb_register(...)
>  #define kdb_register_repeat(...)
>  #define kdb_uregister(x)
> +#define in_kdb_printk() (0)
>  #endif /* CONFIG_KGDB_KDB */
>  enum {
>        KDB_NOT_INITIALIZED,
> Index: linux-2.6/kernel/debug/kdb/kdb_io.c
> ===================================================================
> --- linux-2.6.orig/kernel/debug/kdb/kdb_io.c
> +++ linux-2.6/kernel/debug/kdb/kdb_io.c
> @@ -539,7 +539,6 @@ int vkdb_printf(const char *fmt, va_list
>        int diag;
>        int linecount;
>        int logging, saved_loglevel = 0;
> -       int saved_trap_printk;
>        int got_printf_lock = 0;
>        int retlen = 0;
>        int fnd, len;
> @@ -550,8 +549,6 @@ int vkdb_printf(const char *fmt, va_list
>        unsigned long uninitialized_var(flags);
>
>        preempt_disable();
> -       saved_trap_printk = kdb_trap_printk;
> -       kdb_trap_printk = 0;
>
>        /* Serialize kdb_printf if multiple cpus try to write at once.
>         * But if any cpu goes recursive in kdb, just print the output,
> @@ -807,7 +804,6 @@ kdb_print_out:
>        } else {
>                __release(kdb_printf_lock);
>        }
> -       kdb_trap_printk = saved_trap_printk;
>        preempt_enable();
>        return retlen;
>  }
> @@ -817,9 +813,11 @@ int kdb_printf(const char *fmt, ...)
>        va_list ap;
>        int r;
>
> +       kdb_trap_printk++;
>        va_start(ap, fmt);
>        r = vkdb_printf(fmt, ap);
>        va_end(ap);
> +       kdb_trap_printk--;
>
>        return r;
>  }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-01  8:42 ` Rolando Martins
@ 2011-08-01 10:34   ` Mike Galbraith
  2011-08-01 10:45       ` Rolando Martins
  2011-08-01 11:06   ` Peter Zijlstra
  1 sibling, 1 reply; 29+ messages in thread
From: Mike Galbraith @ 2011-08-01 10:34 UTC (permalink / raw)
  To: Rolando Martins
  Cc: Peter Zijlstra, Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Mon, 2011-08-01 at 09:42 +0100, Rolando Martins wrote:
> Hi Peter,
> is there any progress on the CONFIG_RT_GROUP_SCHED front?

Out of curiosity, why would you want that in a -rt kernel?

(I haven't done any PI testing with that, but I can imagine the throttle
causing heartburn)

	-Mike

> I don't know if this is related, but in 33-rt if I used a low (=100)
> cpu_runtime_us and cpu_period_us then I would get some freezes
> (something that does not happen in 2.6.39).

(providing a realtime budget of 100 whole microseconds to a kernel where
everything and it's brother is realtime is unlikely to go well)


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-01 10:34   ` Mike Galbraith
@ 2011-08-01 10:45       ` Rolando Martins
  0 siblings, 0 replies; 29+ messages in thread
From: Rolando Martins @ 2011-08-01 10:45 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: Peter Zijlstra, Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Mon, Aug 1, 2011 at 11:34 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Mon, 2011-08-01 at 09:42 +0100, Rolando Martins wrote:
>> Hi Peter,
>> is there any progress on the CONFIG_RT_GROUP_SCHED front?
>
> Out of curiosity, why would you want that in a -rt kernel?

I am building a rt middleware that uses cgroups to reserve cpu
bandwidth for a set of tasks.
But I also interested in minimization latencies...

>
> (I haven't done any PI testing with that, but I can imagine the throttle
> causing heartburn)
>
>        -Mike
>
>> I don't know if this is related, but in 33-rt if I used a low (=100)
>> cpu_runtime_us and cpu_period_us then I would get some freezes
>> (something that does not happen in 2.6.39).
>
> (providing a realtime budget of 100 whole microseconds to a kernel where
> everything and it's brother is realtime is unlikely to go well)
I empirically tested values until I reached this one. Anything above
this would result in a huge amount of jitter
(to all tasks under a control group), at least on my boxes (corei7
920, and AMD phenom x4 950).

Rolando

>
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
@ 2011-08-01 10:45       ` Rolando Martins
  0 siblings, 0 replies; 29+ messages in thread
From: Rolando Martins @ 2011-08-01 10:45 UTC (permalink / raw)
  To: Mike Galbraith
  Cc: Peter Zijlstra, Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Mon, Aug 1, 2011 at 11:34 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Mon, 2011-08-01 at 09:42 +0100, Rolando Martins wrote:
>> Hi Peter,
>> is there any progress on the CONFIG_RT_GROUP_SCHED front?
>
> Out of curiosity, why would you want that in a -rt kernel?

I am building a rt middleware that uses cgroups to reserve cpu
bandwidth for a set of tasks.
But I also interested in minimization latencies...

>
> (I haven't done any PI testing with that, but I can imagine the throttle
> causing heartburn)
>
>        -Mike
>
>> I don't know if this is related, but in 33-rt if I used a low (=100)
>> cpu_runtime_us and cpu_period_us then I would get some freezes
>> (something that does not happen in 2.6.39).
>
> (providing a realtime budget of 100 whole microseconds to a kernel where
> everything and it's brother is realtime is unlikely to go well)
I empirically tested values until I reached this one. Anything above
this would result in a huge amount of jitter
(to all tasks under a control group), at least on my boxes (corei7
920, and AMD phenom x4 950).

Rolando

>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-01  8:42 ` Rolando Martins
  2011-08-01 10:34   ` Mike Galbraith
@ 2011-08-01 11:06   ` Peter Zijlstra
  2011-08-01 11:10     ` Rolando Martins
  1 sibling, 1 reply; 29+ messages in thread
From: Peter Zijlstra @ 2011-08-01 11:06 UTC (permalink / raw)
  To: Rolando Martins; +Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Mon, 2011-08-01 at 09:42 +0100, Rolando Martins wrote:
> Hi Peter,
> is there any progress on the CONFIG_RT_GROUP_SCHED front?
> I don't know if this is related, but in 33-rt if I used a low (=100)
> cpu_runtime_us and cpu_period_us then I would get some freezes
> (something that does not happen in 2.6.39).
> 
> 
No, I've been busy mopping up other things.. Ideally I'd rip out all the
current rt group code and put int the stuff Dario and Fabio are working
on, sadly they too are otherwise engaged atm.

I'll see if I can find a bit of time this week to stare at this mess.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-01 11:06   ` Peter Zijlstra
@ 2011-08-01 11:10     ` Rolando Martins
  0 siblings, 0 replies; 29+ messages in thread
From: Rolando Martins @ 2011-08-01 11:10 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Mon, Aug 1, 2011 at 12:06 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2011-08-01 at 09:42 +0100, Rolando Martins wrote:
>> Hi Peter,
>> is there any progress on the CONFIG_RT_GROUP_SCHED front?
>> I don't know if this is related, but in 33-rt if I used a low (=100)
>> cpu_runtime_us and cpu_period_us then I would get some freezes
>> (something that does not happen in 2.6.39).
>>
>>
Hi Peter,

> No, I've been busy mopping up other things.. Ideally I'd rip out all the
> current rt group code and put int the stuff Dario and Fabio are working
> on, sadly they too are otherwise engaged atm.
So, we would have sched_deadline support in rt? That would be amazing!

>
> I'll see if I can find a bit of time this week to stare at this mess.
Ok! I hope to contribute to the effort at least by providing some testing...

Thanks,
Rolando

>
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
                   ` (6 preceding siblings ...)
  2011-08-01  8:42 ` Rolando Martins
@ 2011-08-04  6:34 ` Fernando Lopez-Lezcano
  2011-08-04  9:42   ` Peter Zijlstra
  2011-08-04 16:34   ` Tim Sander
  8 siblings, 1 reply; 29+ messages in thread
From: Fernando Lopez-Lezcano @ 2011-08-04  6:34 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney,
	Fernando Lopez-Lezcano

On 07/28/2011 02:43 PM, Thomas Gleixner wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.0-rt6 release.

Thanks, here's some feedback from a user of Planet CCRMA (running an 
unreleased build of rt6 on x86_64 which I have not had a chance to test 
yet). See below for some details...

-- Fernando


-------- Original Message --------
Subject: More grist for the RT mill
Date: Wed, 3 Aug 2011 03:39:46 -0700
From: Tracey Hytry

After a lot of work I've managed to install Feodra15 on one of the 
machines...
just to be able to test the x86_64 version of the new builds.

Enclosed is info from just after boot.
I didn't have anything set up to test it, but there were no more errors 
afterwards;
starting x and transferring some files via nfs.
You can pass this along to linux-rt-users if needed.

----------------------------------------------
dmesg:

[  117.025914]
[  117.025916] =================================
[  117.025918] [ INFO: inconsistent lock state ]
[  117.025920] 3.0.0-1.rt6.1.fc15.ccrma.x86_64.rt #1
[  117.025922] ---------------------------------
[  117.025924] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[  117.025927] posixcputmr/0/6 [HC0[0]:SC0[0]:HE1:SE1] takes:
[  117.025929]  (&sig->cputimer.lock){?.....}, at: [<ffffffff8107b6f1>] 
__run_posix_cpu_timers+0x8f/0x353
[  117.025936] {IN-HARDIRQ-W} state was registered at:
[  117.025938]   [<ffffffff8108c8df>] __lock_acquire+0x2ce/0xd0c
[  117.025943]   [<ffffffff8108d820>] lock_acquire+0xf3/0x13e
[  117.025946]   [<ffffffff814ef322>] _raw_spin_lock+0x45/0x79
[  117.025949]   [<ffffffff8104a617>] __account_system_time+0x4a/0x81
[  117.025952]   [<ffffffff8104e9c7>] account_system_time+0xa1/0xa8
[  117.025955]   [<ffffffff8104ec1e>] account_process_tick+0x78/0x86
[  117.025957]   [<ffffffff81068ff1>] update_process_times+0x2f/0x54
[  117.025961]   [<ffffffff81088c6b>] tick_sched_timer+0xff/0x128
[  117.025964]   [<ffffffff8107c5f6>] __run_hrtimer+0xed/0x1db
[  117.025967]   [<ffffffff8107d008>] hrtimer_interrupt+0x1a1/0x2af
[  117.025969]   [<ffffffff814f719c>] smp_apic_timer_interrupt+0x77/0x8a
[  117.025973]   [<ffffffff814f6053>] apic_timer_interrupt+0x13/0x20
[  117.025976]   [<ffffffff814ef64c>] _raw_spin_unlock_irqrestore+0x4d/0x73
[  117.025978]   [<ffffffff8107a943>] thread_group_cputimer+0xae/0xbd
[  117.025981]   [<ffffffff8107a97d>] cpu_timer_sample_group+0x2b/0x75
[  117.025984]   [<ffffffff8107bc04>] set_process_cpu_timer+0x36/0xdf
[  117.025987]   [<ffffffff8107bcf1>] update_rlimit_cpu+0x44/0x63
[  117.025989]   [<ffffffff81206305>] 
selinux_bprm_committing_creds+0xd3/0xd8
[  117.025994]   [<ffffffff811fd99c>] 
security_bprm_committing_creds+0x13/0x15
[  117.025998]   [<ffffffff8114279e>] install_exec_creds+0x13/0x52
[  117.026001]   [<ffffffff811816d2>] load_elf_binary+0xf40/0x175e
[  117.026004]   [<ffffffff81143630>] search_binary_handler+0xad/0x25d
[  117.026007]   [<ffffffff81144600>] do_execve_common+0x186/0x283
[  117.026009]   [<ffffffff81144740>] do_execve+0x43/0x45
[  117.026009]   [<ffffffff810114e4>] sys_execve+0x43/0x5a
[  117.026009]   [<ffffffff814f5adc>] stub_execve+0x6c/0xc0
[  117.026009] irq event stamp: 37
[  117.026009] hardirqs last  enabled at (37): [<ffffffff814ef69f>] 
_raw_spin_unlock_irq+0x2d/0x59
[  117.026009] hardirqs last disabled at (36): [<ffffffff814ef405>] 
_raw_spin_lock_irq+0x1d/0x82
[  117.026009] softirqs last  enabled at (0): [<ffffffff8105838a>] 
copy_process+0x6c1/0x14a0
[  117.026009] softirqs last disabled at (0): [<          (null)>] 
      (null)
[  117.026009]
[  117.026009] other info that might help us debug this:
[  117.026009]  Possible unsafe locking scenario:
[  117.026009]
[  117.026009]        CPU0
[  117.026009]        ----
[  117.026009]   lock(&sig->cputimer.lock);
[  117.026009]   <Interrupt>
[  117.026009]     lock(&sig->cputimer.lock);
[  117.026009]
[  117.026009]  *** DEADLOCK ***
[  117.026009]
[  117.026009] no locks held by posixcputmr/0/6.
[  117.026009]
[  117.026009] stack backtrace:
[  117.026009] Pid: 6, comm: posixcputmr/0 Not tainted 
3.0.0-1.rt6.1.fc15.ccrma.x86_64.rt #1
[  117.026009] Call Trace:
[  117.026009]  [<ffffffff814e6278>] print_usage_bug+0x1e3/0x1f4
[  117.026009]  [<ffffffff810154e5>] ? save_stack_trace+0x2c/0x49
[  117.026009]  [<ffffffff8108be73>] ? check_usage_forwards+0xa6/0xa6
[  117.026009]  [<ffffffff8108c4f7>] mark_lock+0x106/0x220
[  117.026009]  [<ffffffff8108c956>] __lock_acquire+0x345/0xd0c
[  117.026009]  [<ffffffff8108a020>] ? trace_hardirqs_off+0xd/0xf
[  117.026009]  [<ffffffff8108a5f5>] ? 
lock_release_holdtime.part.10+0x59/0x62
[  117.026009]  [<ffffffff814ef69f>] ? _raw_spin_unlock_irq+0x2d/0x59
[  117.026009]  [<ffffffff8107b6f1>] ? __run_posix_cpu_timers+0x8f/0x353
[  117.026009]  [<ffffffff8108d820>] lock_acquire+0xf3/0x13e
[  117.026009]  [<ffffffff8107b6f1>] ? __run_posix_cpu_timers+0x8f/0x353
[  117.026009]  [<ffffffff8104aacd>] ? finish_task_switch+0x7c/0xf5
[  117.026009]  [<ffffffff8104aa90>] ? finish_task_switch+0x3f/0xf5
[  117.026009]  [<ffffffff814ef322>] _raw_spin_lock+0x45/0x79
[  117.026009]  [<ffffffff8107b6f1>] ? __run_posix_cpu_timers+0x8f/0x353
[  117.026009]  [<ffffffff8107b6f1>] __run_posix_cpu_timers+0x8f/0x353
[  117.026009]  [<ffffffff81049045>] ? need_resched+0x23/0x2d
[  117.026009]  [<ffffffff8107ba6c>] posix_cpu_timers_thread+0xb7/0x14b
[  117.026009]  [<ffffffff8107b9b5>] ? __run_posix_cpu_timers+0x353/0x353
[  117.026009]  [<ffffffff810785da>] kthread+0x99/0xa1
[  117.026009]  [<ffffffff8108a020>] ? trace_hardirqs_off+0xd/0xf
[  117.026009]  [<ffffffff8108dc5b>] ? trace_hardirqs_on+0xd/0xf
[  117.026009]  [<ffffffff814f67a4>] kernel_thread_helper+0x4/0x10
[  117.026009]  [<ffffffff814efa58>] ? retint_restore_args+0x13/0x13
[  117.026009]  [<ffffffff81078541>] ? __init_kthread_worker+0x8c/0x8c
[  117.026009]  [<ffffffff814f67a0>] ? gs_change+0x13/0x13

----------------------------------------------
lsmod:

Module                  Size  Used by
fuse                   70197  3
sunrpc                222384  1
powernow_k8            29079  1
nf_conntrack_ipv4      14700  1
nf_defrag_ipv4         12673  1 nf_conntrack_ipv4
xt_state               12578  1
nf_conntrack           81796  2 nf_conntrack_ipv4,xt_state
snd_ice1712            63535  0
snd_ice17xx_ak4xxx     13128  1 snd_ice1712
snd_ak4xxx_adda        18480  2 snd_ice1712,snd_ice17xx_ak4xxx
snd_cs8427             14054  1 snd_ice1712
snd_ac97_codec        121717  1 snd_ice1712
snd_seq                61755  0
snd_pcm                85387  2 snd_ice1712,snd_ac97_codec
xfs                   763810  1
snd_timer              29239  2 snd_seq,snd_pcm
snd_page_alloc         14039  1 snd_pcm
ac97_bus               12682  1 snd_ac97_codec
snd_i2c                14050  2 snd_ice1712,snd_cs8427
snd_mpu401_uart        14244  1 snd_ice1712
ppdev                  17712  0
snd_rawmidi            25881  1 snd_mpu401_uart
snd_seq_device         14209  2 snd_seq,snd_rawmidi
nv_tco                 13564  0
snd                    71052  11 
snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_seq,snd_pcm,snd_timer,snd_i2c,snd_mpu401_uart,snd_rawmidi,snd_seq_device
parport_pc             28208  0
edac_core              48073  0
forcedeth              55667  0
edac_mce_amd           18786  0
parport                40931  2 ppdev,parport_pc
asus_atk0110           18767  0
k8temp                 13123  0
i2c_nforce2            13166  0
soundcore              14562  1 snd
firewire_ohci          36465  0
uas                    17919  0
firewire_core          62263  1 firewire_ohci
usb_storage            52308  0
ata_generic            12899  0
crc_itu_t              12579  1 firewire_core
pata_jmicron           12747  0
pata_acpi              13027  0
sata_nv                27864  6
pata_amd               18256  1
nouveau               556740  3
ttm                    65945  1 nouveau
drm_kms_helper         36330  1 nouveau
drm                   206243  5 nouveau,ttm,drm_kms_helper
i2c_algo_bit           13246  1 nouveau
i2c_core               34149  5 
i2c_nforce2,nouveau,drm_kms_helper,drm,i2c_algo_bit
mxm_wmi                12823  1 nouveau
wmi                    18697  1 mxm_wmi
video                  19210  1 nouveau

----------------------------------------------
lspci:

00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:07.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 
[Envy24] PCI Multi-Channel I/O Controller (rev 02)
01:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A 
IEEE-1394a-2000 Controller (PHY/Link)
02:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial 
ATA Controller (rev 03)
02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 Serial ATA 
Controller (rev 03)
03:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 
GS] (rev a1)

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-04  6:34 ` Fernando Lopez-Lezcano
@ 2011-08-04  9:42   ` Peter Zijlstra
  2011-08-04 19:05     ` Fernando Lopez-Lezcano
  2011-08-08 17:25     ` Fernando Lopez-Lezcano
  0 siblings, 2 replies; 29+ messages in thread
From: Peter Zijlstra @ 2011-08-04  9:42 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Wed, 2011-08-03 at 23:34 -0700, Fernando Lopez-Lezcano wrote:
> [  117.026009]  [<ffffffff814ef322>] _raw_spin_lock+0x45/0x79
> [  117.026009]  [<ffffffff8107b6f1>] ? __run_posix_cpu_timers+0x8f/0x353
> [  117.026009]  [<ffffffff8107b6f1>] __run_posix_cpu_timers+0x8f/0x353 

I think its this one, could you confirm?

---
Index: linux-2.6/kernel/posix-cpu-timers.c
===================================================================
--- linux-2.6.orig/kernel/posix-cpu-timers.c
+++ linux-2.6/kernel/posix-cpu-timers.c
@@ -1288,10 +1288,11 @@ static inline int fastpath_timer_check(s
 	sig = tsk->signal;
 	if (sig->cputimer.running) {
 		struct task_cputime group_sample;
+		unsigned long flags;
 
-		raw_spin_lock(&sig->cputimer.lock);
+		raw_spin_lock_irqsave(&sig->cputimer.lock, flags);
 		group_sample = sig->cputimer.cputime;
-		raw_spin_unlock(&sig->cputimer.lock);
+		raw_spin_unlock_irqrestore(&sig->cputimer.lock, flags);
 
 		if (task_cputime_expired(&group_sample, &sig->cputime_expires))
 			return 1;


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724!
  2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
@ 2011-08-04 16:34   ` Tim Sander
  2011-07-28 23:33 ` Peter W. Morreale
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 29+ messages in thread
From: Tim Sander @ 2011-08-04 16:34 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

Hi 

I was really happy to find 6 preempt rt releases for the 3.0 kernel after holliday :-).

So i went for a testdrive and found an error: The error occurs in a non released non 
mainline kernel and is available from me upon request. It has been working on 
(2.6.39,3.0) but is not working on 3.0-rt6. It fails in an interrupt which calls: 

wake_up_interruptible(&hbm_device.wait);

The waitque has been initialized with:
init_waitqueue_head(&hbm_device.wait);
before interrupts where enabled. So i don't think its a race.

Will test if the 3.0-rc7 fixes the problem.

Best regards
Tim

Below is the output:
kernel BUG at kernel/rtmutex.c:724!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c7148000
[00000000] *pgd=87131831, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in: msp fpga canterm i2c_imx netx netx_reset dspload fpgaload mxc_nand nand nand_ids nand_ecc
CPU: 0    Not tainted  (3.0.0-pmx-rt6-00007-g6b68987 #153)
PC is at __bug+0x24/0x30
LR is at vprintk+0x3ec/0x45c
pc : [<c002cbb0>]    lr : [<c003dd58>]    psr: 60000193
sp : c715fcf0  ip : c715fc30  fp : c715fcfc
r10: c0319234  r9 : 00000001  r8 : 00000040
r7 : 00000000  r6 : 00000001  r5 : c787d060  r4 : bf03c6c4
r3 : 00000000  r2 : 00010003  r1 : c715fc30  r0 : 0000002a
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 87148008  DAC: 00000015
Process meassrv (pid: 450, stack limit = 0xc715e268)
Stack: (0xc715fcf0 to 0xc7160000)
fce0:                                     c715fd5c c715fd00 c023eb44 c002cb98
fd00: c023f268 c023ed68 c715fd3c c715fd18 c00346c8 c023f264 00000000 c00632b0
fd20: bf03c628 00000001 00000041 00000000 00000000 c02fee01 00000041 bf03c6c4
fd40: 00000001 00000001 00000000 00000040 c715fd6c c715fd60 c023f240 c023ea54
fd60: c715fd94 c715fd70 c00346a8 c023f23c c715fd8c c715fd80 bf03c628 00000001
fd80: 00000041 00000000 c715fdac c715fd98 bf03bb24 c0034690 c7b685a0 c02feef8
fda0: c715fde4 c715fdb0 c006eecc bf03ba70 ffffffff 00000004 000a25a8 c02feef8
fdc0: c7b685a0 c02f9678 00000002 00000040 00000003 00000001 c715fdfc c715fde8
fde0: c006f050 c006eea0 c02feef8 00000002 c715fe14 c715fe00 c00710c4 c006f000
fe00: c0071008 00000001 c715fe24 c715fe18 c006e8d8 c0071014 c715fe54 c715fe28
fe20: c0033210 c006e8b0 ffffffff 00000034 00000000 00340000 00000001 00000000
fe40: c715e000 00000000 c715fe64 c715fe58 c0033250 c003317c c715fe74 c715fe68
fe60: c006e8d8 c0033230 c715fe8c c715fe78 c0024068 c006e8b0 ffffffff f5800000
fe80: c715fee4 c715fe90 c002968c c002400c c0034fe8 c715fe48 c715fe78 00000000
fea0: bf03c6c4 c715ff18 c715ff0c c787d060 00000004 c715e000 00000000 c715fee4
fec0: c715fe18 c715fed8 c002cb70 c023f240 60000013 ffffffff c715ff04 c715fee8
fee0: c0056338 c023f23c c00365cc c715e000 41093914 c715ff0c c715ff3c c715ff08
ff00: bf03b9e0 c005631c 00000001 00000000 c787d060 c00365cc 00000000 00000000
ff20: 00000004 c7114b60 41093914 c715ff70 c715ff6c c715ff40 c009e95c bf03b99c
ff40: c715ff6c c715ff50 c009fab0 c7114b60 41093914 00000000 00000000 00000004
ff60: c715ffa4 c715ff70 c009ea2c c009e8b0 00000000 00000000 c715ff94 00000001
ff80: c0042578 bee199b4 00000000 4109fca8 00000003 c0029c04 00000000 c715ffa8
ffa0: c0029a80 c009e9f4 bee199b4 00000000 00000009 41093914 00000004 bee199b4
ffc0: bee199b4 00000000 4109fca8 00000003 410a0460 bee19934 00000000 4109ff9c
ffe0: 00000000 4108bb48 404e43fc 404e4bc4 80000010 00000009 86bae92e 86fa7a2e
Backtrace: 
[<c002cb8c>] (__bug+0x0/0x30) from [<c023eb44>] (rt_spin_lock_slowlock+0xfc/0x274)
[<c023ea48>] (rt_spin_lock_slowlock+0x0/0x274) from [<c023f240>] (rt_spin_lock+0x10/0x14)
 r8:00000040 r7:00000000 r6:00000001 r5:00000001 r4:bf03c6c4
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c00346a8>] (__wake_up+0x24/0x4c)
[<c0034684>] (__wake_up+0x0/0x4c) from [<bf03bb24>] (hbm_mmap_irq_handler+0xc0/0x100 [fpga])
 r7:00000000 r6:00000041 r5:00000001 r4:bf03c628
[<bf03ba64>] (hbm_mmap_irq_handler+0x0/0x100 [fpga]) from [<c006eecc>] (handle_irq_event_percpu+0x38/0x160)
 r5:c02feef8 r4:c7b685a0
[<c006ee94>] (handle_irq_event_percpu+0x0/0x160) from [<c006f050>] (handle_irq_event+0x5c/0x7c)
[<c006eff4>] (handle_irq_event+0x0/0x7c) from [<c00710c4>] (handle_level_irq+0xbc/0x108)
 r5:00000002 r4:c02feef8
[<c0071008>] (handle_level_irq+0x0/0x108) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
 r4:00000001 r3:c0071008
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0033210>] (mxc_gpio_irq_handler+0xa0/0xb4)
[<c0033170>] (mxc_gpio_irq_handler+0x0/0xb4) from [<c0033250>] (mx3_gpio_irq_handler+0x2c/0x30)
[<c0033224>] (mx3_gpio_irq_handler+0x0/0x30) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0024068>] (asm_do_IRQ+0x68/0x8c)
[<c0024000>] (asm_do_IRQ+0x0/0x8c) from [<c002968c>] (__irq_svc+0x4c/0x94)
Exception stack(0xc715fe90 to 0xc715fed8)
fe80:                                     c0034fe8 c715fe48 c715fe78 00000000
fea0: bf03c6c4 c715ff18 c715ff0c c787d060 00000004 c715e000 00000000 c715fee4
fec0: c715fe18 c715fed8 c002cb70 c023f240 60000013 ffffffff
 r5:f5800000 r4:ffffffff
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c0056338>] (add_wait_queue+0x28/0x4c)
[<c0056310>] (add_wait_queue+0x0/0x4c) from [<bf03b9e0>] (hbm_mmap_read+0x50/0xd4 [fpga])
 r6:c715ff0c r5:41093914 r4:c715e000 r3:c00365cc
[<bf03b990>] (hbm_mmap_read+0x0/0xd4 [fpga]) from [<c009e95c>] (vfs_read+0xb8/0x144)
 r7:c715ff70 r6:41093914 r5:c7114b60 r4:00000004
[<c009e8a4>] (vfs_read+0x0/0x144) from [<c009ea2c>] (sys_read+0x44/0x70)
 r8:00000004 r7:00000000 r6:00000000 r5:41093914 r4:c7114b60
[<c009e9e8>] (sys_read+0x0/0x70) from [<c0029a80>] (ret_fast_syscall+0x0/0x30)
 r8:c0029c04 r7:00000003 r6:4109fca8 r5:00000000 r4:bee199b4
Code: e59f0010 e1a01003 eb084104 e3a03000 (e5833000) 
---[ end trace 0000000000000002 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Backtrace: 
[<c002cdb8>] (dump_backtrace+0x0/0x110) from [<c023ce34>] (dump_stack+0x18/0x1c)
 r6:00000000 r5:c715fca8 r4:c030f370 r3:00000000
[<c023ce1c>] (dump_stack+0x0/0x1c) from [<c023ce9c>] (panic+0x64/0x188)
[<c023ce38>] (panic+0x0/0x188) from [<c002d2f4>] (die+0x100/0x128)
 r3:00010000 r2:c715fb78 r1:00000001 r0:c02afc9d
 r7:00000817
[<c002d1f4>] (die+0x0/0x128) from [<c002f0a8>] (__do_kernel_fault+0x6c/0x8c)
 r7:c715fca8 r6:c7abae40 r5:00000817 r4:00000000
[<c002f03c>] (__do_kernel_fault+0x0/0x8c) from [<c002f1fc>] (do_page_fault+0x134/0x14c)
 r8:00000000 r7:c02f9190 r6:c787d060 r5:c7abae40 r4:c715fca8
r3:c715fca8
[<c002f0c8>] (do_page_fault+0x0/0x14c) from [<c002420c>] (do_DataAbort+0x38/0xa0)
[<c00241d4>] (do_DataAbort+0x0/0xa0) from [<c002960c>] (__dabt_svc+0x4c/0x80)
Exception stack(0xc715fca8 to 0xc715fcf0)
fca0:                   0000002a c715fc30 00010003 00000000 bf03c6c4 c787d060
fcc0: 00000001 00000000 00000040 00000001 c0319234 c715fcfc c715fc30 c715fcf0
fce0: c003dd58 c002cbb0 60000193 ffffffff
 r8:00000040 r7:00000000 r6:00000001 r5:c715fcdc r4:ffffffff
[<c002cb8c>] (__bug+0x0/0x30) from [<c023eb44>] (rt_spin_lock_slowlock+0xfc/0x274)
[<c023ea48>] (rt_spin_lock_slowlock+0x0/0x274) from [<c023f240>] (rt_spin_lock+0x10/0x14)
 r8:00000040 r7:00000000 r6:00000001 r5:00000001 r4:bf03c6c4
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c00346a8>] (__wake_up+0x24/0x4c)
[<c0034684>] (__wake_up+0x0/0x4c) from [<bf03bb24>] (hbm_mmap_irq_handler+0xc0/0x100 [fpga])
 r7:00000000 r6:00000041 r5:00000001 r4:bf03c628
[<bf03ba64>] (hbm_mmap_irq_handler+0x0/0x100 [fpga]) from [<c006eecc>] (handle_irq_event_percpu+0x38/0x160)
 r5:c02feef8 r4:c7b685a0
[<c006ee94>] (handle_irq_event_percpu+0x0/0x160) from [<c006f050>] (handle_irq_event+0x5c/0x7c)
[<c006eff4>] (handle_irq_event+0x0/0x7c) from [<c00710c4>] (handle_level_irq+0xbc/0x108)
 r5:00000002 r4:c02feef8
[<c0071008>] (handle_level_irq+0x0/0x108) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
 r4:00000001 r3:c0071008
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0033210>] (mxc_gpio_irq_handler+0xa0/0xb4)
[<c0033170>] (mxc_gpio_irq_handler+0x0/0xb4) from [<c0033250>] (mx3_gpio_irq_handler+0x2c/0x30)
[<c0033224>] (mx3_gpio_irq_handler+0x0/0x30) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0024068>] (asm_do_IRQ+0x68/0x8c)
[<c0024000>] (asm_do_IRQ+0x0/0x8c) from [<c002968c>] (__irq_svc+0x4c/0x94)
Exception stack(0xc715fe90 to 0xc715fed8)
fe80:                                     c0034fe8 c715fe48 c715fe78 00000000
fea0: bf03c6c4 c715ff18 c715ff0c c787d060 00000004 c715e000 00000000 c715fee4
fec0: c715fe18 c715fed8 c002cb70 c023f240 60000013 ffffffff
 r5:f5800000 r4:ffffffff
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c0056338>] (add_wait_queue+0x28/0x4c)
[<c0056310>] (add_wait_queue+0x0/0x4c) from [<bf03b9e0>] (hbm_mmap_read+0x50/0xd4 [fpga])
 r6:c715ff0c r5:41093914 r4:c715e000 r3:c00365cc
[<bf03b990>] (hbm_mmap_read+0x0/0xd4 [fpga]) from [<c009e95c>] (vfs_read+0xb8/0x144)
 r7:c715ff70 r6:41093914 r5:c7114b60 r4:00000004
[<c009e8a4>] (vfs_read+0x0/0x144) from [<c009ea2c>] (sys_read+0x44/0x70)
 r8:00000004 r7:00000000 r6:00000000 r5:41093914 r4:c7114b60
[<c009e9e8>] (sys_read+0x0/0x70) from [<c0029a80>] (ret_fast_syscall+0x0/0x30)
 r8:c0029c04 r7:00000003 r6:4109fca8 r5:00000000 r4:bee199b4


Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich für den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724!
@ 2011-08-04 16:34   ` Tim Sander
  0 siblings, 0 replies; 29+ messages in thread
From: Tim Sander @ 2011-08-04 16:34 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, linux-rt-users, Peter Zijlstra, Paul E. McKenney

Hi 

I was really happy to find 6 preempt rt releases for the 3.0 kernel after holliday :-).

So i went for a testdrive and found an error: The error occurs in a non released non 
mainline kernel and is available from me upon request. It has been working on 
(2.6.39,3.0) but is not working on 3.0-rt6. It fails in an interrupt which calls: 

wake_up_interruptible(&hbm_device.wait);

The waitque has been initialized with:
init_waitqueue_head(&hbm_device.wait);
before interrupts where enabled. So i don't think its a race.

Will test if the 3.0-rc7 fixes the problem.

Best regards
Tim

Below is the output:
kernel BUG at kernel/rtmutex.c:724!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c7148000
[00000000] *pgd=87131831, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in: msp fpga canterm i2c_imx netx netx_reset dspload fpgaload mxc_nand nand nand_ids nand_ecc
CPU: 0    Not tainted  (3.0.0-pmx-rt6-00007-g6b68987 #153)
PC is at __bug+0x24/0x30
LR is at vprintk+0x3ec/0x45c
pc : [<c002cbb0>]    lr : [<c003dd58>]    psr: 60000193
sp : c715fcf0  ip : c715fc30  fp : c715fcfc
r10: c0319234  r9 : 00000001  r8 : 00000040
r7 : 00000000  r6 : 00000001  r5 : c787d060  r4 : bf03c6c4
r3 : 00000000  r2 : 00010003  r1 : c715fc30  r0 : 0000002a
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 87148008  DAC: 00000015
Process meassrv (pid: 450, stack limit = 0xc715e268)
Stack: (0xc715fcf0 to 0xc7160000)
fce0:                                     c715fd5c c715fd00 c023eb44 c002cb98
fd00: c023f268 c023ed68 c715fd3c c715fd18 c00346c8 c023f264 00000000 c00632b0
fd20: bf03c628 00000001 00000041 00000000 00000000 c02fee01 00000041 bf03c6c4
fd40: 00000001 00000001 00000000 00000040 c715fd6c c715fd60 c023f240 c023ea54
fd60: c715fd94 c715fd70 c00346a8 c023f23c c715fd8c c715fd80 bf03c628 00000001
fd80: 00000041 00000000 c715fdac c715fd98 bf03bb24 c0034690 c7b685a0 c02feef8
fda0: c715fde4 c715fdb0 c006eecc bf03ba70 ffffffff 00000004 000a25a8 c02feef8
fdc0: c7b685a0 c02f9678 00000002 00000040 00000003 00000001 c715fdfc c715fde8
fde0: c006f050 c006eea0 c02feef8 00000002 c715fe14 c715fe00 c00710c4 c006f000
fe00: c0071008 00000001 c715fe24 c715fe18 c006e8d8 c0071014 c715fe54 c715fe28
fe20: c0033210 c006e8b0 ffffffff 00000034 00000000 00340000 00000001 00000000
fe40: c715e000 00000000 c715fe64 c715fe58 c0033250 c003317c c715fe74 c715fe68
fe60: c006e8d8 c0033230 c715fe8c c715fe78 c0024068 c006e8b0 ffffffff f5800000
fe80: c715fee4 c715fe90 c002968c c002400c c0034fe8 c715fe48 c715fe78 00000000
fea0: bf03c6c4 c715ff18 c715ff0c c787d060 00000004 c715e000 00000000 c715fee4
fec0: c715fe18 c715fed8 c002cb70 c023f240 60000013 ffffffff c715ff04 c715fee8
fee0: c0056338 c023f23c c00365cc c715e000 41093914 c715ff0c c715ff3c c715ff08
ff00: bf03b9e0 c005631c 00000001 00000000 c787d060 c00365cc 00000000 00000000
ff20: 00000004 c7114b60 41093914 c715ff70 c715ff6c c715ff40 c009e95c bf03b99c
ff40: c715ff6c c715ff50 c009fab0 c7114b60 41093914 00000000 00000000 00000004
ff60: c715ffa4 c715ff70 c009ea2c c009e8b0 00000000 00000000 c715ff94 00000001
ff80: c0042578 bee199b4 00000000 4109fca8 00000003 c0029c04 00000000 c715ffa8
ffa0: c0029a80 c009e9f4 bee199b4 00000000 00000009 41093914 00000004 bee199b4
ffc0: bee199b4 00000000 4109fca8 00000003 410a0460 bee19934 00000000 4109ff9c
ffe0: 00000000 4108bb48 404e43fc 404e4bc4 80000010 00000009 86bae92e 86fa7a2e
Backtrace: 
[<c002cb8c>] (__bug+0x0/0x30) from [<c023eb44>] (rt_spin_lock_slowlock+0xfc/0x274)
[<c023ea48>] (rt_spin_lock_slowlock+0x0/0x274) from [<c023f240>] (rt_spin_lock+0x10/0x14)
 r8:00000040 r7:00000000 r6:00000001 r5:00000001 r4:bf03c6c4
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c00346a8>] (__wake_up+0x24/0x4c)
[<c0034684>] (__wake_up+0x0/0x4c) from [<bf03bb24>] (hbm_mmap_irq_handler+0xc0/0x100 [fpga])
 r7:00000000 r6:00000041 r5:00000001 r4:bf03c628
[<bf03ba64>] (hbm_mmap_irq_handler+0x0/0x100 [fpga]) from [<c006eecc>] (handle_irq_event_percpu+0x38/0x160)
 r5:c02feef8 r4:c7b685a0
[<c006ee94>] (handle_irq_event_percpu+0x0/0x160) from [<c006f050>] (handle_irq_event+0x5c/0x7c)
[<c006eff4>] (handle_irq_event+0x0/0x7c) from [<c00710c4>] (handle_level_irq+0xbc/0x108)
 r5:00000002 r4:c02feef8
[<c0071008>] (handle_level_irq+0x0/0x108) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
 r4:00000001 r3:c0071008
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0033210>] (mxc_gpio_irq_handler+0xa0/0xb4)
[<c0033170>] (mxc_gpio_irq_handler+0x0/0xb4) from [<c0033250>] (mx3_gpio_irq_handler+0x2c/0x30)
[<c0033224>] (mx3_gpio_irq_handler+0x0/0x30) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0024068>] (asm_do_IRQ+0x68/0x8c)
[<c0024000>] (asm_do_IRQ+0x0/0x8c) from [<c002968c>] (__irq_svc+0x4c/0x94)
Exception stack(0xc715fe90 to 0xc715fed8)
fe80:                                     c0034fe8 c715fe48 c715fe78 00000000
fea0: bf03c6c4 c715ff18 c715ff0c c787d060 00000004 c715e000 00000000 c715fee4
fec0: c715fe18 c715fed8 c002cb70 c023f240 60000013 ffffffff
 r5:f5800000 r4:ffffffff
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c0056338>] (add_wait_queue+0x28/0x4c)
[<c0056310>] (add_wait_queue+0x0/0x4c) from [<bf03b9e0>] (hbm_mmap_read+0x50/0xd4 [fpga])
 r6:c715ff0c r5:41093914 r4:c715e000 r3:c00365cc
[<bf03b990>] (hbm_mmap_read+0x0/0xd4 [fpga]) from [<c009e95c>] (vfs_read+0xb8/0x144)
 r7:c715ff70 r6:41093914 r5:c7114b60 r4:00000004
[<c009e8a4>] (vfs_read+0x0/0x144) from [<c009ea2c>] (sys_read+0x44/0x70)
 r8:00000004 r7:00000000 r6:00000000 r5:41093914 r4:c7114b60
[<c009e9e8>] (sys_read+0x0/0x70) from [<c0029a80>] (ret_fast_syscall+0x0/0x30)
 r8:c0029c04 r7:00000003 r6:4109fca8 r5:00000000 r4:bee199b4
Code: e59f0010 e1a01003 eb084104 e3a03000 (e5833000) 
---[ end trace 0000000000000002 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Backtrace: 
[<c002cdb8>] (dump_backtrace+0x0/0x110) from [<c023ce34>] (dump_stack+0x18/0x1c)
 r6:00000000 r5:c715fca8 r4:c030f370 r3:00000000
[<c023ce1c>] (dump_stack+0x0/0x1c) from [<c023ce9c>] (panic+0x64/0x188)
[<c023ce38>] (panic+0x0/0x188) from [<c002d2f4>] (die+0x100/0x128)
 r3:00010000 r2:c715fb78 r1:00000001 r0:c02afc9d
 r7:00000817
[<c002d1f4>] (die+0x0/0x128) from [<c002f0a8>] (__do_kernel_fault+0x6c/0x8c)
 r7:c715fca8 r6:c7abae40 r5:00000817 r4:00000000
[<c002f03c>] (__do_kernel_fault+0x0/0x8c) from [<c002f1fc>] (do_page_fault+0x134/0x14c)
 r8:00000000 r7:c02f9190 r6:c787d060 r5:c7abae40 r4:c715fca8
r3:c715fca8
[<c002f0c8>] (do_page_fault+0x0/0x14c) from [<c002420c>] (do_DataAbort+0x38/0xa0)
[<c00241d4>] (do_DataAbort+0x0/0xa0) from [<c002960c>] (__dabt_svc+0x4c/0x80)
Exception stack(0xc715fca8 to 0xc715fcf0)
fca0:                   0000002a c715fc30 00010003 00000000 bf03c6c4 c787d060
fcc0: 00000001 00000000 00000040 00000001 c0319234 c715fcfc c715fc30 c715fcf0
fce0: c003dd58 c002cbb0 60000193 ffffffff
 r8:00000040 r7:00000000 r6:00000001 r5:c715fcdc r4:ffffffff
[<c002cb8c>] (__bug+0x0/0x30) from [<c023eb44>] (rt_spin_lock_slowlock+0xfc/0x274)
[<c023ea48>] (rt_spin_lock_slowlock+0x0/0x274) from [<c023f240>] (rt_spin_lock+0x10/0x14)
 r8:00000040 r7:00000000 r6:00000001 r5:00000001 r4:bf03c6c4
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c00346a8>] (__wake_up+0x24/0x4c)
[<c0034684>] (__wake_up+0x0/0x4c) from [<bf03bb24>] (hbm_mmap_irq_handler+0xc0/0x100 [fpga])
 r7:00000000 r6:00000041 r5:00000001 r4:bf03c628
[<bf03ba64>] (hbm_mmap_irq_handler+0x0/0x100 [fpga]) from [<c006eecc>] (handle_irq_event_percpu+0x38/0x160)
 r5:c02feef8 r4:c7b685a0
[<c006ee94>] (handle_irq_event_percpu+0x0/0x160) from [<c006f050>] (handle_irq_event+0x5c/0x7c)
[<c006eff4>] (handle_irq_event+0x0/0x7c) from [<c00710c4>] (handle_level_irq+0xbc/0x108)
 r5:00000002 r4:c02feef8
[<c0071008>] (handle_level_irq+0x0/0x108) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
 r4:00000001 r3:c0071008
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0033210>] (mxc_gpio_irq_handler+0xa0/0xb4)
[<c0033170>] (mxc_gpio_irq_handler+0x0/0xb4) from [<c0033250>] (mx3_gpio_irq_handler+0x2c/0x30)
[<c0033224>] (mx3_gpio_irq_handler+0x0/0x30) from [<c006e8d8>] (generic_handle_irq+0x34/0x48)
[<c006e8a4>] (generic_handle_irq+0x0/0x48) from [<c0024068>] (asm_do_IRQ+0x68/0x8c)
[<c0024000>] (asm_do_IRQ+0x0/0x8c) from [<c002968c>] (__irq_svc+0x4c/0x94)
Exception stack(0xc715fe90 to 0xc715fed8)
fe80:                                     c0034fe8 c715fe48 c715fe78 00000000
fea0: bf03c6c4 c715ff18 c715ff0c c787d060 00000004 c715e000 00000000 c715fee4
fec0: c715fe18 c715fed8 c002cb70 c023f240 60000013 ffffffff
 r5:f5800000 r4:ffffffff
[<c023f230>] (rt_spin_lock+0x0/0x14) from [<c0056338>] (add_wait_queue+0x28/0x4c)
[<c0056310>] (add_wait_queue+0x0/0x4c) from [<bf03b9e0>] (hbm_mmap_read+0x50/0xd4 [fpga])
 r6:c715ff0c r5:41093914 r4:c715e000 r3:c00365cc
[<bf03b990>] (hbm_mmap_read+0x0/0xd4 [fpga]) from [<c009e95c>] (vfs_read+0xb8/0x144)
 r7:c715ff70 r6:41093914 r5:c7114b60 r4:00000004
[<c009e8a4>] (vfs_read+0x0/0x144) from [<c009ea2c>] (sys_read+0x44/0x70)
 r8:00000004 r7:00000000 r6:00000000 r5:41093914 r4:c7114b60
[<c009e9e8>] (sys_read+0x0/0x70) from [<c0029a80>] (ret_fast_syscall+0x0/0x30)
 r8:c0029c04 r7:00000003 r6:4109fca8 r5:00000000 r4:bee199b4


Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich für den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724!
  2011-08-04 16:34   ` Tim Sander
  (?)
@ 2011-08-04 16:37   ` Peter Zijlstra
  2011-08-04 17:04       ` Tim Sander
  -1 siblings, 1 reply; 29+ messages in thread
From: Peter Zijlstra @ 2011-08-04 16:37 UTC (permalink / raw)
  To: Tim Sander; +Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Thu, 2011-08-04 at 18:34 +0200, Tim Sander wrote:
> I was really happy to find 6 preempt rt releases for the 3.0 kernel after holliday :-).
> 
> So i went for a testdrive and found an error: The error occurs in a non released non 
> mainline kernel and is available from me upon request. It has been working on 
> (2.6.39,3.0) but is not working on 3.0-rt6. It fails in an interrupt which calls: 
> 
> wake_up_interruptible(&hbm_device.wait);
> 
> The waitque has been initialized with:
> init_waitqueue_head(&hbm_device.wait);
> before interrupts where enabled. So i don't think its a race. 

looks like it tries to use waitqueues from hardirq context, that's a
no-no for -rt. That interrupt should be a threaded interrupt.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724!
  2011-08-04 16:37   ` Peter Zijlstra
@ 2011-08-04 17:04       ` Tim Sander
  0 siblings, 0 replies; 29+ messages in thread
From: Tim Sander @ 2011-08-04 17:04 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

Am Donnerstag, 4. August 2011, 18:37:09 schrieb Peter Zijlstra:
> looks like it tries to use waitqueues from hardirq context, that's a
> no-no for -rt. That interrupt should be a threaded interrupt.
Ah, right: i enabled hardirq in tring to fight latency without preempt-rt and 
then forgot.

Its working now with 3.0-rt7.

Thanks 
Tim

Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich für den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724!
@ 2011-08-04 17:04       ` Tim Sander
  0 siblings, 0 replies; 29+ messages in thread
From: Tim Sander @ 2011-08-04 17:04 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

Am Donnerstag, 4. August 2011, 18:37:09 schrieb Peter Zijlstra:
> looks like it tries to use waitqueues from hardirq context, that's a
> no-no for -rt. That interrupt should be a threaded interrupt.
Ah, right: i enabled hardirq in tring to fight latency without preempt-rt and 
then forgot.

Its working now with 3.0-rt7.

Thanks 
Tim

Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich für den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-04  9:42   ` Peter Zijlstra
@ 2011-08-04 19:05     ` Fernando Lopez-Lezcano
  2011-08-04 20:15       ` Uwe Kleine-König
  2011-08-08 17:25     ` Fernando Lopez-Lezcano
  1 sibling, 1 reply; 29+ messages in thread
From: Fernando Lopez-Lezcano @ 2011-08-04 19:05 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney,
	Fernando Lopez-Lezcano

Was going to try this but it appears it is in rt7, trying to build rt7 
fails with:

ERROR: "of_find_property" [drivers/tty/serial/of_serial.ko] undefined!
ERROR: "of_find_property" [drivers/hwmon/ltc4245.ko] undefined!

-- Fernando

On 08/04/2011 02:42 AM, Peter Zijlstra wrote:
> On Wed, 2011-08-03 at 23:34 -0700, Fernando Lopez-Lezcano wrote:
>> [  117.026009]  [<ffffffff814ef322>] _raw_spin_lock+0x45/0x79
>> [  117.026009]  [<ffffffff8107b6f1>] ? __run_posix_cpu_timers+0x8f/0x353
>> [  117.026009]  [<ffffffff8107b6f1>] __run_posix_cpu_timers+0x8f/0x353
>
> I think its this one, could you confirm?
>
> ---
> Index: linux-2.6/kernel/posix-cpu-timers.c
> ===================================================================
> --- linux-2.6.orig/kernel/posix-cpu-timers.c
> +++ linux-2.6/kernel/posix-cpu-timers.c
> @@ -1288,10 +1288,11 @@ static inline int fastpath_timer_check(s
>   	sig = tsk->signal;
>   	if (sig->cputimer.running) {
>   		struct task_cputime group_sample;
> +		unsigned long flags;
>
> -		raw_spin_lock(&sig->cputimer.lock);
> +		raw_spin_lock_irqsave(&sig->cputimer.lock, flags);
>   		group_sample = sig->cputimer.cputime;
> -		raw_spin_unlock(&sig->cputimer.lock);
> +		raw_spin_unlock_irqrestore(&sig->cputimer.lock, flags);
>
>   		if (task_cputime_expired(&group_sample,&sig->cputime_expires))
>   			return 1;
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-04 19:05     ` Fernando Lopez-Lezcano
@ 2011-08-04 20:15       ` Uwe Kleine-König
  2011-08-05  9:28         ` Uwe Kleine-König
  0 siblings, 1 reply; 29+ messages in thread
From: Uwe Kleine-König @ 2011-08-04 20:15 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Peter Zijlstra, Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Thu, Aug 04, 2011 at 12:05:12PM -0700, Fernando Lopez-Lezcano wrote:
> Was going to try this but it appears it is in rt7, trying to build
> rt7 fails with:
> 
> ERROR: "of_find_property" [drivers/tty/serial/of_serial.ko] undefined!
> ERROR: "of_find_property" [drivers/hwmon/ltc4245.ko] undefined!
This is known but unfixed, see
http://mid.gmane.org/20110722065711.GD16561@pengutronix.de

You should be able to workaround that by jugling with the .config. I.e.
disable OF or something like that.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-04 20:15       ` Uwe Kleine-König
@ 2011-08-05  9:28         ` Uwe Kleine-König
  2011-08-05 16:03           ` Fernando Lopez-Lezcano
  0 siblings, 1 reply; 29+ messages in thread
From: Uwe Kleine-König @ 2011-08-05  9:28 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Peter Zijlstra, Thomas Gleixner, LKML, linux-rt-users, Paul E. McKenney

On Thu, Aug 04, 2011 at 10:15:00PM +0200, Uwe Kleine-König wrote:
> On Thu, Aug 04, 2011 at 12:05:12PM -0700, Fernando Lopez-Lezcano wrote:
> > Was going to try this but it appears it is in rt7, trying to build
> > rt7 fails with:
> > 
> > ERROR: "of_find_property" [drivers/tty/serial/of_serial.ko] undefined!
> > ERROR: "of_find_property" [drivers/hwmon/ltc4245.ko] undefined!
> This is known but unfixed, see
> http://mid.gmane.org/20110722065711.GD16561@pengutronix.de
> 
> You should be able to workaround that by jugling with the .config. I.e.
> disable OF or something like that.
Can you send me a .config, then I'd look into that.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-05  9:28         ` Uwe Kleine-König
@ 2011-08-05 16:03           ` Fernando Lopez-Lezcano
  0 siblings, 0 replies; 29+ messages in thread
From: Fernando Lopez-Lezcano @ 2011-08-05 16:03 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Peter Zijlstra, Thomas Gleixner, LKML, linux-rt-users,
	Paul E. McKenney, Fernando Lopez-Lezcano

On 08/05/2011 02:28 AM, Uwe Kleine-König wrote:
> On Thu, Aug 04, 2011 at 10:15:00PM +0200, Uwe Kleine-König wrote:
>> On Thu, Aug 04, 2011 at 12:05:12PM -0700, Fernando Lopez-Lezcano wrote:
>>> Was going to try this but it appears it is in rt7, trying to build
>>> rt7 fails with:
>>>
>>> ERROR: "of_find_property" [drivers/tty/serial/of_serial.ko] undefined!
>>> ERROR: "of_find_property" [drivers/hwmon/ltc4245.ko] undefined!
>> This is known but unfixed, see
>> http://mid.gmane.org/20110722065711.GD16561@pengutronix.de
>>
>> You should be able to workaround that by jugling with the .config. I.e.
>> disable OF or something like that.
> Can you send me a .config, then I'd look into that.

To work around the issue I had to disable:

   CONFIG_SERIAL_OF_PLATFORM
   CONFIG_SENSORS_LTC4245

-- Fernando

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-07-30 20:21   ` Remy Bohmer
@ 2011-08-07 10:44     ` Remy Bohmer
  0 siblings, 0 replies; 29+ messages in thread
From: Remy Bohmer @ 2011-08-07 10:44 UTC (permalink / raw)
  To: Thomas Gleixner, Peter Zijlstra; +Cc: LKML, linux-rt-users, Paul E. McKenney

Hi All,

2011/7/30 Remy Bohmer <linux@bohmer.net>:
> Hi,
>
> 2011/7/30 Remy Bohmer <linux@bohmer.net>:
>>> Please keep on testing and sending patches. Peter Zijlstra kindly
>>> volunteered to cover for me. He'll pick up stuff and eventually push
>>> out releases when a reasonable number of sane patches hits his inbox.
>>
>> I got rt5 booting yesterday on a ARM core (Atmel AT91):

After fixing several problems in mainstream kernel for this board
(at91sam9261ek), the RT(8) patch runs remarkably stable. None of the
problems discovered so far were related to the RT-patch. I can now
start testing how it behaves on timing level.

Thanks.

Kind regards,

Remy

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [ANNOUNCE] 3.0-rt6
  2011-08-04  9:42   ` Peter Zijlstra
  2011-08-04 19:05     ` Fernando Lopez-Lezcano
@ 2011-08-08 17:25     ` Fernando Lopez-Lezcano
  1 sibling, 0 replies; 29+ messages in thread
From: Fernando Lopez-Lezcano @ 2011-08-08 17:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Fernando Lopez-Lezcano, Thomas Gleixner, LKML, linux-rt-users,
	Paul E. McKenney

On 08/04/2011 02:42 AM, Peter Zijlstra wrote:
> On Wed, 2011-08-03 at 23:34 -0700, Fernando Lopez-Lezcano wrote:
>> [  117.026009]  [<ffffffff814ef322>] _raw_spin_lock+0x45/0x79
>> [  117.026009]  [<ffffffff8107b6f1>] ? __run_posix_cpu_timers+0x8f/0x353
>> [  117.026009]  [<ffffffff8107b6f1>] __run_posix_cpu_timers+0x8f/0x353
>
> I think its this one, could you confirm?

If this was later part of rt8 then yes, Tracey was able to boot on 
fc15/x86_64 with no further problems (3.0.1 + rt8). I was also able to 
boot rt8 this morning in my fc15 test laptop with no bugs or oops so 
far... still testing but looks promising.

Thanks again!
-- Fernando


> ---
> Index: linux-2.6/kernel/posix-cpu-timers.c
> ===================================================================
> --- linux-2.6.orig/kernel/posix-cpu-timers.c
> +++ linux-2.6/kernel/posix-cpu-timers.c
> @@ -1288,10 +1288,11 @@ static inline int fastpath_timer_check(s
>   	sig = tsk->signal;
>   	if (sig->cputimer.running) {
>   		struct task_cputime group_sample;
> +		unsigned long flags;
>
> -		raw_spin_lock(&sig->cputimer.lock);
> +		raw_spin_lock_irqsave(&sig->cputimer.lock, flags);
>   		group_sample = sig->cputimer.cputime;
> -		raw_spin_unlock(&sig->cputimer.lock);
> +		raw_spin_unlock_irqrestore(&sig->cputimer.lock, flags);
>
>   		if (task_cputime_expired(&group_sample,&sig->cputime_expires))
>   			return 1;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2011-08-08 17:25 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-28 21:43 [ANNOUNCE] 3.0-rt6 Thomas Gleixner
2011-07-28 22:33 ` Madovsky
2011-07-28 23:33 ` Peter W. Morreale
2011-07-29  0:56   ` Thomas Gleixner
2011-07-29  6:05 ` Mike Galbraith
2011-07-29 14:03 ` Paul E. McKenney
2011-07-29 15:57 ` [ANNOUNCE] 3.0-rt6 (kgdb working) Darren Hart
2011-07-30 15:49 ` [ANNOUNCE] 3.0-rt6 Remy Bohmer
2011-07-30 15:49   ` Remy Bohmer
2011-07-30 20:21   ` Remy Bohmer
2011-08-07 10:44     ` Remy Bohmer
2011-08-01  8:42 ` Rolando Martins
2011-08-01 10:34   ` Mike Galbraith
2011-08-01 10:45     ` Rolando Martins
2011-08-01 10:45       ` Rolando Martins
2011-08-01 11:06   ` Peter Zijlstra
2011-08-01 11:10     ` Rolando Martins
2011-08-04  6:34 ` Fernando Lopez-Lezcano
2011-08-04  9:42   ` Peter Zijlstra
2011-08-04 19:05     ` Fernando Lopez-Lezcano
2011-08-04 20:15       ` Uwe Kleine-König
2011-08-05  9:28         ` Uwe Kleine-König
2011-08-05 16:03           ` Fernando Lopez-Lezcano
2011-08-08 17:25     ` Fernando Lopez-Lezcano
2011-08-04 16:34 ` [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724! Tim Sander
2011-08-04 16:34   ` Tim Sander
2011-08-04 16:37   ` Peter Zijlstra
2011-08-04 17:04     ` Tim Sander
2011-08-04 17:04       ` Tim Sander

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.