Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[ANNOUNCE] 3.0-rt6

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


tglx at linutronix

Jul 28, 2011, 2:43 PM

Post #1 of 22 (1223 views)
Permalink
[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-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pmorreale at novell

Jul 28, 2011, 4:33 PM

Post #2 of 22 (1215 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


tglx at linutronix

Jul 28, 2011, 5:56 PM

Post #3 of 22 (1215 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


efault at gmx

Jul 28, 2011, 11:05 PM

Post #4 of 22 (1212 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


paulmck at linux

Jul 29, 2011, 7:03 AM

Post #5 of 22 (1208 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] linux>
---

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dvhart at linux

Jul 29, 2011, 8:57 AM

Post #6 of 22 (1209 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 (kgdb working) [In reply to]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


linux at bohmer

Jul 30, 2011, 8:49 AM

Post #7 of 22 (1205 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

Hi,

2011/7/28 Thomas Gleixner <tglx [at] linutronix>:
> 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-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


linux at bohmer

Jul 30, 2011, 1:21 PM

Post #8 of 22 (1203 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

Hi,

2011/7/30 Remy Bohmer <linux [at] bohmer>:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rolando.martins at gmail

Aug 1, 2011, 1:42 AM

Post #9 of 22 (1204 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] linutronix> 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 [at] vger
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


efault at gmx

Aug 1, 2011, 3:34 AM

Post #10 of 22 (1203 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rolando.martins at gmail

Aug 1, 2011, 3:45 AM

Post #11 of 22 (1203 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

On Mon, Aug 1, 2011 at 11:34 AM, Mike Galbraith <efault [at] gmx> 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-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


peterz at infradead

Aug 1, 2011, 4:06 AM

Post #12 of 22 (1203 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rolando.martins at gmail

Aug 1, 2011, 4:10 AM

Post #13 of 22 (1205 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

On Mon, Aug 1, 2011 at 12:06 PM, Peter Zijlstra <peterz [at] infradead> 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

>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nando at ccrma

Aug 3, 2011, 11:34 PM

Post #14 of 22 (1204 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


peterz at infradead

Aug 4, 2011, 2:42 AM

Post #15 of 22 (1197 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


tim.sander at hbm

Aug 4, 2011, 9:34 AM

Post #16 of 22 (1200 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 : BUG at kernel/trmutex.c:724! [In reply to]

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-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nando at ccrma

Aug 4, 2011, 12:05 PM

Post #17 of 22 (1201 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


u.kleine-koenig at pengutronix

Aug 4, 2011, 1:15 PM

Post #18 of 22 (1196 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] pengutronix

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/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


u.kleine-koenig at pengutronix

Aug 5, 2011, 2:28 AM

Post #19 of 22 (1187 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] pengutronix
>
> 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/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nando at ccrma

Aug 5, 2011, 9:03 AM

Post #20 of 22 (1166 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] pengutronix
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


linux at bohmer

Aug 7, 2011, 3:44 AM

Post #21 of 22 (1164 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

Hi All,

2011/7/30 Remy Bohmer <linux [at] bohmer>:
> Hi,
>
> 2011/7/30 Remy Bohmer <linux [at] bohmer>:
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nando at ccrma

Aug 8, 2011, 10:25 AM

Post #22 of 22 (1160 views)
Permalink
Re: [ANNOUNCE] 3.0-rt6 [In reply to]

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 [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.