Steven Rostedt | 26 Nov 21:26 2014

[ANNOUNCE] 3.12.33-rt47


Dear RT Folks,

I'm pleased to announce the 3.12.33-rt47 stable release.

This release is just an update to the new stable 3.12.33 version
and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.12-rt
  Head SHA1: baa6dfd452fd1af7d4ee2a329d6437523add8364

Or to build 3.12.33-rt47 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.12.33.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.33-rt47.patch.xz

Enjoy,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

"Jürgen Lanner" | 19 Nov 13:43 2014
Picon
Picon

Measuring scheduling latency for RT threads

I have a complex automation project with makes heavy use of real time prio threads working with external
hardware connected by e.g. TCP/IP.
IMHO most of my latencies simply come from the fact that there are multiple threads running on the same RT
prio being scheduled FIFO. (poor design, yes, but that's what I want to fix)
Expected response time is in low millsecond area, so no miroseconds juggling here.
The process is running (alone, no other processes there) on one CPU of an i5 quad core (using 3.13.0-35
ubuntu 14.04)
 
My first goal is to find out about the worst case latency:
Is there a way I can find out how long (worst case) a RT thread being ready to run is just waiting to be
dispatched?  
I tried /proc/pid/sched and was looking for se.statistics.wait_max but this was always 0.
Going through the kernel sources I found out that these value (among many of the neighbors) is not
calculated for real time threads (rt.c).
Is there a reason for this?
Is there another, maybe better way how I can achieve my goal?
 
My second goal would be to identify the tasks (which ones?) consuming so much time (how much?) in this
situation and thus causing the delay.
Is there something built in to track down these bad guys?
I think of something that keeps capturing the PIDs and exec time of all dispatched threads while a thread is waiting.
If it turns out that it runs into worst case latency, the collected data could give a hint where to dig.
On proc/pid/sched there is se.statistics.exec_max, some thread having a large number there can be a
candidate, yes, but that is not necessarily causing my latency..  
But I think more of a bad situation where a lot of tasks need to work at the same time bloating the run queue and
thus causing the latency.
I feel my solution is more "intelligent workload distribution" by identifying not so urgent work and
shifting it to a later point in time.
 
Thanks in advance
(Continue reading)

Lampersperger Andreas | 18 Nov 10:11 2014
Picon

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

Hello,

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!
Andreas

------------------------------------------------------------------------------------------------------
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: http://www.heidenhain.de/disclaimer
NrybXǧv^)޺{.n+{۬z"^nrzh&Gh(階ݢj"mzޖfh~m
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> redhat.com>

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> redhat.com>
---
 src/cyclictest/cyclictest.8 |    3 ++-
 src/cyclictest/cyclictest.c |   34 ++++++++++++++++++++++++++++++++++
(Continue reading)

Marc Marí | 8 Nov 23:56 2014
Picon

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
handle_irq_event_percpu+0x2d8/0x2fc()
[    5.087378] irq 305 handler
irq_default_primary_handler+0x0/0x1c enabled interrupts
[    5.095008]
[<c010dc4c>] (unwind_backtrace+0x0/0x144) from [<c0a4e8e0>]
(dump_stack+0x20/0x24)
[    5.103600] [<c0a4e8e0>]
(dump_stack+0x20/0x24) from [<c01939e8>]
(warn_slowpath_common+0x58/0x70)
[    5.112548] [<c01939e8>]
(warn_slowpath_common+0x58/0x70) from [<c0193a7c>]
(warn_slowpath_fmt+0x40/0x48)
[    5.122100] [<c0193a7c>]
(warn_slowpath_fmt+0x40/0x48) from [<c01fa66c>]
(handle_irq_event_percpu+0x2d8/0x2fc)
[    5.132077] [<c01fa66c>]
(handle_irq_event_percpu+0x2d8/0x2fc) from [<c01fa718>]
(handle_irq_event+0x88/0xb0)
[    5.141975] [<c01fa718>]
(handle_irq_event+0x88/0xb0) from [<c01fd50c>]
(handle_level_irq+0xbc/0x15c)
[    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
enabled.

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
Oops[#1]:
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> gmail.com> wrote:

> On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <umgwanakikbuti <at> gmail.com>
> 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 http://lwn.net/Articles/617140/ 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: https://lkml.org/lkml/2014/4/8/584
> 
> 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
Picon

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

Hi,

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
	patches?

  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
Picon

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

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 
apic->send_IPI_all(NMI_VECTOR);

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

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

Matthias Klein | 29 Oct 11:10 2014
Picon

Latest development tree

Hello,

where canI find the lastest development of the PREEMPT_RT patch?

At https://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/ 
are only the stable releases, right?

Best regards,
Matthias

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


Gmane