On 02/08/2015 04:29 PM, David Dueck wrote:
This fixes a potential null pointer dereference.
Signed-off-by: David Dueck davidcdu...@googlemail.com
Acked-by: Sebastian Andrzej Siewior bige...@linutronix.de
Fixes: d4332013919a (driver core: dev_get_drvdata: Don't check for NULL
dev)
Greg
;
but I didn't think of that others might pass 0 since it wasn't used
before.
Does the original patch (you noted) break anything as of now? Because
then this patch should go stable.
Signed-off-by: Michal Simek michal.si...@xilinx.com
Acked-by: Sebastian Andrzej Siewior bige...@linutronix.de
- Yoshihiro YUNOMAE
(reason: 550 5.1.1 yoshihiro.yunomae...@hitachi.com: Recipient
address rejected: User Unknown)
On 01/16/2015 11:37 AM, Michal Simek wrote:
Hi,
Hi,
Origin patch looks good to me but this checking will be good to add.
Are you using of_serial.c because I didn't find any
On 01/16/2015 12:02 PM, Michal Simek wrote:
Origin patch looks good to me but this checking will be good to add.
Are you using of_serial.c because I didn't find any of_alias_get_id call
for 8250?
I'm using of_alias_get_id() in 8250_omap.c which made it into
v3.19-rc1. I think the change you
* Benjamin LaHaise | 2014-06-25 11:24:45 [-0400]:
I finally have some time to look at this patch in detail. I'd rather do the
below variant that does what Kent suggested. Mike, can you confirm that
this fixes the issue you reported? It's on top of my current aio-next tree
at
* Mike Galbraith | 2014-06-02 15:12:44 [+0200]:
Using mutex_acquire_nest() as used in __ww_mutex_lock() fixes the
splat below. Remove superfluous line break in __ww_mutex_lock()
as well.
applied.
Signed-off-by: Mike Galbraith umgwanakikb...@gmail.com
umgwanakikbuti? The good ones were taken,
On 02/18/2015 09:31 AM, Purcareata Bogdan wrote:
Thanks! Will send a patchset separating these 2 functional changes - the
openpic raw_spinlock for upstream ppc (since it doesn't bring any
changes anyway), and the MAX_VCPUS limitation for the RT tree.
thanks. please cc me on both.
This
irq context
PREEMPT_RT_FULL safe. The callbacks are executed in kthread context.
Bases on wait-simple.
Signed-off-by: Daniel Wagner daniel.wag...@bmw-carit.de
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
include/linux/work-simple.h | 24 ++
kernel/sched/Makefile |2
* Sebastian Andrzej Siewior | 2015-02-16 12:18:22 [+0100]:
Known issues:
- xor / raid_pq
I had max latency jumping up to 67563us on one CPU while the next
lower max was 58us. I tracked it down to module's init code of
xor and raid_pq. Both disable preemption while
* Paul Gortmaker | 2015-02-13 16:30:17 [-0500]:
there is the thread [v3.10-rt / v3.12-rt] scheduling while atomic in
cgroup code where I applied Mike's patch. This should fix the problem
reported and be part of the next release.
Could please double check (either by grabing the patch or waiting
On 02/18/2015 10:32 AM, Bogdan Purcareata wrote:
Due to the introduction of the raw_spinlock for the KVM openpic, guests with a
high number of VCPUs may induce great latencies on the underlying RT Linux
system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs).
This can be
that it is save if blk_mq_ctx is
used multiple times, the in struct lock protects the access.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
block/blk-mq.c | 4
block/blk-mq.h | 8
2 files changed, 12 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index
* Steven Rostedt | 2014-04-08 22:47:01 [-0400]:
From: Steven Rostedt (Red Hat) rost...@goodmis.org
The readers of mainline rwsems are not allowed to nest, the rwsems in the
PREEMPT_RT kernel should not nest either.
I applied this and this is the reason why cpufreq isn't working. What I
see in
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
That said, I don't think serial8250_do_startup() is really doing that much
for OMAP h/w startup; open-coding what omap_8250 really needs is probably
10 loc.
10 loc? I have a few more. serial8250_clear_fifos(),
serial_link_irq_chain() aren't
On 02/12/2015 08:55 PM, Peter Hurley wrote:
On 02/12/2015 02:23 PM, Sebastian Andrzej Siewior wrote:
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
That said, I don't think serial8250_do_startup() is really doing that much
for OMAP h/w startup; open-coding what omap_8250 really needs
* Marcelo Tosatti | 2015-01-26 19:12:31 [-0200]:
Ping ?
please resent.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
* Stanislav Meduna | 2014-11-11 01:55:37 [+0100]:
Hi,
Hi,
something between 3.12.19(-rt30) and 3.12.31(-rt45) broke
hrtimers on (at least) i.MX28 for CONFIG_HZ_PERIODIC.
Switching to CONFIG_NO_HZ_IDLE restores them.
Is this the expected behaviour or a regression?
No, I don't think so. Did it
to get one twice in a row.
Not sure when this started but I guess 397335f00 (rtmutex: Fix deadlock
detector for real) or commit 3d5c9340 (rtmutex: Handle deadlock
detection smarter).
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
kernel/locking/rtmutex.c | 3 ++-
1 file changed, 2
* Sebastian Andrzej Siewior | 2015-02-17 18:53:17 [+0100]:
* Purcareata Bogdan | 2015-02-17 14:27:44 [+0200]:
Ping?
On 02.02.2015 11:35, Purcareata Bogdan wrote:
Ping?
No body?
bah! That mutt thing is too fast.
The raw conversation looks sane and could go upstream. This other chunk
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only be all interruptible or all not
interruptible, that the swait_wake() should
* Purcareata Bogdan | 2015-02-17 14:27:44 [+0200]:
Ping?
On 02.02.2015 11:35, Purcareata Bogdan wrote:
Ping?
No body?
Sebatian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
* Mike Galbraith | 2014-11-02 08:31:18 [+0100]:
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -80,7 +80,7 @@ noinline void btrfs_clear_path_blocking(
{
int i;
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#if (defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_PREEMPT_RT_BASE))
/* lockdep
* Stanislav Meduna | 2014-04-17 16:18:16 [+0200]:
diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c
index e10acc2..7065486 100644
--- a/drivers/w1/w1_io.c
+++ b/drivers/w1/w1_io.c
@@ -170,14 +170,14 @@ static u8 w1_read_bit(struct w1_master *dev)
unsigned long flags = 0;
/*
* Andrey Smirnov | 2014-06-10 11:52:05 [-0700]:
Eventually I am hoping to disable any sorts of frequency scaling or
power management on our system, but I am still curious to know if that
is a known issue patches for which exist. Does anyone has any
leads/suggestions?
You need to breakout of the
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
Thomas, what is the usual approach for patches like this? Do you take
them into your rt tree or should they get integrated to upstream?
Patch 1 is definitely suitable for upstream, that's the reason why we
have raw_spin_lock vs. raw_spin_unlock.
the code is back on the CPU, it overwrites the futex value
with with the old PID and the waiter bit set.
The workaround is to explicit disable code preemption to avoid the
described race window.
Debugged-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior bige
* Clark Williams | 2014-08-27 16:09:28 [-0500]:
Thomas,
The latest btrfs code uses rwsem_is_contended() in the function
caching_thread(). On RT systems, include/linux/rwsem.h is replaced with
include/linux/rwsem_rt.h which does not provide a definition for
rwsem_is_contended(). This commit
* Mike Galbraith | 2014-06-21 10:09:48 [+0200]:
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2398,16 +2398,18 @@ static bool consume_stock(struct mem_cgr
{
struct memcg_stock_pcp *stock;
bool ret = true;
+ int cpu;
if (nr_pages CHARGE_BATCH)
return
* Steven Rostedt | 2014-07-01 11:14:44 [-0400]:
I talked with Peter Zijlstra about this, and he told me that the clearing
of the PF_NO_SETAFFINITY flag was to deal with the optimization of
migrate_disable/enable() that ignores tasks that have that flag set. But
that optimization was removed when
* Mike Galbraith | 2014-11-02 08:31:47 [+0100]:
(sirqs suck, this makes them suck less for some boxen/loads)
Subject: softirq: resurrect softirq threads
From: Mike Galbraith mgalbra...@suse.de
Date: Mon Jan 6 08:42:11 CET 2014
Some loads cannot tolerate the jitter induced by all softirqs being
* Mike Galbraith | 2014-11-02 08:31:28 [+0100]:
(not pretty)
You do the RCU thingy and replace locking. Is this required after the
patch I've sent in Re: [RFC PATCH V2] rt/aio: fix rcu garbage
collection might_sleep() splat? From a quick browse I've seen that
ffs_epfile_aio_write() invokes
* Mike Galbraith | 2014-11-02 08:31:37 [+0100]:
Shrug. Lots of hobbyists have a beast in their basement, right?
I can take this as is if you want.
--- a/arch/x86/platform/uv/uv_time.c
+++ b/arch/x86/platform/uv/uv_time.c
@@ -300,13 +300,18 @@ static int uv_rtc_unset_timer(int cpu, i
static
On 02/10/2015 12:34 AM, Peter Hurley wrote:
The too much work message means serial8250_handle_irq() is returning 0,
ie., not handled. Which in turn means IIR indicates no interrupt is pending
(UART_IIR_NO_INT == 1).
The OMAP UART for instance have two possible TX-IRQ handling. The
default is
...@hurleysoftware.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 10 --
drivers/tty/serial/8250/8250_omap.c | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial
On 02/11/2015 09:42 PM, Peter Hurley wrote:
Reverting makes sense to me if it has caused a regression. Maybe Sebastian
can update his patch to do this based on some quirk flag instead?
That's fine with me. There's a 'bugs' field in struct 8250_uart_port and
UART_BUG_* defines in 8250/8250.h
on it. Therefore the Omap fix is
reverted for now.
Fixes: 0aa525d11859 (tty: serial: 8250_core: read only RX if there is
something in the FIFO)
Reported-By: Nicolas Schichan nschic...@freebox.fr
Debuged-By: Peter Hurley pe...@hurleysoftware.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Dear RT folks!
I'm pleased to announce the v3.18.7-rt1 patch set. It was running over
the weekend on my x86 box and was still alive this morning. However it
is still the first release for the v3.18 -RT series.
I haven't follow the mailing list or commented / applied any patches
from the list for
* Juri Lelli | 2014-05-13 15:30:20 [+0200]:
Hi,
Hi Juri,
Also SCHED_DEADLINE dies without the following.
Thanks,
- Juri
---From 3ca5943538c728399037823e5632431bc2da707c Mon Sep 17 00:00:00 2001
From: Juri Lelli juri.le...@gmail.com
Date: Tue, 13 May 2014 15:21:16 +0200
Subject: [PATCH]
On 03/17/2015 09:10 PM, Paul Gortmaker wrote:
[[PATCH RT 26/39] scheduling while atomic in cgroup code] On 12/03/2015 (Thu
15:13) Steven Rostedt wrote:
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
* Mike Galbraith | 2015-03-13 05:53:25 [+0100]:
First of all, a task being ticked and trying to shut the tick down will
fail to do so due to having just awakened ksoftirqd, so let ksoftirqd
try to do that after SOFTIRQ_TIMER processing. Secondly, should the
tick be shut down, we may livelock in
On 03/16/2015 03:02 PM, Steven Rostedt wrote:
On Mon, 16 Mar 2015 14:59:10 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
* Steven Rostedt | 2015-03-12 15:13:07 [-0400]:
Please scream at me if I messed something up. Please test the patches too.
So Paul remided us about
* Steven Rostedt | 2015-03-12 15:13:07 [-0400]:
Please scream at me if I messed something up. Please test the patches too.
So Paul remided us about the dead lock thingy that has been reported.
Users reported that it does not occur with v3.18-RT and they think it is
due to 'Revert timers: do not
* Steven Rostedt | 2015-03-12 18:08:57 [-0400]:
The hirq_work_list is only defined when PREEMPT_RT_FULL is configured.
Most access to it is within an #ifdef CONFIG_PREEMPT_RT_FULL, except
for one. Encapsulate that location too.
Signed-off-by: Steven Rostedt rost...@goodmis.org
Applied
Dear RT folks!
I'm pleased to announce the v3.18.9-rt5 patch set.
Changes since v3.18.9-rt4
- fix non-rt builds. Reported by Neil Bradley, fixed by Steven Rostedt
- backport a patch from Lai Jiangshan which was suggested by Paul E.
McKenney to avoid a RCU related race
- a bunch of stable
On 03/09/2015 11:51 AM, Mike Galbraith wrote:
Why do both mutex and rtmutex then exist one might ask? ;-) No big deal
either way though, it's not like it becomes immutable once applied.
You don't choose rtmutex afaik. rtmutex is used by futex (only?) and
one of the things it does is PI.
On -RT
* Mike Galbraith | 2015-02-18 12:21:54 [+0100]:
On Mon, 2015-02-16 at 12:18 +0100, Sebastian Andrzej Siewior wrote:
Known issues:
- lazy preempt on x86_64 leads to a crash with some load.
The below still works for me. (it doesn't make nohz_full actually work
in rt, but at least folks
I just stumbled over this in -RT. The code:
87 bool irq_work_queue(struct irq_work *work)
88 {
…
96 /* If the work is lazy, handle it from next tick if any */
97 if (work-flags IRQ_WORK_LAZY) {
98 if (llist_add(work-llnode, this_cpu_ptr(lazy_list))
99
On 03/09/2015 12:29 PM, Mike Galbraith wrote:
On Mon, 2015-03-09 at 12:07 +0100, Sebastian Andrzej Siewior wrote:
On 03/09/2015 11:51 AM, Mike Galbraith wrote:
Why do both mutex and rtmutex then exist one might ask? ;-) No big deal
either way though, it's not like it becomes immutable once
On 03/09/2015 03:36 PM, Mike Galbraith wrote:
On Mon, 2015-03-09 at 14:45 +0100, Sebastian Andrzej Siewior wrote:
* Mike Galbraith | 2015-02-18 12:21:54 [+0100]:
On Mon, 2015-02-16 at 12:18 +0100, Sebastian Andrzej Siewior wrote:
Known issues:
- lazy preempt on x86_64 leads
So I run hackbench -g 600 -l 350 -s 250 which takes approx 77 seconds
to complete. Then this popped up:
|INFO: rcu_preempt detected stalls on CPUs/tasks:
| Tasks blocked on level-0 rcu_node (CPUs 0-3): P24858 P28514 P25185 P25184
P28713 P19549 P3139 P25275 P28474 P29062 P6703 P10 106 P14309
* Brian Silverman | 2015-03-05 00:16:20 [-0500]:
Beforehand, 000 is spending most of its time in interrupts, but bash
is doing something related to memory management on it in between.
bash-14721 [000] ..1 6854.629126: rt_spin_lock
-free_pcppages_bulk
bash-14721
* Paul E. McKenney | 2015-03-09 08:59:47 [-0700]:
On Mon, Mar 09, 2015 at 04:26:51PM +0100, Sebastian Andrzej Siewior wrote:
So I run hackbench -g 600 -l 350 -s 250 which takes approx 77 seconds
to complete. Then this popped up:
|INFO: rcu_preempt detected stalls on CPUs/tasks:
| Tasks
* Austin Schuh | 2015-03-05 09:10:47 [-0800]:
ping?
Why is this a ping? I haven't seen this in my rt nor in my lkml inbox.
Please repost it properly including lkml.
From what I can tell not beeing a sched guy is that the patch looks
reasonable since the timeout gets only set to zero on
On 03/09/2015 05:36 PM, Steven Rostedt wrote:
BTW, I'm going to start with 3.18-rt1 and see what's been added to the
other -rt updates. If there's something I need that was added to
3.18-rt1 can you let me know. That is, if it wasn't marked with a
stable-rt tag. My scripts will find those.
I
On 03/09/2015 07:02 PM, Paul E. McKenney wrote:
abaf3f9d275b (rcu: Revert Allow post-unlock reference for rt_mutex to avoid
priority-inversion)
This patch fixed a priority-inversion problem, so might well fix your
RCU CPU stall-warning problem.
Yes, it fixes the problem. Thank you.
On 03/02/2015 09:46 AM, Maarten Lankhorst wrote:
Hey,
Op 02-03-15 om 04:20 schreef Mike Galbraith:
On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
This patch makes it possible to replace the base mutex by a rt_mutex. In
general one would not do this.
I would argue
On 03/06/2015 01:16 PM, Maarten Lankhorst wrote:
Okay so what I the point made here? It is only about the config option,
right? What are the preferences here:
[ ] yes, the way it is now
Is my personal preference, but I'm not a locking expert(TM).
Lets see what Mike says. I currently don't
* Marcelo Tosatti | 2015-01-14 15:12:52 [-0200]:
Against which tree was this prepared? Could please rebase it against
v3.18.7-rt2? Because a I see fuzz 2, the mips file is gone and
s390 rejects almost every chunk.
And there was that mips chunk Steven noticed.
Patch #2 seems to apply but since it
* Steven Rostedt | 2015-02-26 09:06:10 [-0500]:
If we can pull that off and remove all rtmutex trylocks from hardirq
context, I would much rather do that.
This hocus pocus coding is just going to lead us down the path of the
black arts. I already have a black cat, so I'm good to go.
Okay. So
Dear RT folks!
I'm pleased to announce the v3.18.9-rt4 patch set.
Changes since v3.18.9-rt3
- The patch rwsem-rt: Do not allow readers to nest has been reverted.
This means cpufreq works again.
- A fix in sound/audio to not disable interrupts as part of the locking.
(Mike Galbraith)
- A
* Steven Rostedt | 2015-03-12 15:13:07 [-0400]:
Please scream at me if I messed something up. Please test the patches too.
Could you add Mike's 3.14.23-rt20 - fs,btrfs: fix rt deadlock on
extent_buffer-loc [0] and that is the upper chunk (ctree.c only). As I
mentioned in the thread, the code is
* Steven Rostedt | 2015-03-12 15:13:23 [-0400]:
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
If you take this, could you take 9d3e2d02f54160725d97f4ab1e1e8de493fbf33a
(locking/rtmutex: Set state back to running on error) it sits on my
queue and is
* Sebastian Andrzej Siewior | 2015-03-13 11:40:47 [+0100]:
If you take this, could you take 9d3e2d02f54160725d97f4ab1e1e8de493fbf33a
(locking/rtmutex: Set state back to running on error) it sits on my
queue and is upstream already.
Or forget what I said. It is there already, it has been removed
Hi Shawn,
On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
We did not add a DT property for it, because there was already enough
info (clock configuration) in DT for kernel to figure it out.
Correct. My understanding is whatever can be figured out without DT should
be done that way.
On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
diff =
--- arch/arm/mach-imx/mach-imx6q.c
+++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
@@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
* set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad
* (external
* Steven Rostedt | 2015-03-12 15:13:07 [-0400]:
Please scream at me if I messed something up. Please test the patches too.
There is also [PATCH v3.14-rt] netpoll: guard the access to dev-npinfo
with rcu_read_lock/unlock which I did not apply because the code is
gone in v3.18. I stopped looking
* Brian Silverman | 2015-03-09 20:36:27 [-0400]:
It looks like your softirq for net_rx is getting a packet and then after
raising NET_RX (again?) it blocks on a lock. In order to get this lock
it boosts and schedules bash. It gets runable but on the other CPU. On
CPU1 there is nothig going is
On 03/06/2015 06:50 PM, Mike Galbraith wrote:
On Fri, 2015-03-06 at 13:36 +0100, Sebastian Andrzej Siewior wrote:
On 03/06/2015 01:16 PM, Maarten Lankhorst wrote:
Okay so what I the point made here? It is only about the config option,
right? What are the preferences here:
[ ] yes, the way
* Mike Galbraith | 2015-03-21 19:02:23 [+0100]:
Steve, I'm still working on the fix we discussed using dummy irq_task.
I should be able to submit some time next week, if still interested.
Either that, or I think we should remove the function
spin_do_trylock_in_interrupt() to prevent any
On 03/03/2015 06:19 AM, cfredric wrote:
Signed-off-by: cfredric chris.p.fredrick...@gmail.com
You could use your full name here.
---
drivers/usb/core/buffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index
in the
-RT try including Mike Galbraith's latest lockdep annotations fixups and
proper deadlock detection which was broken after the rt_mutex rework.
Cc: Mike Galbraith umgwanakikb...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
include/linux/ww_mutex.h | 87
From: Peter Zijlstra pet...@infradead.org
The existing wait queue support has support for custom wake up call
backs, wake flags, wake key (passed to call back) and exclusive
flags that allow wakers to be tagged as exclusive, for limiting
the number of wakers.
In a lot of cases, none of these
change the task's state back to RUNNING. I assume this is
intended. Without this change after ww_mutex using rt_mutex the selftest
passes but later I get plenty of
| bad: scheduling from the idle thread!
backtraces.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
kernel/locking
This level of indirection is one step towards replacing the mutex with
a different kind of locking mechanism.
The new functions of the form __.*_lock provide access to whatever is
hidden behind the base member in ww-mutex's struct
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
On -RT we use struct rt_mutex instead of struct mutex for a regular mutex.
And since people use GPUs there, too we needed a port of ww_mutex based
rtmutex. I snipped the implementaton out of -RT tried to fit on mainline
and not breaking too much. It doesn't look that bad now :)
#1 is here to keep
On 02/27/2015 07:20 PM, Maarten Lankhorst wrote:
Assuming it's compile tested, can't really test that here. :)
It passes the self-test without the killable one and the other one I
switched off. And that thing that we have in -RT has been reported to
be working with the nouveau driver.
There is
On 02/27/2015 07:40 AM, Daniel Wagner wrote:
Hi Sebastian
Hi Daniel,
On 02/26/2015 09:48 AM, Sebastian Andrzej Siewior wrote:
* Sebastian Andrzej Siewior | 2015-02-25 14:55:01 [+0100]:
+
+static int thermal_notify_work_init(void)
+{
+int err;
+
+err = swork_get();
+if (!err
On 03/05/2015 02:09 AM, Marcelo Tosatti wrote:
Can you please include the series?
Thanks
Sebastian?
I will pick it up, don't worry. I think I do my -RT day tomorrow.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
* Joakim Hernberg | 2015-02-19 10:36:01 [+0100]:
On Tue, 17 Feb 2015 09:37:44 +0100
Daniel Wagner w...@monom.org wrote:
I needed the patch below to get it running stable under load on my
shiny box.
FWIW, this patch makes 3.18-rt survive thermal events on my laptop.
Okay. I applied a slightly
* Mike Galbraith | 2015-02-18 16:05:28 [+0100]:
[ 37.667792] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[ 37.720307] BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:915
[ 37.720307] in_atomic(): 1, irqs_disabled(): 0, pid: 3194, name: rpc.nfsd
[
On 02/18/2015 09:13 PM, Steven Rostedt wrote:
Here the same thing but without cmpxchg(). _If_ after an increment the
value is negative then we take slowpath. Otherwise we have the lock.
OK, so I need to make it so it can nest with trylock. I have to look at
the patch again because it has
* Mike Galbraith | 2015-02-18 15:09:23 [+0100]:
Locking functions previously using read_lock_irq()/read_lock_irqsave() were
changed to local_irq_disable/save(), leading to gripes. Use nort variants.
applied
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
* Scott Wood | 2015-02-23 17:27:31 [-0600]:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular, openpic_update_irq
which loops on the number of vcpus, with a loop body that calls
IRQ_check() which loops over all pending
(tested on am335x + imx28) point of view always
using cmpxchg() in rt_mutex_lock() + rt_mutex_unlock() makes sense I
would drop the define.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
If this gets applied I would prepare a removal __HAVE_ARCH_CMPXCHG in
the architectures the way
* Sebastian Andrzej Siewior | 2015-02-25 18:56:13 [+0100]:
To put some numbers on it: preempt -RT, am335x, 10 loops of
10 invocations of rt_spin_lock() + rt_spin_unlock() (time total is
the average of the 10 loops for the 10 invocations, loop is
total / 10 * 1000):
This is the test
* Peter Zijlstra | 2015-02-18 15:03:20 [+0100]:
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
Usually you see scheduling while atomic on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
not cause a DoS
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
Yes, but large latencies just mean the code has to be rewritten (x86
doesn't anymore do event injection in an atomic regions for example).
Until
Dear RT folks!
I'm pleased to announce the v3.18.7-rt2 patch set.
There are still patches to collect but I had this tested for a couple of
days, got big and did not want to sit on it any longer.
Changes since v3.18.7-rt1
- a patch for sched/deadline to get it work in RT (Juri Lelli)
- a patch
On 2014-02-11 16:51:55 [+0100], Thomas Gleixner wrote:
On Wed, 30 Oct 2013, Mel Gorman wrote:
On Wed, Oct 30, 2013 at 09:45:31AM +0100, Thomas Gleixner wrote:
On Tue, 29 Oct 2013, Mel Gorman wrote:
Patch boots and futextest did not explode but I did no comparison
performance tests.
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular, openpic_update_irq
which loops on the number of vcpus, with a loop body that calls
* Steven Rostedt | 2015-02-23 19:57:43 [-0500]:
On Mon, 23 Feb 2015 17:16:27 -0700
Thavatchai Makphaibulchoke thavatchai.makpahibulch...@hp.com wrote:
If I'm not mistaken, another reason could also be due to the rate of the
timer interrupt, in the case that the mutex is highly contested IH
* Xander Huff | 2015-01-28 15:06:59 [-0600]:
Fixed by wrapping the test definitions in #ifndef CONFIG_PREEMPT_RT_FULL
conditionals.
FYI: To be clearer, this should apply to all stable RT releases 3.4 and later.
Applied
Sebastian
--
To unsubscribe from this list: send the line unsubscribe
* Mike Galbraith | 2015-02-26 09:02:05 [+0100]:
I found what was breaking my core2 lappy in 4.0-rt as well, namely the
4.0-rt? So you are a time traveler?
locking, ww_mutex: fix ww_mutex vs self-deadlock
If the caller already holds the mutex, task_blocks_on_rt_mutex()
returns -EDEADLK, we
* Sebastian Andrzej Siewior | 2015-02-25 14:55:01 [+0100]:
Okay. I applied a slightly modified version of it. That init() is
From 8334ac498f104c00e5d93e3e83d3bcec1a993cec Mon Sep 17 00:00:00 2001
From: Daniel Wagner w...@monom.org
Date: Tue, 17 Feb 2015 09:37:44 +0100
Subject: [PATCH] thermal
* Steven Rostedt | 2015-03-19 12:26:11 [-0400]:
On Thu, 19 Mar 2015 09:17:09 +0100
Mike Galbraith umgwanakikb...@gmail.com wrote:
(aw crap, let's go shopping)... so why is the one in timer.c ok?
It's not. Sebastian, you said there were no other cases of rt_mutexes
being taken in hard irq
From: Sebastian Andrzej Siewior bige...@linutronix.de
This basically reverts commit 068500e08dc8 (serial: imx: initialized
DMA w/o HW flow enabled) simply because it does not work.
I tested it on various IMX6 boards and the default SDMA firmware, that is
included in ROM, does not work properly
On 05/07/2015 03:55 PM, Nicolae Rosia wrote:
Hi,
Hi,
Okay, please inform about your results. I think I had that one and the
result was no UART communication at all and a lot overrun errors.
I have reverted this patch and the serial comm is working well.
I haven't been able to test with
From: Sebastian Andrzej Siewior bige...@linutronix.de
This basically reverts commit 068500e08dc8 (serial: imx: initialized
DMA w/o HW flow enabled) simply because it does not work as expected
without additional magic which I am not aware of. The DMA mode is only
used for non-console UARTs so
On 2015-05-07 17:54:31 [-0300], Fabio Estevam wrote:
Thanks, this fixes Bluetooth operation on a imx6sl-warp running
without SDMA firmware.
Two suggestions:
1. You should Cc stable as it affects 4.0 also
I have the Fixes tag, doesn't this count?
2. It doesn't apply cleanly against
1 - 100 of 6306 matches
Mail list logo
