Stanislav Meduna | 18 Apr 22:36 2014

tracing: BUG: sleeping function called from invalid context


tracing the irqsoff latency - not sure what exactly was that,
maybe tracing_on, maybe current_tracer:

BUG: sleeping function called from invalid context at /home/stano/Kernels/linux-3.12-rt/kernel/rtmutex.c:673
in_atomic(): 1, irqs_disabled(): 0, pid: 607, name: bash
3 locks held by bash/607:
 #0:  (sb_writers#8){......}, at: [<c00de6f4>] vfs_write+0x1cc/0x1d0
 #1:  (trace_types_lock){......}, at: [<c0087764>] tracing_set_tracer+0x1c/0x2ac
 #2:  (&buffer->mutex#2){......}, at: [<c0080220>] ring_buffer_resize+0xac/0x3dc
Preemption disabled at:[<  (null)>]   (null)

CPU: 0 PID: 607 Comm: bash Not tainted 3.12.15-rt25+ #124
[<c0015210>] (unwind_backtrace+0x0/0xfc) from [<c0013030>] (show_stack+0x18/0x1c)
[<c0013030>] (show_stack+0x18/0x1c) from [<c02f7010>] (rt_spin_lock+0x28/0x68)
[<c02f7010>] (rt_spin_lock+0x28/0x68) from [<c00aa468>] (free_hot_cold_page+0x84/0x3b8)
[<c00aa468>] (free_hot_cold_page+0x84/0x3b8) from [<c007cb2c>] (free_buffer_page+0x14/0x20)
[<c007cb2c>] (free_buffer_page+0x14/0x20) from [<c00800bc>] (rb_update_pages+0x280/0x338)
[<c00800bc>] (rb_update_pages+0x280/0x338) from [<c00804a0>] (ring_buffer_resize+0x32c/0x3dc)
[<c00804a0>] (ring_buffer_resize+0x32c/0x3dc) from [<c0087530>] (free_snapshot+0x18/0x38)
[<c0087530>] (free_snapshot+0x18/0x38) from [<c00879c4>] (tracing_set_tracer+0x27c/0x2ac)
[<c00879c4>] (tracing_set_tracer+0x27c/0x2ac) from [<c0087a4c>] (tracing_set_trace_write+0x58/0x114)
[<c0087a4c>] (tracing_set_trace_write+0x58/0x114) from [<c00de5f4>] (vfs_write+0xcc/0x1d0)
[<c00de5f4>] (vfs_write+0xcc/0x1d0) from [<c00de7d8>] (SyS_write+0x4c/0x78)
[<c00de7d8>] (SyS_write+0x4c/0x78) from [<c000f4a0>] (ret_fast_syscall+0x0/0x44)


(Continue reading)

Stanislav Meduna | 17 Apr 22:38 2014

i.MX28 milliseconds latencies, interrupts disabled in arch_cpu_idle?


on a i.MX28:

Linux nxt 3.12.15-rt25+ #83 PREEMPT RT Thu Apr 17 20:54:00 CEST 2014 armv5tejl GNU/Linux

# tracer: irqsoff
# irqsoff latency trace v1.1.5 on 3.12.15-rt25+
# --------------------------------------------------------------------
# latency: 2224 us, #6/6, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0)
#    -----------------
#    | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
#    -----------------
#  => started at: rcu_idle_enter
#  => ended at:   arch_cpu_idle
#                   _--------=> CPU#
#                  / _-------=> irqs-off
#                 | / _------=> need-resched
#                 || / _-----=> need-resched_lazy
#                 ||| / _----=> hardirq/softirq
#                 |||| / _---=> preempt-depth
#                 ||||| / _--=> preempt-lazy-depth
#                 |||||| / _-=> migrate-disable
#                 ||||||| /     delay
#  cmd     pid    |||||||| time  |   caller
#     \   /      ||||||||  \   |   /
  <idle>-0       0d...1..    2us+: rcu_idle_enter
(Continue reading)

Stanislav Meduna | 16 Apr 16:46 2014

w1-gpio: sleeping function called from invalid context


trying 1-wire with rt-patched Linux 3.12.15-rt25+ and lock debugging:

[   12.055550] BUG: sleeping function called from invalid context at /home/stano/Kernels/linux-3.12-rt/kernel/rtmutex.c:673
[   12.055573] in_atomic(): 0, irqs_disabled(): 128, pid: 92, name: w1_bus_master1
[   12.055588] 2 locks held by w1_bus_master1/92:
[   12.055675]  #0:  (&dev->mutex){+.+...}, at: [<c0233560>] w1_process+0xbc/0xe0
[   12.055729]  #1:  (&dev->bus_mutex){+.+...}, at: [<c0232a50>] w1_search+0x78/0x1e8
[   12.055741] irq event stamp: 374
[   12.055787] hardirqs last  enabled at (373): [<c02e04cc>] _raw_spin_unlock_irqrestore+0x6c/0x74
[   12.055815] hardirqs last disabled at (374): [<c0234598>] w1_touch_bit+0x50/0xc4
[   12.055860] softirqs last  enabled at (0): [<c001bacc>] copy_process+0x37c/0x1178
[   12.055876] softirqs last disabled at (0): [<  (null)>]   (null)
[   12.055899] CPU: 0 PID: 92 Comm: w1_bus_master1 Not tainted 3.12.15-rt25+ #66
[   12.055973] [<c00151bc>] (unwind_backtrace+0x0/0xf4) from [<c0012c00>] (show_stack+0x10/0x14)
[   12.056020] [<c0012c00>] (show_stack+0x10/0x14) from [<c02df920>] (rt_spin_lock+0x20/0x60)
[   12.056080] [<c02df920>] (rt_spin_lock+0x20/0x60) from [<c01bc98c>] (gpiod_direction_output+0x50/0x2fc)
[   12.056122] [<c01bc98c>] (gpiod_direction_output+0x50/0x2fc) from [<c02345ac>] (w1_touch_bit+0x64/0xc4)
[   12.056156] [<c02345ac>] (w1_touch_bit+0x64/0xc4) from [<c0234794>] (w1_write_8+0x54/0x7c)
[   12.056196] [<c0234794>] (w1_write_8+0x54/0x7c) from [<c0232a78>] (w1_search+0xa0/0x1e8)
[   12.056239] [<c0232a78>] (w1_search+0xa0/0x1e8) from [<c0233414>] (w1_search_process_cb+0x50/0xe0)
[   12.056280] [<c0233414>] (w1_search_process_cb+0x50/0xe0) from [<c0233570>] (w1_process+0xcc/0xe0)
[   12.056334] [<c0233570>] (w1_process+0xcc/0xe0) from [<c003cf24>] (kthread+0xa0/0xa8)
[   12.056379] [<c003cf24>] (kthread+0xa0/0xa8) from [<c000f3e0>] (ret_from_fork+0x14/0x34)

This happens reproducibly on any access.

Please Cc: me when replying

(Continue reading)

Rob Connolly | 16 Apr 00:09 2014

Freezing issue on loading/usage of kernel modules


I am attempting to use the rt patch set on an OpenWRT MIPS based system
(ar71xx). I'm having some issues loading/using certain kernel modules,
specifically for ethernet and USB support. The symptoms I am
experiencing are:

1. The system will freeze completely after loading the usb modules
(manually with insmod). Specifically this is after loading
ehci_platform. The system appears to detect the hardware and then lock
up, it is then rebooted by the watchdog a few seconds later. See below:

root <at> OpenWrt:/# insmod /lib/modules/3.10.32/nls_base.ko
root <at> OpenWrt:/# insmod /lib/modules/3.10.32/nls_base.procd: -
root <at> OpenWrt:/# insmod /lib/modules/3.10.32/usb-common.ko
root <at> OpenWrt:/# insmod /lib/modules/3.10.32/usbcore.ko
[   51.150000] usbcore: registered new interface driver usbfs
[   51.160000] usbcore: registered new interface driver hub
[   51.160000] usbcore: registered new device driver usb
root <at> OpenWrt:/# insmod /lib/modules/3.10.32/ehci-hcd.ko
[   58.850000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
root <at> OpenWrt:/# insmod /lib/modules/3.10.32/ohci-hcd.ko
[   65.730000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
root <at> OpenWrt:/# insmod /lib/modules/3.10.32/ehci-platform.ko
[   77.830000] ehci-platform: EHCI generic platform driver
[   77.830000] ehci-platform ehci-platform: EHCI Host Controller
[   77.840000] ehci-platform ehci-platform: new USB bus registered,
assigned bus number 1
[   77.850000] ehci-platform ehci-platform: irq 3, io mem 0x1b000000
[   77.880000] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00
(Continue reading)

John Kacur | 15 Apr 16:28 2014

RFC: SIGUSR1 to stderr

We usually do testing by running cyclictest laucned via rteval. It
would be nice to get status updates from cyclictest in the middle of
long runs (sometimes days long). cyclictest already has the capability
to do this via SIGUSR1.

It would be useful for rteval parsing of SIGUSR1 output if this were
directed to stderr. I could make this the default, but don't want to
do this if it would interfere with the way anyone else is doing
testing. If this would cause a problem for you, I'll just make it an

So, please let me know if this change would cause problems for you.


To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at>
More majordomo info at

Stanislav Meduna | 14 Apr 21:24 2014

BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25


hunting another problem with AUART acting weirdly I got

BUG: spinlock trylock failure on UP on CPU#0, ksoftirqd/0/3
 lock: boot_tvec_bases+0x0/0x10a0, .magic: dead4ead, .owner: ksoftirqd/0/3, .owner_cpu: 0
CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.12.15-rt25-00371-gfec62f5-dirty #26
[<c00149ec>] (unwind_backtrace+0x0/0xf4) from [<c0012ab0>] (show_stack+0x10/0x14)
[<c0012ab0>] (show_stack+0x10/0x14) from [<c01a4b80>] (do_raw_spin_trylock+0x4c/0x58)
[<c01a4b80>] (do_raw_spin_trylock+0x4c/0x58) from [<c02ca0b4>] (_raw_spin_trylock+0x20/0x98)
[<c02ca0b4>] (_raw_spin_trylock+0x20/0x98) from [<c02c9654>] (rt_spin_trylock+0x14/0xd0)
[<c02c9654>] (rt_spin_trylock+0x14/0xd0) from [<c00285cc>] (run_local_timers+0x24/0x78)
[<c00285cc>] (run_local_timers+0x24/0x78) from [<c0028654>] (update_process_times+0x34/0x68)
[<c0028654>] (update_process_times+0x34/0x68) from [<c005f0ac>] (tick_sched_timer+0x58/0x22c)
[<c005f0ac>] (tick_sched_timer+0x58/0x22c) from [<c003f2f8>] (__run_hrtimer+0x7c/0x2a8)
[<c003f2f8>] (__run_hrtimer+0x7c/0x2a8) from [<c003f684>] (hrtimer_interrupt+0x104/0x30c)
[<c003f684>] (hrtimer_interrupt+0x104/0x30c) from [<c0230a84>] (mxs_timer_interrupt+0x20/0x2c)
[<c0230a84>] (mxs_timer_interrupt+0x20/0x2c) from [<c0051d1c>] (handle_irq_event_percpu+0x80/0x2f8)
[<c0051d1c>] (handle_irq_event_percpu+0x80/0x2f8) from [<c0051fd0>] (handle_irq_event+0x3c/0x5c)
[<c0051fd0>] (handle_irq_event+0x3c/0x5c) from [<c0054778>] (handle_level_irq+0x8c/0x118)
[<c0054778>] (handle_level_irq+0x8c/0x118) from [<c0051c8c>] (generic_handle_irq+0x28/0x30)
[<c0051c8c>] (generic_handle_irq+0x28/0x30) from [<c001009c>] (handle_IRQ+0x30/0x84)
[<c001009c>] (handle_IRQ+0x30/0x84) from [<c0013324>] (__irq_svc+0x44/0x88)
[<c0013324>] (__irq_svc+0x44/0x88) from [<c006a664>] (__try_to_take_rt_mutex+0x4/0x144)
[<c006a664>] (__try_to_take_rt_mutex+0x4/0x144) from [<00000000>] (  (null))

Linux nxt 3.12.15-rt25-00371-gfec62f5-dirty #26 PREEMPT RT Mon Apr 14 20:40:56 CEST 2014 armv5tejl GNU/Linux

This is on a Freescale i.MX28, 3.12.15-rt25 with patches that do not touch
anything related.
(Continue reading)

Daniel Wagner | 14 Apr 16:22 2014

[RFC v0] thermal: Protect schedule flag by raw spin

From: Daniel Wagner <daniel.wagner <at>>

pkg_work_lock is used to serialize the access to pkg_work_scheduled.
pkg_temp_thermal_device_add() reallocates pkg_work_scheduled when
CPUs are added (When they are removed, pkg_work_scheduled wont
be updated). Since pkg_work_scheduled accessed from the interrupt
context spin_lock_irqsave() is the right thing on mainline to use.

On RT the spin lock is a mutex and therefore we should not sleep
in the irq context:

[<ffffffff816850ac>] dump_stack+0x4e/0x8f
[<ffffffff81680f7d>] __schedule_bug+0xa6/0xb4
[<ffffffff816896b4>] __schedule+0x5b4/0x700
[<ffffffff8168982a>] schedule+0x2a/0x90
[<ffffffff8168a8b5>] rt_spin_lock_slowlock+0xe5/0x2d0
[<ffffffff8168afd5>] rt_spin_lock+0x25/0x30
[<ffffffffa03a7b75>] pkg_temp_thermal_platform_thermal_notify+0x45/0x134 [x86_pkg_temp_thermal]
[<ffffffff8103d4db>] ? therm_throt_process+0x1b/0x160
[<ffffffff8103d831>] intel_thermal_interrupt+0x211/0x250
[<ffffffff8103d8c1>] smp_thermal_interrupt+0x21/0x40
[<ffffffff8169415d>] thermal_interrupt+0x6d/0x80

Again, this is a bug on mainline.

I didn't find a good way to get rid of the krealloc in
pkg_temp_thermal_device_add(). Instead using krealloc I dropped
to an open coded version so that the alloc is outside of

(Continue reading)

jordan | 13 Apr 17:50 2014

WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

Hey list.

1. So after finally having some time off of work [after a busy couple
of months] i have come back to trying to sort out linux-rt on my AMD
PHenom II 965 system - which had failed to boot post 3.12.5-rt7

first, i need to make a correction -rt8 DID boot fine and was stable
[after one/initial lockup, it never locked again, and obviously booted
fine.]. but i figured this out, only after doing a git-bisect on -rt7
to -rt8 ... and never got around to testing -rt8 to -rt9... However, I
decided to give 3.14-rt a run - and again - ended up with the machine
failing to boot... Next, i decided to revert all three of the patches
that you pointed out Sebastion;

| timers-do-not-raise-softirq-unconditionally.patch
| timer-Raise-softirq-if-there-s-irq_work.patch
| timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch

well, what i actually ended up doing was reverting the first and
modifying the 1st patch to revert the other two patches (by changing
../kernel/timer.c section of the original patch). [ i reverted after
applying the linux-rt patch, not split queue];

[ninez <at> localhost ~]$ uname -a
Linux localhost 3.14.0-rt1-1-l-pa #1 SMP PREEMPT RT Sun Apr 13
10:44:19 EDT 2014 x86_64 GNU/Linux

I've been running 3.14-rt for a couple of hours now and it appears to
be stable, thus far - without those patches/fixes applied [and
(Continue reading)

Sebastian Andrzej Siewior | 30 Mar 20:46 2014

[ANNOUNCE] 3.12.15-rt25

Dear RT folks!

I'm pleased to announce the v3.12.15-rt25 patch set.

Changes since v3.12.15-rt24
- Two patches for the gianfar network driver. One fixes a deadlock /
  lockup which is only available on -RT and probably since v3.10. The
  other is the removal of local_irq_save() statemens which should not be
  used on -RT.

- A small optimization from Nicholas Mc Guire where cpumask_weight() can
  be avoided because the outcome is known.

Known issues:

      - bcache is disabled.

The delta patch against v3.12.15-rt24 is appended below and can be found

The RT patch against 3.12.15 can be found here:

The split quilt queue is available at:

(Continue reading)

Buford Gonalez | 28 Mar 10:36 2014


r labours

To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at>
More majordomo info at

Gary S. Robertson | 26 Mar 00:05 2014

[PATCH 0/2] cyclictest: Restore CPU affinity for non-NUMA builds

From: "Gary S. Robertson" <gary.robertson <at>>

These patches restore the ability to use the legacy CPU affinity functionality in cyclictest when built
without NUMA support.  When cyclictest was patched to add bitmask CPU affinity support with NUMA V2, it
broke the existing CPU affinity support for non-NUMA builds.  That patch mapped the legacy CPU affinity
behavior (choosing a single core or else all cores) onto the bit-mapped framework when cyclictest was
built against NUMA V1 libraries.  I simply extended this mapping to include also the case where cyclictest
was built with no NUMA support.

Unfortunately the addition of the extra conditional compilation clauses into the function definitions
from that patch made the resulting source code difficult to follow - so I also re-organized the code to make
the end result more understandable.  I simply created conditional compilation clauses for the three
NUMA-related build configurations (V2, V1, or none).  Then I created separate clean function
definitions for each configuration... an extension of the method already used for the non-NUMA
configuration case..

The restructuring of the code makes the patch containing changes to rt_numa.h difficult to follow.  If you
prefer I can re-work these changes as three patches instead of two... splitting the rt_numa.h patch into
one patch which re-organizes the code and a second which applies the changes that fix the CPU affinity bug.

Gary S. Robertson (2):
  Restore CPU affinity function for non-NUMA builds
  Don't offer --numa option when unavailable

 src/cyclictest/cyclictest.c |    2 +
 src/cyclictest/rt_numa.h    |  188 +++++++++++++++++++++++++++----------------
 2 files changed, 121 insertions(+), 69 deletions(-)


(Continue reading)