minyard | 28 Jul 23:32 2014
Picon

[PATCH] tracing: Always run per-cpu ring buffer resize with schedule_work_on()

From: Corey Minyard <cminyard <at> mvista.com>

The code for resizing the trace ring buffers has to run the per-cpu
resize on the CPU itself.  The code was using preempt_off() and
running the code for the current CPU directly, otherwise calling
schedule_work_on().

At least on RT this could result in the following:

|BUG: sleeping function called from invalid context at kernel/rtmutex.c:673
|in_atomic(): 1, irqs_disabled(): 0, pid: 607, name: bash
|3 locks held by bash/607:
|CPU: 0 PID: 607 Comm: bash Not tainted 3.12.15-rt25+ #124
|(rt_spin_lock+0x28/0x68)
|(free_hot_cold_page+0x84/0x3b8)
|(free_buffer_page+0x14/0x20)
|(rb_update_pages+0x280/0x338)
|(ring_buffer_resize+0x32c/0x3dc)
|(free_snapshot+0x18/0x38)
|(tracing_set_tracer+0x27c/0x2ac)

probably via
|cd /sys/kernel/debug/tracing/
|echo 1 > events/enable ; sleep 2
|echo 1024 > buffer_size_kb

If we just always use schedule_work_on(), there's no need for the
preempt_off().  So do that.

Reported-by: Stanislav Meduna <stano <at> meduna.org>
(Continue reading)

Michael Jones | 25 Jul 21:27 2014
Picon

[PATCH] cyclictest: remove non-existant short options from --help output

Update the output from 'cyclictest --help' and the man page to reflect
options which only have a long version.

Signed-off-by: Michael Jones <dev <at> michaeljones.de>
---
 src/cyclictest/cyclictest.8 |  2 +-
 src/cyclictest/cyclictest.c | 10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/cyclictest/cyclictest.8 b/src/cyclictest/cyclictest.8
index 4e169aa..dfe2de7 100644
--- a/src/cyclictest/cyclictest.8
+++ b/src/cyclictest/cyclictest.8
 <at>  <at>  -168,7 +168,7  <at>  <at>  task wakeup tracing (used with \-b)
 .B \\-W, \-\-wakeuprt
 rt-task wakeup tracing (used with \-b)
 .TP
-.B \\-y, \-\-policy=NAME
+.B \-\-policy=NAME
 set the scheduler policy of the measurement threads
 where NAME is one of: other, normal, batch, idle, fifo, rr
 .TP
diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index 4547831..51ac56b 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
 <at>  <at>  -999,7 +999,7  <at>  <at>  static void display_help(int error)
 	       "-D       --duration=t      specify a length for the test run\n"
 	       "                           default is in seconds, but 'm', 'h', or 'd' maybe added\n"
 	       "                           to modify value to minutes, hours or days\n"
(Continue reading)

王振兴 | 24 Jul 13:56 2014
Picon

Problem with driver on preempt-rt linux

Hi,everyone!
   I have a problem in testing the driver of my PCI-7841 card on preempt_rt linux. The driver is provided by the
producer of the card.It runs well on regular linux.However, when I run it with preempt_rt linux
kernel,although it's installed with no problem,the data of the can ports receive always have some
errors.It just can't rightly receive the datas I transmit.Is it a driver problem?But I thought driver on
preempt-rt linux should be the same with the regular one.
    Looking forward to the reply.Thanks.             		 	   		  NrybXǧv^)޺{.n+{۬z"^nrzh&Gh(階ݢj"mzޖfh~m
王振兴 | 24 Jul 13:50 2014
Picon

Problem of driver on preempt_rt linux

 		 	   		  NrybXǧv^)޺{.n+{۬z"^nrzh&Gh(階ݢj"mzޖfh~m
Koehrer Mathias (ETAS/ESW5 | 24 Jul 09:36 2014

CLOCK_REALTIME instead of CLOCK_MONOTONIC for PTP coupled RT_PREEMPT systems?

Hi all,

as far as I know is the standard recommendation to use the clock CLOCK_MONOTONIC with e.g. clock_gettime
and clock_nanosleep for real time usage.
I have now the requirement that a couple of (x86) PCs are coupled and synchronized using PTP (linuxptp Project).
The idea of this coupling is that all PCs have always the same (absolute) time stamp (with the PTP accuracy).
For this I have to use the clock CLOCK_REALTIME
instead of CLOCK_MONOTONIC.
What speaks against using CLOCK_REALTIME for the real time application?
Are there any drawbacks? 
With our application I can ensure that no manually set of the time occurs.

Thanks for any feedback on this question.

Mathias

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

Yoann LE BARS | 24 Jul 00:24 2014
Picon

What is to become concerning real time in Linux kernel?


Hello everybody out there!

	As a user of soft real-time Linux kernel, I have some question about
its future.

	During Real Time Linux Workshop in November 2013, developers involved
in the real-time patch have indicated the project will be done in 2014,
“one way or another” (<http://lwn.net/Articles/572740/>). In this
workshop, it has also been said that 95 % of the real-time work was
already upstream.

	The question was how will it be done? In considering that the 95 % is
good enough? Get the rest of the code upstream – which imply an
important effort and several people involved in it? Something between
these two options?

	As SCHED_DEADLINE has been incorporated into Linux 3.14 kernel
(<http://www.phoronix.com/scan.php?page=news_item&px=MTU3Njk>), it seems
to me that it has been decided to get some more code upstream. Still,
the question remains: what way will be the project done?

	Does anyone have any more information about it? As for my part, I
cannot find anything more.

	Regards.

							Yoann
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
(Continue reading)

Steven Rostedt | 17 Jul 17:26 2014

[ANNOUNCE] 3.2.60-rt89


Dear RT Folks,

I'm pleased to announce the 3.2.60-rt89 stable release.

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.2-rt
  Head SHA1: 28dbf3f4acae4140e2b56cfa507f3fe623052269

Or to build 3.2.60-rt89 directly, the following patches should be applied:

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.60-rt89.patch.xz

You can also build from 3.2.60-rt88 by applying the incremental patch:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/incr/patch-3.2.60-rt88-rt89.patch.xz

Enjoy,

-- Steve

Changes from v3.2.60-rt88:

(Continue reading)

Steven Rostedt | 17 Jul 17:24 2014

[ANNOUNCE] 3.12.24-rt38


Dear RT Folks,

I'm pleased to announce the 3.12.24-rt38 stable release.

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: e0c7cbcada84aa70709673b0d0fba0ca5d11cb01

Or to build 3.12.24-rt38 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.24.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.24-rt38.patch.xz

You can also build from 3.12.24-rt37 by applying the incremental patch:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/incr/patch-3.12.24-rt37-rt38.patch.xz

Enjoy,

-- Steve

Changes from v3.12.24-rt37:

(Continue reading)

Koehrer Mathias (ETAS/ESW5 | 16 Jul 08:11 2014

Achievable latency with USB I/O and RT_PREEMPT?

Hi all,

we are running RT_PREEMPT on a standard x86 PC which works really fine.
Our I/O is so far mainly done via PCI/PCIe boards which works fine as well.
Now there is an idea to do some special I/O using USB (2.0) microcontrollers (e.g. something like the
Arduino Lenorado - AVR ATmega32U4) that are connected to the PC.
The requirement is that we are able to transfer data (about 40 byte per direction) between the PC and the
microcontroller once per millisecond.
Might this be achievable?
Is there anybody who has experience with this kind of setup?
What are the typical latencies/jitter on the microcontroller side that are to be expected?
What effect on the latency/jitter does it have if multiple microcontrollers are connected via an USB hub to
the PC?

Thank you very much for all help on this questions.

Best regards

Mathias
--
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

Steven Rostedt | 14 Jul 22:06 2014

[PATCH RT 0/4] Linux 3.2.60-rt89-rc1


Dear RT Folks,

This is the RT stable review cycle of patch 3.2.60-rt89-rc1.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the
final release is.

If all goes well, this patch will be converted to the next main release
on 7/17/2014.

Enjoy,

-- Steve

To build 3.2.60-rt89-rc1 directly, the following patches should be applied:

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.60-rt89-rc1.patch.xz

You can also build from 3.2.60-rt88 by applying the incremental patch:

(Continue reading)

Steven Rostedt | 14 Jul 22:03 2014

[PATCH RT 0/3] Linux 3.12.24-rt38-rc1


Dear RT Folks,

This is the RT stable review cycle of patch 3.12.24-rt38-rc1.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the
final release is.

If all goes well, this patch will be converted to the next main release
on 7/17/2014.

Enjoy,

-- Steve

To build 3.12.24-rt38-rc1 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.24.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.24-rt38-rc1.patch.xz

You can also build from 3.12.24-rt37 by applying the incremental patch:

(Continue reading)


Gmane