Lampersperger Andreas | 18 Nov 10:11 2014

How to modify priority uart/serial interrupt on 3.14.23-rt20?


does anyone have a hint how modify (increase) the priority of 
the serial/uart interrupt on a 3.14.23-rt20 kernel?

AFAIK the kernel thread for serial communication is created 
when the communication starts, but I want to change the
priority when the driver loads (modprobe 8250).

Thank's for your help!

Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office: Traunreut
Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard
Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm

E-Mail Haftungsausschluss / E-Mail Disclaimer:
Arnaldo Carvalho de Melo | 13 Nov 16:12 2014

[PATCH 1/1] cyclictest: Allow passing a list of cpus to affine threads to

From: Arnaldo Carvalho de Melo <acme <at>>

For testing, for instance, running one thread per cpu in a CPU socket,
testing isolation of groups of cores that share memory cache.

[root <at> emilia ~]# ~acme/bin/cyclictest -nmu -p95 -a 1,3,5,7
policy: fifo: loadavg: 0.00 0.17 2.48 2/409 25640

T: 0 (25636) P:95 I:1000 C:  15503 Min:   4 Act:  4 Avg:  4 Max:  8
T: 1 (25637) P:95 I:1500 C:  10331 Min:   4 Act:  4 Avg:  4 Max:  7
T: 2 (25638) P:95 I:2000 C:   7745 Min:   4 Act:  4 Avg:  4 Max:  8
T: 3 (25639) P:95 I:2500 C:   6193 Min:   3 Act:  4 Avg:  4 Max:  8

[root <at> emilia ~]# tuna -t cyclictest -CP
                      thread       ctxt_switches
    pid SCHED_ rtpri affinity voluntary nonvoluntary            cmd
 25635    FIFO     2  0,2,4,6       449           16     cyclictest
  25636   FIFO    95        1      4471            1     cyclictest
  25637   FIFO    95        3      2977            1     cyclictest
  25638   FIFO    95        5      2230            1     cyclictest
  25639   FIFO    95        7      1782            1     cyclictest
[root <at> emilia ~]#

And generally to allow starting multiple threads spread over non
contiguous CPUs.

Signed-off-by: Arnaldo Carvalho de Melo <acme <at>>
 src/cyclictest/cyclictest.8 |    3 ++-
 src/cyclictest/cyclictest.c |   34 ++++++++++++++++++++++++++++++++++
(Continue reading)

Marc Marí | 8 Nov 23:56 2014

Solving WARNING: Enabled interrupts issues

Hello everyone

I'm working in the porting of a platform-specific linux kernel to RT. I
think I'm in the right way, but I'm looking on the best approach to
solve issues with IRQS in drivers.

At this moment I have this warning:
[    5.079524] WARNING: at kernel/irq/handle.c:146
[    5.087378] irq 305 handler
irq_default_primary_handler+0x0/0x1c enabled interrupts
[    5.095008]
[<c010dc4c>] (unwind_backtrace+0x0/0x144) from [<c0a4e8e0>]
[    5.103600] [<c0a4e8e0>]
(dump_stack+0x20/0x24) from [<c01939e8>]
[    5.112548] [<c01939e8>]
(warn_slowpath_common+0x58/0x70) from [<c0193a7c>]
[    5.122100] [<c0193a7c>]
(warn_slowpath_fmt+0x40/0x48) from [<c01fa66c>]
[    5.132077] [<c01fa66c>]
(handle_irq_event_percpu+0x2d8/0x2fc) from [<c01fa718>]
[    5.141975] [<c01fa718>]
(handle_irq_event+0x88/0xb0) from [<c01fd50c>]
[    5.151144] [<c01fd50c>]
(Continue reading)

Yang Shi | 7 Nov 00:45 2014

[PATCH v3.14-rt] mips: rt: Replace pagefault_* to raw version

In k{un}map_coherent, pagefault_disable and pagefault_enable are called
respectively, but k{un}map_coherent needs preempt disabled according to
commit f8829caee311207afbc882794bdc5aa0db5caf33 ("[MIPS] Fix aliasing bug
in copy_to_user_page / copy_from_user_page") to avoid dcache alias on COW.

k{un}map_coherent are just called when cpu_has_dc_aliases == 1 with VIPT cache.
However, actually, the most modern MIPS processors have PIPT dcache without
dcache alias issue. In such case, k{un}map_atomic will be called with preempt

To fix this, we replace pagefault_* to raw version in k{un}map_coherent, which
disables preempt, otherwise the following kernel panic may be caught:

CPU 0 Unable to handle kernel paging request at virtual address fffffffffffd5000, epc ==
ffffffff80122c00, ra == ffffffff8011fbcc
CPU: 0 PID: 409 Comm: runltp Not tainted 3.14.17-rt5 #1
task: 980000000fa936f0 ti: 980000000eed0000 task.ti: 980000000eed0000
$ 0 : 0000000000000000 000000001400a4e1 fffffffffffd5000 0000000000000001
$ 4 : 980000000cded000 fffffffffffd5000 980000000cdedf00 ffffffffffff00fe
$ 8 : 0000000000000000 ffffffffffffff00 000000000000000d 0000000000000004
$12 : 980000000eed3fe0 000000000000a400 ffffffffa00ae278 0000000000000000
$16 : 980000000cded000 000000726eb855c8 98000000012ccfe8 ffffffff8095e0c0
$20 : ffffffff80ad0000 ffffffff8095e0c0 98000000012d0bd8 980000000fb92000
$24 : 0000000000000000 ffffffff80177fb0
$28 : 980000000eed0000 980000000eed3b60 980000000fb92060 ffffffff8011fbcc
Hi : 000000000002cb02
Lo : 000000000000ee56
epc : ffffffff80122c00 copy_page+0x38/0x548
    Not tainted
(Continue reading)

Steven Rostedt | 5 Nov 15:27 2014

Re: [ANNOUNCE] 3.14.23-rt20

On Wed, 5 Nov 2014 14:50:41 +0100
Juerg Haefliger <juergh <at>> wrote:

> On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <umgwanakikbuti <at>>
> wrote:
> >
> > On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
> > > Dear RT Folks,
> > >
> > > I'm pleased to announce the 3.14.23-rt20 stable release.
> > >
> > > This is the first 3.14-rt release in the stable-rt series. Normally I
> > > wait till the next development release is out before I pull in a new
> > > one. That is, I would pull in 3.14-rt when 3.16-rt or later was
> > > released. But because development is now moving at a "hobbyist rate"
> > > (read for details)
> > > and 3.14-rt is no longer being developed against, I figured it was
> > time
> > > to put it under the "stable-rt" umbrella.
> >
> > I piddled about with it yesterday, found that you can't change cpufreq
> > governor IFF the tree is configured as rt, but works fine as voluntary
> > preempt.
> The problem seems to be this patch:
> The cpufreq code does nested down_read_trylocks and only the first one
> succeeds:
> drivers/cpufreq/cpufreq.c:
(Continue reading)

Daniel Wagner | 5 Nov 10:09 2014

[RFC v0 0/9] [RFC v0 0/9] pi_stress: Add SCHED_DEADLINE support


I wrote a small test program to play around with SCHED_DEADLINE which
triggered various PI related crashes. Steven convinced me to get
the test somehow upstream. I figured pi_stress is very simular with my
test program. So here my attempt to merge the essence of my test
into pi_stress.c

  patch 1: hackbench: Don't re-assign context for each fd
  patch 2: rt-tests.h: Remove unused header file
  patch 3: pi_stress: Remove unused TIMER_SIGNAL definition

	Not really related to this series. Just found it while
	browsing the code a bit. Are you interested in such

  patch 4: error: Add debug() function
  patch 5: pi_stress: Use error.h for logging and debugging

	I didn't want to add the sched_setattr() code directly
	to pi_stress.c. As soon rt-utils.h is used you get also
	error.h which brings info() and friends it collides
	in pi_stress.c.
	Several other tests also implement info() and friends.
	Would it make sense to convert them using error.h too?
	Then I would also suggest to get --verbose and
	--debug options handled in a central way. Maybe something
	like the GLib does with parsing the argc first and hanlding
	those flags. What do you think?

(Continue reading)

Chanchal Paul | 4 Nov 12:39 2014

RT Kernel compile and install help needed.

I am fairly new to kernel compilation and installation process, still
i managed to learn from Kernelnewbies and RT-wiki and managed to patch
3.12.14 vanilla kernel with rt patch 3.14.12. Then I followed the
steps and installed rt-kernel in my lubuntu vm. While doing make
menuconfig, i selected preemtion model as BASIC-RT from processor type
and features option. It worked.

Now my confusion arises when i see my uname -a string as [Linux
paul-lubuntu 3.14.12-rt9 #2 SMP PREEMPT Tue Oct 28 13:30:27 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux] which indicated that i have a
preemptive kernel installed. but the c program from RT_PREEMPT_HOWTO
section of RTwiki website for Runtime detection of an RT-PREEMPT
Kernel only prints [this is a vanilla kernel]. So, my question is am I
running a vanilla kernel or a real-time kernel? If I am not then what
are the steps to properly install a real-time kernel?

Thanking you for giving attention to my mail.
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

Chris Friesen | 3 Nov 22:08 2014

which kernel thread handles NMIs?

We're running with the 3.4 kernel with RT patch, and we're trying to 
debug some issues.

One of the issues is that the magic sysrq "l" command to show a stack 
backtrace on all CPUs doesn't seem to work, though other magic sysrq 
commands do work properly.

Looking at the code, for X86 it seems to call 

Does anyone know what kernel thread would handle NMI_VECTOR?  I want to 
make sure its priority is sufficiently high.

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

Matthias Klein | 29 Oct 11:10 2014

Latest development tree


where canI find the lastest development of the PREEMPT_RT patch?

are only the stable releases, right?

Best regards,

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

Chris Friesen | 23 Oct 21:27 2014

semantics of reader/writer semaphores in rt patch

I recently noticed that when CONFIG_PREEMPT_RT_FULL is enabled we the 
semantics change.  From "include/linux/rwsem_rt.h":

  * Note that the semantics are different from the usual
  * Linux rw-sems, in PREEMPT_RT mode we do not allow
  * multiple readers to hold the lock at once, we only allow
  * a read-lock owner to read-lock recursively. This is
  * better for latency, makes the implementation inherently
  * fair and makes it simpler as well.

How is this valid?  It seems to me that there are any number of code 
paths that could depend on having multiple threads of execution be able 
to hold the reader lock simultaneously.  Something as simple as:

thread A:
take rw_semaphore X for reading
take lock Y, modify data, release lock Y
wake up thread B
wait on conditional protected by lock Y
free rw_semaphore X

thread B:
take rw_semaphore X for reading
wait on conditional protected by lock Y
send message to wake up thread A
free rw_semaphore X

In the regular kernel this would work, in the RT kernel it would deadlock.

Does the RT kernel just disallow this sort of algorithm?
(Continue reading)

Chris Friesen | 23 Oct 19:54 2014

RT/ext4/jbd2 circular dependency (was: Re: Hang writing to nfs-mounted filesystem from client)

On 10/17/2014 12:55 PM, Austin Schuh wrote:
> Use the 121 patch.  This sounds very similar to the issue that I helped
> debug with XFS.  There ended up being a deadlock due to a bug in the
> kernel work queues.  You can search the RT archives for more info.

I can confirm that the problem still shows up with the rt121 patch. (And
also with Paul Gortmaker's proposed 3.4.103-rt127 patch.)

We added some instrumentation and it looks like we've tracked down the problem.
Figuring out how to fix it is proving to be tricky.

Basically it looks like we have a circular dependency involving the
inode->i_data_sem rt_mutex, the PG_writeback bit, and the BJ_Shadow list.  It
goes something like this:

1) set page for writeback (set PG_writeback bit)
2) put jbd2 journal head on BJ_Shadow list
3) sleep on PG_writeback bit waiting for page writeback complete

1) ext4_map_blocks() acquires inode->i_data_sem for writing
2) do_get_write_access() sleeps waiting for jbd2 journal head to come off
the BJ_Shadow list

At this point the flush code can't run because it can't acquire
inode->i_data_sem for reading, so the page will never get written out.

The following is a more detailed timeline with information from added trace
(Continue reading)