Pavel Vasilyev | 17 Sep 15:08 2014
Picon

Why in 3.14 patch some things do not have compared with 3.2?


Subj?

--- arch/x86/kernel/dumpstack_64.c 2014-03-08 12:54:32.968951000 +0400
+++ arch/x86/kernel/dumpstack_64.c 2012-03-22 00:09:30.000000000 +0400
 <at>  <at>  -21,10 +21,14  <at>  <at> 
                 (N_EXCEPTION_STACKS + DEBUG_STKSZ/EXCEPTION_STKSZ - 2)

  static char x86_stack_ids[][8] = {
+#if DEBUG_STACK > 0
                 [ DEBUG_STACK-1                 ]       = "#DB",
+#endif
                 [ NMI_STACK-1                   ]       = "NMI",
                 [ DOUBLEFAULT_STACK-1           ]       = "#DF",
+#if STACKFAULT_STACK > 0
                 [ STACKFAULT_STACK-1            ]       = "#SS",
+#endif
                 [ MCE_STACK-1                   ]       = "#MC",
  #if DEBUG_STKSZ > EXCEPTION_STKSZ
                 [ N_EXCEPTION_STACKS ...
--- arch/x86/kernel/cpu/common.c 2014-03-08 12:54:32.968951000 +0400
+++ arch/x86/kernel/cpu/common.c 2012-08-15 07:06:04.000000000 +0400
 <at>  <at>  -1051,7 +1051,9  <at>  <at> 
   */
  static const unsigned int exception_stack_sizes[N_EXCEPTION_STACKS] = {
           [0 ... N_EXCEPTION_STACKS - 1]        = EXCEPTION_STKSZ,
+#if DEBUG_STACK > 0
           [DEBUG_STACK - 1]                     = DEBUG_STKSZ
+#endif
  };
(Continue reading)

Mushtaq Khan | 17 Sep 11:12 2014
Picon

BUG: scheduling while atomic

Hi,
 I see error message "BUG: scheduling while atomic"intermittently. As
per other post on similar  issue, this happens when schedule is called
from either interrupt
 context or some other atomic operation (Might be after acquiring
spinlock). But from the call trace am not getting any clue, please
help me guide  on this issue.
Using Linux 3.4rt.

 BUG: scheduling while atomic: dslmgmt/538/0x00000201
 Modules linked in: iptable_mangle init_addr(  (null) -   (null)),
core_addr(c036
 9000 - c0369210)
  iptable_filter init_addr(  (null) -   (null)), core_addr(c0362000 - c03620b0)
  ip_tables init_addr(  (null) -   (null)), core_addr(c0359000 - c035b618)
  xt_multiport init_addr(  (null) -   (null)), core_addr(c034f000 - c034f2d8)
  xt_mark init_addr(  (null) -   (null)), core_addr(c0348000 - c0348098)
  xt_mac init_addr(  (null) -   (null)), core_addr(c0342000 - c03420b4)
  xt_DSCP init_addr(  (null) -   (null)), core_addr(c033c000 - c033c388)
  xt_dscp init_addr(  (null) -   (null)), core_addr(c0335000 - c0335128)
  pwrmngtd(P) init_addr(  (null) -   (null)), core_addr(c032e000 - c032f54c)
  bcmvlan(P) init_addr(  (null) -   (null)), core_addr(c030a000 - c031a598)
  p8021ag(P) init_addr(  (null) -   (null)), core_addr(c02e0000 - c02e1120)
  bcmarl(P) init_addr(  (null) -   (null)), core_addr(c02d7000 - c02d7e74)
  nciTMSkmod(P) init_addr(  (null) -   (null)), core_addr(c0280000 - c029ffc8)
  bcm_enet init_addr(  (null) -   (null)), core_addr(c01e4000 - c02078f4)
  adsldd(P) init_addr(  (null) -   (null)), core_addr(c011b000 - c0150c78)
  bcmxtmcfg(P) init_addr(  (null) -   (null)), core_addr(c009a000 - c00a5e28)
  pktflow(P) init_addr(  (null) -   (null)), core_addr(c0067000 - c0074800)
  bcm_bpm(P) init_addr(  (null) -   (null)), core_addr(c0045000 - c0046470)
(Continue reading)

Harry van Haaren | 5 Sep 14:06 2014
Picon

Re: CpuFreq Laptop Scaling broken?

On Wed, Aug 27, 2014 at 4:07 PM, Viresh Kumar
> Some more prints inside  cpufreq_get_policy() might take us closer..

I've time to continue this bug hunt again:

With more prints:

struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
{
    struct cpufreq_policy *policy = NULL;
    unsigned long flags;

    if ( cpufreq_disabled() )
  {
    printk("RT test errror: cpufreq_disabled(), returning NULL\n");
    return NULL;
  }
  if (cpu >= nr_cpu_ids)
  {
    printk("cpu > nr_cpu_ids\n");
        return NULL;
  }

    if (!down_read_trylock(&cpufreq_rwsem))
  {
    printk("RT debug: down_read_trylock( &cpufreq_rwsem ) returned NULL\n");
        return NULL;
  }

   <snip>
(Continue reading)

Jeff Epler | 1 Sep 16:30 2014
Picon

[RFC 0/4] Improving SPI driver latency (vs v3.8.13.14-rt31)

I recently became interested in realtime access to an SPI device on the
Odroid U3 platform, with a goal of running a repetitive task every 1ms
that performs two SPI transactions. (for http://linuxcnc.org/
interfacing to a http://mesanet.com/ "Anything I/O" card)

Unfortunately, I found that there were frequent large latencies, some
over 10ms, when using /dev/spidev.  This seems to be typical of others'
experience using it (for instance, one can find threads discussing
disappointing RT performance of SPI on the beaglebone and pandaboard; at
least one raspberry pi project chose to implement a pure userspace SPI
driver instead of using spidev)

At all levels of the SPI stack, I found things that could be improved if
lowest delays are the goal.  I doubt that in their current form these
changes are suitable to be incorporated in preempt-rt, but I hope that 
this might spur some discussion that would ultimately lead to better
realtime performance of SPI in the preempt-rt kernel.

As you may know, the kernel's spi driver stack consists of
    spidev    - implementation of the /dev/spidev* device
    spi       - hardware-independent kernel layer
    spi-xyzzy - hardware-dependent driver for xyzzy hardware
                (s3c64xx in my device)

I fixed causes of latency at each layer
 * First, I eliminated per-ioctl memory allocations in spidev 
 * Second, I made __spi_sync *actually* synchronous, rather than
   being a wrapper over spi_async + wait_for_completion; and changed
   spidev to use spi_sync
 * Third, in the hardware-dependent code I moved DMA acquisition to
(Continue reading)

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)


Gmane