Robin | 30 Aug 15:02 2014
Picon

(unknown)

unsubscribe linux-rt-users
--
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

Asier Tamayo | 28 Aug 12:24 2014

RV: Migrating from Xenomai


Hello all,

I have been using Xenomai for some time, in an Atom N270 based board, running a kernel 2.6.34 compiled with
Sysgo's ELinOS 5.2 tool. I have mainly used the native skin, as well as some RTDM drivers.

Now, I have to start using a new AMD G-Series T52R based board, and kernel 2.6.34 shows some problems with it.
Therefore, I have to update the kernel to a newer one, but ELinOS has dropped the Xenomai support. 

One of the options I see is migrating my application to the PREEMPT_RT patch, which is already supported by
ELinOS. Has anyone got any experience with it? Which difficulties should I expect to find in the migration
process? Any special problems with RTDM, shared memory...?

Has anyone got information about latencies and performance comparison between Xenomai and PREEMPT_RT
patch? I have found some in https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf, but it is a bit outdated.

Best regards,

Asier Tamayo

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

Asier Tamayo | 28 Aug 12:46 2014

RE: Migrating from Xenomai


Hello all,

I have been using Xenomai for some time, in an Atom N270 based board, running a kernel 2.6.34 compiled with
Sysgo's ELinOS 5.2 tool. I have mainly used the native skin, as well as some RTDM drivers.

Now, I have to start using a new AMD G-Series T52R based board, and kernel 2.6.34 shows some problems with it.
Therefore, I have to update the kernel to a newer one, but ELinOS has dropped the Xenomai support. 

One of the options I see is migrating my application to the PREEMPT_RT patch, which is already supported by
ELinOS. Has anyone got any experience with it? Which difficulties should I expect to find in the migration
process? Any special problems with RTDM, shared memory...?

Has anyone got information about latencies and performance comparison between Xenomai and PREEMPT_RT
patch? I have found some in https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf, but it is a bit outdated.

Best regards,

Asier Tamayo

--
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 | 27 Aug 03:54 2014

[ANNOUNCE] 3.12.26-rt40


Dear RT Folks,

I'm pleased to announce the 3.12.26-rt40 stable release.

This release is just an update to the new stable 3.12.26 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: 5b55c23934a2d5fb61cf0a82ade85042783308c9

Or to build 3.12.26-rt40 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.26.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.26-rt40.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 | 27 Aug 00:10 2014

[PATCH -rt 3.10.x] mce: don't try to wake thread before it exists.

If a broken machine with issues raises an MCE irq event real
early in the boot, it can try and wake the -rt specific handler
thread (mce_notify_helper) before it exists.  (It is created
through a device_initcall that happens later in the boot.)  When
this happens, we see the irq, which calls the wake with a null
pointer, which then panics the machine at boot.

The race between the irq event and thread init is as follows:

mce_notify_irq();
  --> mce_notify_work();
        --> wake_up_process(mce_notify_helper);

device_initcall_sync(mcheck_init_device);
  --> mce_notify_work_init();
        --> mce_notify_helper = kthread_run(mce_notify_helper_thread, ...);

So, clearly if the IRQ event happens before the device_initcall,
the mce_notify_helper pointer (at global file scope and hence BSS)
will still be NULL, resulting in the following panic at boot:

  CPU: Physical Processor ID: 0
  CPU: Processor Core ID: 0
  ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
  ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
  mce: CPU supports 22 MCE banks
  CPU0: Thermal monitoring enabled (TM1)
  Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
  Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0
  tlb_flushall_shift: 6
(Continue reading)

Harry van Haaren | 25 Aug 17:03 2014
Picon

Re: CpuFreq Laptop Scaling broken?

On Mon, Aug 25, 2014 at 3:57 PM, Pavel Vasilyev <pavel <at> pavlinux.ru> wrote:
>>>> # Attempt to set min freq of 2GHz (max) of this core2duo
>>>> $ echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
>>>> bash: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq: Permission
>>>> denied
>
> cpuinfo_min_freq - Read-only file, use scaling_min_freq

$ echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
bash: echo: write error: Invalid argument

No success there.
--
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

Harry van Haaren | 25 Aug 14:28 2014
Picon

CpuFreq Laptop Scaling broken?

Hi -rt users, and CC's,

I'm attempting to squeeze the lowest audio-latency out of a laptop as possible,
and in doing so would like to set the CPU to performance.

CPU in laptop: Intel(R) Core(TM)2 Duo CPU T7300  <at>  2.00GHz

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
ondemand performance

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq

# Attempt to set performance governer
$ echo "performance" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
bash: echo: write error: Invalid argument

# Attempt to set min freq of 2GHz (max) of this core2duo
$ echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
bash: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq: Permission denied

As far as I can tell, it is currently impossible on the -rt kernel to
change CPU governer?
This is necessary for reliable low-latency audio for laptop musicians.

What is necessary to fix cpufreq on -rt? Cheers, -Harry

PS: I've CC'd maintainers of cpufreq, I hope that's OK, otherwise
please inform me of
normal practices on linux-rt-users ML
(Continue reading)

Daniel Wagner | 25 Aug 11:02 2014

Some benchmark results

Hi,

I wanted to know how good or bad mainline vs RT is, therefore I let
MMTests torture my laptop for a while. I selected a few of the supported
benchmarks by MMTests in order to keep to a reasonable time frame.

The aim was to see the impact of normal (no RT) workloads with different
preempt configurations on mainline and RT patched kernel. I tried to not
to change other configuration flags except the preempt one. There are
some small difference due to dependencies but the rest looks ok to me.

http://www.monom.org/rt/mmtests/

Suggestion, improvements, comments?

cheers,
daniel

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

Anders Roxell | 15 Aug 01:52 2014

Merge conflict when forward porting v3.14.12-rt9 onto v3.14.17

Hi all,

I have forward ported v3.14.12-rt9 to v3.14.17 and I got some merge conflicts.
The merge conflicts occured already on v3.14.14.

I maintain a git tree (to support the Linaro stable kernel RT tree) at [1]
meant to integrate the RT development patchset onto the mainline stable
kernel releases (one branch for each major stable kernel release), and
later integrate minor mainline releases into the branches, such that the
branches themselves are purely fast-forward.

Cheers,
Anders

[1] https://git.linaro.org/people/anders.roxell/linux-rt.git

diff --cc kernel/Kconfig.locks
index 8bb92eb,ecee67a..b867a1c
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
 <at>  <at>  <at>  -220,6 -220,9 +220,9  <at>  <at>  <at>  config INLINE_WRITE_UNLOCK_IRQRESTOR

  endif

+ config ARCH_SUPPORTS_ATOMIC_RMW
+       bool
+ 
  config MUTEX_SPIN_ON_OWNER
        def_bool y
-       depends on SMP && !DEBUG_MUTEXES && !PREEMPT_RT_FULL
(Continue reading)

Joakim Hernberg | 14 Aug 19:21 2014
Picon

[RFC PATCH] fix the broken 'e' command line argument of cyclictest

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index 4547831..c54972b 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
 <at>  <at>  -1232,7 +1232,7  <at>  <at>  static void process_options (int argc, char *argv[], int max_cpus)
                        {"help",             no_argument,       NULL, OPT_HELP },
                        {NULL, 0, NULL, 0}
                };
-               int c = getopt_long(argc, argv, "a::A::b:Bc:Cd:D:Efh:H:i:Il:MnNo:O:p:PmqrRsSt::uUvD:wWT:",
+               int c = getopt_long(argc, argv, "a::A::b:Bc:Cd:D:e:Efh:H:i:Il:MnNo:O:p:PmqrRsSt::uUvD:wWT:",
                                    long_options, &option_index);
                if (c == -1)
                        break;
 <at>  <at>  -1280,6 +1280,14  <at>  <at>  static void process_options (int argc, char *argv[], int max_cpus)
                case 'D':
                case OPT_DURATION:
                        duration = parse_time_string(optarg); break;
+               case 'e':
+               case OPT_LATENCY:
+                       /* power management latency target value */
+                       /* note: default is 0 (zero) */
+                       latency_target_value = atoi(optarg);
+                       if (latency_target_value < 0)
+                               latency_target_value = 0;
+                       break;
                case 'E':
                case OPT_EVENT:
                        enable_events = 1; break;
 <at>  <at>  -1421,13 +1429,6  <at>  <at>  static void process_options (int argc, char *argv[], int max_cpus)
                /* long only options */
(Continue reading)

Joakim Hernberg | 14 Aug 19:29 2014
Picon

[RFC PATCH] make SMP option only use online cpus (cyclictest)

When I boot my 8 core i7 laptop with the maxcpus=4 kernel boot flag,
cyclictest -S runs 8 threads.  This patch makes it only use the online
cpus instead.

diff --git a/src/cyclictest/cyclictest.c
b/src/cyclictest/cyclictest.c index 4547831..92fc346 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
 <at>  <at>  -1740,7 +1740,7  <at>  <at>  int main(int argc, char **argv)
        sigset_t sigset;
        int signum = SIGALRM;
        int mode;
-       int max_cpus = sysconf(_SC_NPROCESSORS_CONF);
+       int max_cpus = sysconf(_SC_NPROCESSORS_ONLN);
        int i, ret = -1;
        int status;

diff --git a/src/cyclictest/rt_numa.h b/src/cyclictest/rt_numa.h
index e64c446..c2b3e85 100644
--- a/src/cyclictest/rt_numa.h
+++ b/src/cyclictest/rt_numa.h
 <at>  <at>  -128,7 +128,7  <at>  <at>  static int rt_numa_numa_node_of_cpu(int cpu)
        int max_node, max_cpus;

        max_node = numa_max_node();
-       max_cpus = sysconf(_SC_NPROCESSORS_CONF);
+       max_cpus = sysconf(_SC_NPROCESSORS_ONLN);

        if (cpu > max_cpus) {
                errno = EINVAL;
(Continue reading)


Gmane