Steven Rostedt | 2 Jul 21:26 2015

[ANNOUNCE] 3.10.82-rt89


Dear RT Folks,

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

This release is just an update to the new stable 3.10.82 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.10-rt
  Head SHA1: 0105c1a272a274c85a88a4b67a3d7970e276d16b

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

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.82-rt89.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)

Steven Rostedt | 2 Jul 21:26 2015

[ANNOUNCE] 3.14.46-rt46


Dear RT Folks,

I'm pleased to announce the 3.14.46-rt46 stable release.

This release is just an update to the new stable 3.14.46 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.14-rt
  Head SHA1: 89d1d11dfe34c925932467de4d0ed231b0e22b4f

Or to build 3.14.46-rt46 directly, the following patches should be applied:

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.14/patch-3.14.46-rt46.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)

Steven Rostedt | 2 Jul 21:25 2015

[ANNOUNCE] 3.18.17-rt14


Dear RT Folks,

I'm pleased to announce the 3.18.17-rt14 stable release.

This release is just an update to the new stable 3.18.17 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.18-rt
  Head SHA1: bba903c2bb20dbb6c57a8ba3889f9b8f09dcc6e0

Or to build 3.18.17-rt14 directly, the following patches should be applied:

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.17-rt14.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)

Luis Claudio R. Goncalves | 25 Jun 17:09 2015

[4.0.5-rt4] i915: sleeping function called from invalid context at intel_pipe_update_start/end

Hi!

I have been seeing the annoying message below non-stop: 

i915: sleeping function called from invalid context at intel_pipe_update_start/end

[drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
fbcon: inteldrmfb (fb0) is primary device
BUG: sleeping function called from invalid context at /home/lclaudio/SANDBOX/mrg-rt-v2-devel/kernel/locking/rtmutex.c:917
in_atomic(): 0, irqs_disabled(): 1, pid: 111, name: kworker/u8:5
9 locks held by kworker/u8:5/111:
 #0:  ("events_unbound"){......}, at: [<ffffffff8109a06d>] process_one_work+0x17d/0x640
 #1:  ((&entry->work)){......}, at: [<ffffffff8109a06d>] process_one_work+0x17d/0x640
 #2:  (registration_lock){......}, at: [<ffffffff81416314>] register_framebuffer+0x34/0x3a0
 #3:  (console_lock){......}, at: [<ffffffff81416534>] register_framebuffer+0x254/0x3a0
 #4:  (&fb_info->lock){......}, at: [<ffffffff814145db>] lock_fb_info+0x1b/0x40
 #5:  ((fb_notifier_list).rwsem){......}, at: [<ffffffff810d7d60>] rt_down_read+0x10/0x20
 #6:  (&dev->mode_config.mutex){......}, at: [<ffffffffa007476e>]
__drm_modeset_lock_all+0x8e/0x120 [drm]
 #7:  (crtc_ww_class_acquire){......}, at: [<ffffffffa0074778>]
__drm_modeset_lock_all+0x98/0x120 [drm]
 #8:  (crtc_ww_class_mutex){......}, at: [<ffffffffa007432d>] drm_modeset_lock+0x3d/0x110 [drm]
CPU: 0 PID: 111 Comm: kworker/u8:5 Not tainted 4.0.5-rt4+ #4
Hardware name: Hewlett-Packard p7-1512/2ADA, BIOS 8.15 02/05/2013
Workqueue: events_unbound async_run_entry_fn
 0000000000000000 000000002b54f949 ffff88003de17658 ffffffff81783f82
 000000002b54f949 0000000000000000 ffff88003de17678 ffffffff810a6578
 ffff88018aef5808 ffff88018aef5808 ffff88003de176a8 ffffffff8178abe4
Call Trace:
 [<ffffffff81783f82>] dump_stack+0x4f/0x90
(Continue reading)

Steven Rostedt | 24 Jun 21:37 2015

[ANNOUNCE] 3.4.108-rt135


Dear RT Folks,

I'm pleased to announce the 3.4.108-rt135 stable release.

This release is just an update to the new stable 3.4.108 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.4-rt
  Head SHA1: 20fde0130068754fcca9762f7344a98b1cc22a3b

Or to build 3.4.108-rt135 directly, the following patches should be applied:

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.108-rt135.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)

Steven Rostedt | 24 Jun 21:35 2015

[ANNOUNCE] 3.12.44-rt61


Dear RT Folks,

I'm pleased to announce the 3.12.44-rt61 stable release.

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

Although I did backport some patches from mainline to make NO_HZ_FULL
compile. But more needs to be done to have it work for PREEMPT_RT.

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

Or to build 3.12.44-rt61 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.44.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.44-rt61.patch.xz

Enjoy,

-- Steve
(Continue reading)

Steven Rostedt | 24 Jun 21:33 2015

[ANNOUNCE] 3.18.16-rt13


Dear RT Folks,

I'm pleased to announce the 3.18.16-rt13 stable release.

This release is just an update to the new stable 3.18.16 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.18-rt
  Head SHA1: 2ab403919b5b80b0fbce1f99cf023fecd13d7b95

Or to build 3.18.16-rt13 directly, the following patches should be applied:

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

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

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.16-rt13.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)

Paul Gortmaker | 23 Jun 00:23 2015

[PATCH v3.10-rt] rtmutex: fixup semi incomplete backport causing new warning spew

We have a backport of commit 8930ed80f970a90a795239e7415c9b0e6f964649
("rtmutex: Cleanup deadlock detector debug logic") which is commit
8a3af0727b43a6e51e3699f62bd15f9bb60e0692 here on the v3.10-rt branch,
added in the creation v3.10.70-rt75.  However it missed one of the
conversions from the old int to the new enum, leading to this spew:

  CC      kernel/rtmutex.o
kernel/rtmutex.c: In function ‘rt_mutex_timed_futex_lock’:
kernel/rtmutex.c:1709:37: warning: passing argument 5 of ‘rt_mutex_timed_fastlock’ from
incompatible pointer type
            RT_MUTEX_FULL_CHAINWALK, rt_mutex_slowlock);
                                     ^
kernel/rtmutex.c:1634:1: note: expected ‘int (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *,
int)’ but argument is of type ‘int (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum rtmutex_chainwalk)’
 rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
 ^
kernel/rtmutex.c: In function ‘rt_mutex_timed_lock’:
kernel/rtmutex.c:1749:36: warning: passing argument 5 of ‘rt_mutex_timed_fastlock’ from
incompatible pointer type
            RT_MUTEX_MIN_CHAINWALK, rt_mutex_slowlock);
                                    ^
kernel/rtmutex.c:1634:1: note: expected ‘int (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *,
int)’ but argument is of type ‘int (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum rtmutex_chainwalk)’
 rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
 ^

Slightly hard to wrap your head around, but once you do, the missing
conversion is clear, and once fixed, all rtmutex warnings are gone.

Signed-off-by: Paul Gortmaker <paul.gortmaker <at> windriver.com>
(Continue reading)

Steven Rostedt | 22 Jun 21:43 2015

[PATCH][RT] irq_work: Use proper BUG_ON_NONRT()

We added BUG_ON_NONRT() to handle those cases that don't apply when
PREEMPT_RT is enabled. No need to open code the check using
IS_ENABLED().

Signed-off-by: Steven Rostedt <rostedt <at> goodmis.org>
---
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 9678fd1382a7..5a0f4525139c 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
 <at>  <at>  -144,7 +144,7  <at>  <at>  static void irq_work_run_list(struct llist_head *list)
 	struct irq_work *work;
 	struct llist_node *llnode;

-	BUG_ON(!IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && !irqs_disabled());
+	BUG_ON_NONRT(!irqs_disabled());

 	if (llist_empty(list))
 		return;
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in

Steven Rostedt | 22 Jun 21:09 2015

[PATCH][RT][RFC] irq_work: Have non HARD_IRQ irq work just run from ticks

With PREEMPT_RT, the irq work callbacks are called from the softirq
thread, unless the HARD_IRQ flag is set for the irq work. When an irq
work item is added without the HARD_IRQ flag set, and without the LAZY
flag set, an interrupt is raised, and that interrupt will wake up the
softirq thread to run the irq work like it would do without PREEMPT_RT.

The current logic in irq_work_queue() will not raise the interrupt when
the first irq work item added has the LAZY flag set. But if another
irq work item is added without the LAZY flag set, and without the
HARD_IRQ item set, the interrupt is not raised because the interrupt is
only raised when the list was empty before adding the current irq work
item.

This means that if an irq work item is added with the LAZY flag set, it
will not raise the interrupt and that work item will have to wait till
the next timer tick (which in computer terms is a long way away). Now
if in the mean time, another irq work item is added without the LAZY
flag set, and without the HARD_IRQ flag set (meaning it wants to run
from the softirq), the interrupt will still not be raised. This is
because the interrupt is only raised when the first item of the list is
added. Future items added will not raise the interrupt. This makes the
raising of the irq work callback non deterministic. Rather ironic
considering this only happens when PREEMPT_RT is enabled.

I have several ideas on how to fix this.

1) Add another list (softirq_list), and add to it if PREEMPT_RT is
enabled and the flag doesn't have either LAZY or HARD_IRQ flags set.
This is what would be checked in the interrupt irq work callback
instead of the lazy_list.
(Continue reading)

Giuliano Colla | 22 Jun 13:06 2015
Picon

CLOCK_MONOTONIC issue

Hi all,

in order both to profile the performance of my rt threads, and to 
perform timed operations (such as sem_timedwait), I'm using the 
clock_gettime() function.

Using as a parameter CLOCK_REALTIME everything appears to work as 
expected, but if I attempt to use CLOCK_MONOTONIC (which should be a 
more reliable timing source, from what I read), I get bogus times.

This occurs on different platforms, and with different kernel 
versions/rt patch. (3.10.10-rt7 - 3.10.67-rt71 - 3.12.31-rt45).

Am I missing something obvious, such as a kernel misconfiguration, or 
this is something to be expected?

Any hint will be appreciated.

Thanks in advance,

Giuliano

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in


Gmane