Camera.Geomatics | 18 Dec 16:12 2014

Latency measurement with oscilloscope, randomly high latency times

Hi

We try to achieve hard real time requirements with a 
FPGA->IRQ->ISR->User-Space-≥Kernel-Module-≥FPGA loop.

Kernel IRQ handler which toggles IO pins is executed by a Hardware 
interrupt every 200us (FPGA). Priority is set to 99 via chrt ?f ?p99 
pid-module.

Problem:
The test is working (Pins are toggled in time, <50us), but for some reason 

we have randomly (every 2-3sec) big latency times of several ms.

We sometimes get already interrupted in our IRQ handler (which we 
registered with request_irq) before we wakeup our user space task. 

Kernel Version: linux-socfpga 3.10.37-ltsi-rt37
Development board: Altera Cyclone V SoC Development Kit

Do we have to somehow set the priority 99 for the IRQ handler seperately? 
Is there any kind of priority inheritance from user space task to kernel 
module?

Best Regards
Hannes

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

Joshua Hernstrom | 17 Dec 23:30 2014

Requesting suggestions on ARM based test platforms

Hello,

I am investigating an increase in baseline jitter on my ARMv7 platform after moving from a 3.2 to 3.14 kernel
and want to gather data on similar platforms. Can anyone recommend ARM boards (ideally v7 family, but all
suggestions welcome) that you think would make a good candidate for me to test upon?  The main criteria
being that it has support as far back as 3.2, and that more recent kernels (roughly, 3.10 and later) still
show good baseline jitter (<100us).

I have been trying to use an OMAP3505-based Gumstix Overo but having trouble getting reasonable looking
numbers with more recent kernels, and before spending any more time digging on that front, I'd like to
compare some other boards.

Poking around on the OSADL site, the Beaglebone-Black looks like a good candidate; any other suggestions
that the wisdom of the crowd can throw my way?

Thank you,
Josh
--
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

Luiz Capitulino | 17 Dec 21:16 2014
Picon

cyclictest abstime vs. reltime

Hello,

We're doing some scheduling latency measurements with KVM. While
analyzing some traces and reading cyclictest code in the process,
I found out that by default cyclictest uses the absolute time
algorithm, which basically does:

clock_gettime(&now)
next = now + interval   /* interval == 1000us */
/* do some quick stuff */
while() {
    clock_nanosleep(&next) /* ie. sleeps until now + 1000us, 'next' is abs */
    clock_gettime(&now)
    diff = calcdiff(now, next)
    /* update a bunch of stats and the histogram data, also
       check if we're finished */
    next += interval
}

Now, doesn't this mean that the timerthread will actually sleep less
than interval? This is so because we have fixed sleeping points which
don't take into consideration the sleeping latency nor the bunch of
things the timerthread does (eg. update histogram).

If I'm making sense, won't this behavior cause better numbers to be
reported?

I compared abstime and reltime in bare-metal, and got the following
results (cyclictest [-r] -m -n -q -p99 -l 1000000):

(Continue reading)

chase.qi | 10 Dec 09:25 2014

[PATCH] pip_stress: increase usleep for ARM devices

From: Chase Qi <chase.qi <at> linaro.org>

Hello,

pip_stress works out of the box on my x86 based laptop, but
doesn't work on ARM devices, returned 'no inversion incurred'.
Follow the comment to increase usleep value, 2500 worked for
pandaboard and 3000 worked for Beaglebone Black board.

I propose that increase the usleep value to 3500 from upstream,
so that we can use pip_stress right out of the box.

Please let me know if this is acceptable.

Regards,
Chase

Signed-off-by: Chase Qi <chase.qi <at> linaro.org>
---
 src/pi_tests/pip_stress.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pi_tests/pip_stress.c b/src/pi_tests/pip_stress.c
index 2b42b8f..553290b 100644
--- a/src/pi_tests/pip_stress.c
+++ b/src/pi_tests/pip_stress.c
 <at>  <at>  -162,7 +162,7  <at>  <at>  void low(pid_t pid)
 				statep->inversion = 0;
 			}
 		Pthread_mutex_unlock(statep->mutex);
(Continue reading)

Yadi Hu | 10 Dec 03:32 2014

[PATCH 3.14.x-rt] ARM: enable irq in translation/section permission fault handlers

[PATCH 3.14.x-rt] ARM: enable irq in translation/section permission fault handlers

_might_sleep() is used to check whether current context is atomic 
in preempt-rt kernel. According to discussion on http://www.spinics.net/
lists/linux-rt-users/msg11398.html, this case is a bug in RT. 

local_irq_save();
    some_function();
        rt_spin_lock() --> this calls __might_sleep
local_irq_restore(); 

----
arch/arm/mm/fault.c |    6 ++++++
 1 file changed, 6 insertions(+)

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

Brad Mouring | 5 Dec 20:35 2014

[PATCH] rtmutex.c: Fix incorrect waiter check

In task_blocks_on_lock, there's a null check on pi_blocked_on
of the task_struct. This pointer can encode the fact that the
task that contains the pointer is waking (preventing requeuing)
and therefore is non-null. Use the inline function to avoid
dereferencing an invalid "pointer"

Signed-off-by: Brad Mouring <brad.mouring <at> ni.com>
Reported-by: Ben Shelton <ben.shelton <at> ni.com>
---
 kernel/locking/rtmutex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6c40660..535321e 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
 <at>  <at>  -335,7 +335,8  <at>  <at>  int max_lock_depth = 1024;

 static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
 {
-	return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
+	return rt_mutex_real_waiter(p->pi_blocked_on) ?
+		p->pi_blocked_on->lock : NULL;
 }

 /*
--

-- 
1.8.3-rc3

--
(Continue reading)

Kevin Hao | 3 Dec 13:05 2014
Picon

[PATCH v3.14-rt] netpoll: guard the access to dev->npinfo with rcu_read_lock/unlock_bh() for CONFIG_PREEMPT_RT_FULL=y

For vanilla kernel we don't need to invoke rcu_read_lock/unlock_bh
explicitly to mark an RCU-bh critical section in the softirq context
because bh is already disabled in this case. But for a rt kernel,
the commit ("rcu: Merge RCU-bh into RCU-preempt") implements the
RCU-bh in term of RCU-preempt. So we have to use
rcu_read_lock/unlock_bh() to mark an RCU-bh critical section even in
a softirq context. Otherwise we will get a call trace like this:
  include/linux/netpoll.h:90 suspicious rcu_dereference_check() usage!
  other info that might help us debug this:
  rcu_scheduler_active = 1, debug_locks = 0
  1 lock held by irq/177-eth0_g0/129:
   #0:  (&per_cpu(local_softirq_locks[i], __cpu).lock){+.+...}, at: [<8002f544>] do_current_softirqs+0x12c/0x5ec

  stack backtrace:
  CPU: 0 PID: 129 Comm: irq/177-eth0_g0 Not tainted 3.14.23 #11
  [<80018c0c>] (unwind_backtrace) from [<800138b0>] (show_stack+0x20/0x24)
  [<800138b0>] (show_stack) from [<8075c3bc>] (dump_stack+0x84/0xd0)
  [<8075c3bc>] (dump_stack) from [<8008111c>] (lockdep_rcu_suspicious+0xe8/0x11c)
  [<8008111c>] (lockdep_rcu_suspicious) from [<805e94e8>] (dev_gro_receive+0x240/0x724)
  [<805e94e8>] (dev_gro_receive) from [<805e9c34>] (napi_gro_receive+0x3c/0x1e8)
  [<805e9c34>] (napi_gro_receive) from [<804b01ac>] (gfar_clean_rx_ring+0x2d4/0x624)
  [<804b01ac>] (gfar_clean_rx_ring) from [<804b078c>] (gfar_poll_rx_sq+0x58/0xe8)
  [<804b078c>] (gfar_poll_rx_sq) from [<805eada8>] (net_rx_action+0x1c8/0x418)
  [<805eada8>] (net_rx_action) from [<8002f62c>] (do_current_softirqs+0x214/0x5ec)
  [<8002f62c>] (do_current_softirqs) from [<8002fa88>] (__local_bh_enable+0x84/0x9c)
  [<8002fa88>] (__local_bh_enable) from [<8002fab8>] (local_bh_enable+0x18/0x1c)
  [<8002fab8>] (local_bh_enable) from [<80093924>] (irq_forced_thread_fn+0x50/0x74)
  [<80093924>] (irq_forced_thread_fn) from [<80093c30>] (irq_thread+0x158/0x1c4)
  [<80093c30>] (irq_thread) from [<800555b8>] (kthread+0xd4/0xe8)
  [<800555b8>] (kthread) from [<8000ee88>] (ret_from_fork+0x14/0x20)
(Continue reading)

Juerg Haefliger | 2 Dec 12:09 2014
Picon

kernel BUG at /build/linux-rt/kernel/locking/rtmutex.c:997!

Dear RT experts,

I have a simple test that runs two iperf clients in parallel with the
ltp network tests and it triggers a deadlock within a few minutes.
This is 100% repeatable. I've tried this on different RT kernels and
determined that prior to the following commit (which went into 3.10
upstream), the machine doesn't deadlock and seems to run just fine:

fb52f40e085ef4074f1335672cd62c1f832af13b rtmutex: Handle deadlock
detection smarter

I've reverted part of the above commit in v3.14.23-rt20 and now that
kernel also runs through the test. Specifically, I've applied:

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6c40660..0fff32a 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
 <at>  <at>  -471,7 +471,7  <at>  <at>  static int rt_mutex_adjust_prio_chain(struct
task_struct *task,
        if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
                debug_rt_mutex_deadlock(deadlock_detect, orig_waiter, lock);
                raw_spin_unlock(&lock->wait_lock);
-               ret = -EDEADLK;
+               ret = deadlock_detect ? -EDEADLK : 0;
                goto out_unlock_pi;
        }

Not being an expert, I'm wondering if this is a false deadlock detection?

(Continue reading)

"Jürgen Lanner" | 1 Dec 14:22 2014
Picon
Picon

problem using trace-cmd and trace_marker when using only one core

Ladies and gentlemen,

I found some odd behaviour when using trace-cmd together with trace_marker.

I try to use trace-cmd to trace scheduling events to find out latencies on my box.
    trace-cmd record -e 'sched_wakeup*' -e sched_switch

In oder to synchronize the trace I use echoing to /sys/kernel/debug/tracing/trace_marker
    echo Hallo > /sys/kernel/debug/tracing/trace_marker

This works fine so far.

My task in observation is set to run only on one core (on a quad core cpu) 
so I tried to narrow down the focus of tracing (and the data amount) using the -M option:
    trace-cmd record -M 2 -e 'sched_wakeup*' -e sched_switch

But from this point on I am no longer able to write to the trace_marker, instead I get this response:
    bash: echo: write error: Bad file descriptor

Only reboot solves the problem.

Is this some known or even intended behaviour? Or do I use it in some weird way as described?
Maybe I understood something wrong and you can give me a hint how to overcome the obstacle.

Thanks a lot

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

Braud Caroline | 27 Nov 16:34 2014
Picon
Picon

problem ethernet board

Hello,

I have installed RT kernel from:
 http://pengutronix.de/software/linux-rt/debian_en.html

But I have the same problem as this guy (ethernet controller is not working): 
http://www.spinics.net/lists/linux-rt-users/msg07478.html

except that I'm not using an amd architecture but an Intel one ...

Any idea on how and/or where to get the good headers ?

Thanks in advance,
CB

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

Boris Egorov | 27 Nov 11:20 2014
Picon

[PATCH] rt-migrate-test: exit early if nr_runs is non-positive

Program will crash if nr_runs is 0 due to dividing by it in
print_results(). Let's exit early instead.

Fixes: http://bugs.debian.org/716237

Signed-off-by: Boris Egorov <egorov <at> linux.com>
---
 src/rt-migrate-test/rt-migrate-test.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/rt-migrate-test/rt-migrate-test.c
b/src/rt-migrate-test/rt-migrate-test.c
index e3c7a09..876a122 100644
--- a/src/rt-migrate-test/rt-migrate-test.c
+++ b/src/rt-migrate-test/rt-migrate-test.c
 <at>  <at>  -465,6 +465,11  <at>  <at>  int main (int argc, char **argv)
  	parse_options(argc, argv);
+	if (nr_runs <= 0) {
+		fprintf(stderr, "Warning, --loops argument is non-positive. Exiting.\n");
+		exit(-1);
+	}
+
 	signal(SIGINT, stop_log);
  	if (argc >= (optind + 1))
--

-- 
2.1.3

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


Gmane