Rafael Vega | 25 Sep 18:53 2014
Picon

Fwd: CpuFreq Laptop Scaling broken?

Hi,

I'm jumping into this thread as suggested by the folks at
linux-audio-user. I am the poster of the thread that Harry mentioned.
I would like to help resolve this issue but I'm not sure how. Please
advise and I'll try to help as much as I can. Here are some links with
relevant information (I think) regarding this issue:

The same post Harry mentioned:
http://forums.debian.net/viewtopic.php?f=5&t=117613&p=554333#p554333

Another Debian user reporting similar problems, he "fixed" it by using
an older kernel:
http://forums.debian.net/viewtopic.php?f=5&t=116307

The thread I started on linux-audio-user. Another person reports he
has the same issue in Arch´s package of the RT kernel.
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-September/099285.html

An issue I reported on the thermald git repository. I originally
thought the problem had to do with thermald. There are some hopefully
useful syslog messages there.
https://github.com/01org/thermal_daemon/issues/39#issuecomment-56846550

Rafael Vega.

--

-- 

Rafael Vega
email.rafa <at> gmail.com
(Continue reading)

Chris.Pringle | 23 Sep 12:55 2014

Workqueue "scheduling while atomic" issues in v3.12.19-rt30

Dear All,

We've come across a number of "scheduling while atomic" BUGs after 
upgrading from v3.0 (Freescale SDK v1.2.1) to v3.12.19-rt30 (Freescale SDK 
v1.6) on a P2041 (e500mc core).

2014 Sep 22 17:20:07.984 (none) kernel: BUG: scheduling while atomic: 
rcuc/3/31/0x00000002 
2014 Sep 22 17:20:07.984 (none) kernel: Modules linked in: cryptodev(O) 
ssp(O) 
2014 Sep 22 17:20:07.984 (none) kernel: Preemption disabled at:[< (null)>] 
  (null)
2014 Sep 22 17:20:07.984 (none) kernel:  
2014 Sep 22 17:20:07.984 (none) kernel: CPU: 3 PID: 31 Comm: rcuc/3 
Tainted: G           O 3.12.19-rt30 #1
2014 Sep 22 17:20:07.984 (none) kernel: Call Trace:  
2014 Sep 22 17:20:07.984 (none) kernel: [ea0e3bc0] [80006d24] 
show_stack+0x44/0x150 (unreliable)
2014 Sep 22 17:20:07.984 (none) kernel: [ea0e3c00] [80677eb4] 
dump_stack+0x7c/0xdc 
2014 Sep 22 17:20:07.984 (none) kernel: [ea0e3c20] [80675490] 
__schedule_bug+0x84/0xa0 
2014 Sep 22 17:20:07.984 (none) kernel: [ea0e3c30] [806725b8] 
__schedule+0x458/0x4e0 
2014 Sep 22 17:20:07.985 (none) kernel: [ea0e3d30] [80672710] 
schedule+0x30/0xd0 
2014 Sep 22 17:20:07.985 (none) kernel: [ea0e3d40] [80673338] 
rt_spin_lock_slowlock+0x140/0x288
2014 Sep 22 17:20:07.985 (none) kernel: [ea0e3db0] [8003f43c] 
__queue_work+0x18c/0x280
(Continue reading)

DIXLOR | 22 Sep 15:27 2014
Picon

PTRACE_TRACEME doesn't work: function not implemented

kernel 3.14 + patch-3.14.12-rt9.patch.gz

# strace  anything

strace: test_ptrace_setoptions_for_all: PTRACE_TRACEME strace: 
test_ptrace_setoptions_for_all: PTRACE_TRACEME doesn't work: function not 
implemented
--
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

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)


Gmane