gmane.linux.rt.user

[PATCH] RFC - rt-tools: Detect whether numa is available at build time

John Kacur — 2012-05-25T23:39:49

This is a preliminary hack, I need to clean it up a little, but incase you
want to give it a try, here is the alpha version.

Note - I stole this methodology from tools/perf

Signed-off-by: John Kacur <jkacur< at >redhat.com>
---
 Makefile                 |   33 +++++++++++++++++++++++++++------
 config/feature-tests.mak |    8 ++++++++
 config/utilities.mak     |    7 +++++++
 3 files changed, 42 insertions(+), 6 deletions(-)
 create mode 100644 config/feature-tests.mak
 create mode 100644 config/utilities.mak

diff --git a/Makefile b/Makefile
index 3a82407..33f5027 100644
--- a/Makefile
+++ b/Makefile
< at >< at > -16,9 +16,6 < at >< at > srcdir?= $(prefix)/src
 
 machinetype = $(shell $(CC) -dumpmachine | \
     sed -e 's/-.*//' -e 's/i.86/i386/' -e 's/mips.*/mips/' -e 's/ppc.*/powerpc/')
-ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
-NUMA := 1
-endif
 
 CFLAGS ?= -D_GNU_SOURCE -Wall -Wno-nonnull -Isrc/include
 LDFLAGS ?=
< at >< at > -31,9 +28,33 < at >< at > else
 CFLAGS+= -O0 -g
 endif
 
-ifeq ($(NUMA),1)
-CFLAGS += -DNUMA

[ANNOUNCE] 3.0.32-rt52

Steven Rostedt — 2012-05-22T20:19:36

Dear RT Folks,

I'm pleased to announce the 3.0.32-rt52 stable release.


This release is just an update to the new stable 3.0.32 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

  Head SHA1: 63166b1a384148473180f7bef83e71409e38de14


Or to build 3.0.32-rt52 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.32.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.32-rt52.patch.xz



Enjoy,

[ANNOUNCE] 3.2.18-rt29

Steven Rostedt — 2012-05-22T15:01:48

Dear RT Folks,

I'm pleased to announce the 3.2.18-rt29 stable release.


This release is just an update to the new stable 3.2.18 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

  Head SHA1: c96da77dcbdad05e0d707f443328e708f7cb024a


Or to build 3.2.18-rt29 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.18.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.18-rt29.patch.xz



Enjoy,

Non-free firmware and proprietary Radeon driver on OSADL kernel

Yoann LE BARS — 2012-05-18T22:54:02

Hello everybody out there!

I use OSADL last stable real-time kernel from Pengutronix
(<http://pengutronix.de/software/linux-rt/debian_en.html>) on a computer
which configuration is given in the end of this message.

On this computer, I am using Debian Squeeze (6.0), and, because I have
to do some live recording combined with MIDI playing, I need to use a
real-time kernel. As I am using Debian stable, I want to use the most
stable kernel. Therefore, I have chosen OSADL kernel.

But I am experiencing some troubles, linked with my graphic card.
Tested on the classic kernel, I need to install “firmware-linux-nonfree”
and the proprietary Catalyst driver for my graphic card. If not, then
power consumption is too important, then too much heat is dissipated and
display freezes after few minutes. To install the proprietary driver, I
have done the following:

# aptitude install fglrx-source fglrx-driver fglrx-glx fglrx-control
fglrx-atieventsd module-assistant build-essential linux-headers-2.6
# module-assist

Real time micro benchmark suite - thread priority fix

Venkat Subbiah — 2012-05-17T21:15:52

Not sure whether Real time micro benchmark suite is still being 
maintained at http://sourceforge.net/projects/rtmicrobench. The latest 
code from sourceforge has issues while running rtmb_c tests. It fails 
complaining about not being able to set thread priority.  Here's a fix 
for it.

https://github.com/vsubbiah/rtmb/commit/2a6714030a4009b50b76e99a83bf4b042cc82780

Thanks,
Venkat
--
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

[PATCH -rt] MIPS: Octeon: convert smp_reserve_lock to raw spinlock

Yong Zhang — 2012-05-17T10:15:09

From: Yong Zhang <yong.zhang< at >windriver.com>

Because __cpu_disable is called in atomic context and spinlock
is a mutex on -rt.

Signed-off-by: Yong Zhang <yong.zhang0< at >gmail.com>
---
 arch/mips/cavium-octeon/smp.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index ef9c34a..473c72b 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
< at >< at > -257,7 +257,7 < at >< at > DEFINE_PER_CPU(int, cpu_state);
 
 extern void fixup_irqs(void);
 
-static DEFINE_SPINLOCK(smp_reserve_lock);
+static DEFINE_RAW_SPINLOCK(smp_reserve_lock);
 
 static int octeon_cpu_disable(void)
 {
< at >< at > -266,7 +266,7 < at >< at > static int octeon_cpu_disable(void)
 if (cpu == 0)
 return -EBUSY;
 
-spin_lock(&smp_reserve_lock);
+raw_spin_lock(&smp_reserve_lock);
 
 set_cpu_online(cpu, false);
 cpu_clear(cpu, cpu_callin_map);
< at >< at > -277,7 +277,7 < at >< at > static int octeon_cpu_disable(void)
 flush_cache_all();
 local_flush_tlb_all();
 
-spin_unlock(&smp_

[PATCH][UPSTREAM]net,RT:Remove preemption disabling in netif_rx()

Priyanka Jain — 2012-05-17T04:05:11

1)enqueue_to_backlog() (called from netif_rx) should be
  bind to a particluar CPU. This can be achieved by
  disabling migration. No need to disable preemption

2)Fixes crash "BUG: scheduling while atomic: ksoftirqd"
  in case of RT.
  If preemption is disabled, enqueue_to_backog() is called
  in atomic context. And if backlog exceeds its count,
  kfree_skb() is called. But in RT, kfree_skb() might
  gets scheduled out, so it expects non atomic context.

3)When CONFIG_PREEMPT_RT_FULL is not defined,
 migrate_enable(), migrate_disable() maps to
 preempt_enable() and preempt_disable(), so no
 change in functionality in case of non-RT.

-Replace preempt_enable(), preempt_disable() with
 migrate_enable(), migrate_disable() respectively
-Replace get_cpu(), put_cpu() with get_cpu_light(),
 put_cpu_light() respectively

Signed-off-by: Priyanka Jain <Priyanka.Jain< at >freescale.com>
Acked-by: Rajan Srivastava <Rajan.Srivastava< at >freescale.com>
---
 Testing: Tested successfully on p4080ds(8-core SMP system)  

 net/core/d

[PATCH 1/2] V3: cyclictest: clean up getopt_long() parameters

Frank Rowand — 2012-05-15T23:36:08

V3: unchanged from V2

cyclictest getopt_long() parameter clean up.
Clean up before following patch which will add a new option.

  Some elements of long_options were not in alphabetical order.

  Some elements of optstring were not in alphabetical order.

  '-e', '--latency' was missing help text

  short form of --duration ('D') was missing from optstring

  Change a few instances of leading spaces to tabs.

  Add white space to long_options to improve readability.

  Some cases of the switch processing the result of
    getopt_long() were not in alphabetical order.

  Did _not_ clean up option value parsing and processing.

Signed-off-by: Frank Rowand <frank.rowand< at >am.sony.com>
---
 src/cyclictest/cyclictest.c |  143 73 +70 -0 !
 1 file changed, 73 insertions(+), 70 deletions(-)

Index: b/src/cyclictest/cyclictest.c
===================================================================
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
< at >< at > -923,10 +923,11 < at >< at > static void display_help(int e

good load / stress suite?

Matthieu Bec — 2012-05-15T23:08:13

Hello all,

I was wondering what people used to check RT_PREEMPT behavior under 
load/stress?

I'm trying to test the accuracy of my timers and have a test where I 
setup a kernel module with an hr-timer flipping RTS bit on serial COM0 
periodically, which I can look on an oscilloscope. the scope triggers on 
rising edge, I call jitter what shows on the falling side:
under no specific load I get ~ 10 us (worst case waiting a long time)


My initial idea for stressing the system was to compile a kernel, make 
-j 8 (#cores) that I thought would exercise CPU and IO if anything. As 
it happens, it's "mostly good" but I do get occasional (but repeatable) 
wild excursions (>100us)

Looking around, I found a tool called 'stress' - 
http://weather.ou.edu/~apw/projects/stress/
Under these new conditions, the system behaves really well again ~20 us 
stable all the way.

So both tests give different result, I'm not sure which to trust.
I was thinking maybe there is some weird interaction with the kernel and 
building t

Preemption test

Venkat Subbiah — 2012-05-15T20:30:52

Trying to compile Preepmtion test with instructions from 
https://rt.wiki.kernel.org/index.php/Preemption_Test and I run into the 
error below

g++ preempt-test.cc -g -lboost_thread-mt -lboost_program_options -o 
preempt-test
preempt-test.cc:57:40: error: boost/thread/detail/lock.hpp: No such file 
or directory

Is there a later version than v4 from 
ftp://ftp.novell.com/dev/ghaskins/preempt-test-latest.tar.bz2

The git link  
git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/preempt-test.git 
doesn't exist. Is there a git repo some where else.


Thanks,
Venkat
--
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

[PATCH] compile fix for brcm80211 on v3.2.17

Clark Williams — 2012-05-15T19:04:13

Ben,

Found this while building v3.2.17-rt28:

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index f98becc..833cbef 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
< at >< at > -7879,7 +7879,7 < at >< at > brcms_c_recvctl(struct brcms_c_info *wlc, struct d11rxhdr *rxh,
        if (wlc->hw->suspended_fifos) {
                hdr = (struct ieee80211_hdr *)p->data;
                if (ieee80211_is_beacon(hdr->frame_control))
-                       brcms_b_mute(wlc->hw, false);
+                       brcms_b_mute(wlc->hw, false, 0);
        }
 
        memcpy(IEEE80211_SKB_RXCB(p), &rx_status, sizeof(rx_status));

Not sure if that's completely correct but I found another call site for
brcms_b_mute() that also passed 0 flags. 

Clark

[RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

Steven Rostedt — 2012-05-15T14:03:45

The RT patch has been having lots of trouble lately with large machines
and applications running lots of threads. This usually boils down to a
bottle neck of a single lock: the mm->mmap_sem.

The mmap_sem is a rwsem, which can sleep, but it also can be taken with
a read/write lock, where a read lock can be taken by several tasks at
the same time and the write lock can be only taken by a single task.

But due to priority inheritance, having multiple readers makes the code
much more complex, thus the -rt patch converts all rwsems into a single
mutex, where readers may nest (the same task may grab the same rwsem for
read multiple times), but only one task may hold the rwsem at any given
time (for read or write).

When we have lots of threads, the rwsem may be taken often, either for
memory allocation or filling in page faults. This becomes a bottle neck
for threads as only one thread at a time may grab the mmap_sem (which is
shared by all threads of a process).

Previous attempts of adding multiple readers beca

[ANNOUNCE] 3.2.17-rt28

Steven Rostedt — 2012-05-14T18:09:04

Dear RT Folks,

I'm pleased to announce the 3.2.17 stable release.


This release is just an update to the new stable 3.2.17 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

  Head SHA1: 1b5c78bddb7cd30df391c91122d8d77114d8da37


Or to build 3.2.17 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.17.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.17.patch.xz



Enjoy,

[ANNOUNCE] 3.0.31-rt51

Steven Rostedt — 2012-05-14T16:33:34

Dear RT Folks,

I'm pleased to announce the 3.0.31-rt51 stable release.


This release is just an update to the new stable 3.0.31 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

  Head SHA1: f4162227ef21455c1b1bd74565e49e4c596cecb0


Or to build 3.0.31-rt51 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.31.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.31-rt51.patch.xz



Enjoy,

[ANNOUNCE] rt-tests v0.84

John Kacur — 2012-05-11T14:47:53

It's been a while since we've released a new rt-tests.
Clark silently pushed v0.84 to git, so this note is to let you know.
This release is git only - at least for now.

Repo: git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
Branch: master
Tag: v0.84

I also collect patches in my own repo to push to our fearless leader. :)

This is at
 git://git.kernel.org/pub/scm/linux/kernel/git/jkacur/rt-tests.git

Where I've started branch rt-tests-0.84-devel

Thanks, enjoy!

Clark Williams (5):
  [cyclictest] added priority spreading option --priospread
  Revert "cyclictest problem/bug as non-root"
  report number of samples written in hwlatdetect
  change cyclictest measurement thread to check returns and exit on
    error
  version bump to 0.84

Darren Hart (1):
  Makefile: Support user supplied CFLAGS and LDFLAGS

Frank Rowand (6):
  rt-tests: cyclictest segfault with '-a'
  rt-tests: cyclictest avoid unneeded warning
  rt-tests: cyclictest warn of interaction between '-a', '--smp', and
    '--num

[PATCH 1/2] V2: cyclictest: clean up getopt_long() parameters

Frank Rowand — 2012-05-11T00:59:40

cyclictest getopt_long() parameter clean up.
Clean up before following patch which will add a new option.

  Some elements of long_options were not in alphabetical order.

  Some elements of optstring were not in alphabetical order.

  '-e', '--latency' was missing help text

  short form of --duration ('D') was missing from optstring

  Change a few instances of leading spaces to tabs.

  Add white space to long_options to improve readability.

  Some cases of the switch processing the result of
    getopt_long() were not in alphabetical order.

  Did _not_ clean up option value parsing and processing.

Signed-off-by: Frank Rowand <frank.rowand< at >am.sony.com>
---
 src/cyclictest/cyclictest.c |  143 73 +70 -0 !
 1 file changed, 73 insertions(+), 70 deletions(-)

Index: b/src/cyclictest/cyclictest.c
===================================================================
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
< at >< at > -923,10 +923,11 < at >< at > static void display_help(int error)
        "-D

softirq handling / prioritization of the Ethernet traffic

Frieder Rick — 2012-05-10T21:42:46

I would like to know if it is possible to prioritize the Ethernet 
traffic till it reaches napi_gro_receive() or netif_receive_skb() called 
inside the network card driver.

First I thought it is possible by the prioritization of the irq/XX-ethX 
thread which is used by the network card and the NET_RX_SOFTIRQ, 
NET_TX_SOFTIRQ threads. Till I read that the split from software 
interrupts to threads are gone in the RT patch. Now I'm a bit confused 
and unsure about the softirq handling.

I used ftrace to determine the path of an incoming packet and it looks 
to me that the softirq is prozessed inside the irq/18-eth1 thread. So if 
I give the irq/18-eth1 a higher priority than the others, can I be sure 
that it gets not interrupted?

here a part from my ftrace:

      irq/18-eth1-1738  [001]  1366.914708: function:             
e1000_intr <-- irq_forced_thread_fn
      irq/18-eth1-1738  [001]  1366.914711: function:             
__napi_schedule <-- e1000_intr
[...]
      irq/18-eth1-1738  [001]  1366.914718: fu

Using patch-2.6.33.7.2-rt30 increases latency and CPU usage?

Grant Edwards — 2012-05-09T21:18:10

I've been doing some interrupt latency testing using a board running a
400MHz ARM9 (an Atmel at19sam9g20).  I'm measuring interrupt latency
of an ISR attached to external interrupt pin IRQ0.

I built three kernels from scratch and ran the same test on all three:

 2.6.30          
 2.6.33.7        
 2.6.33.7-rt30  

All kernels are built using the standard AT91 patches from
http://maxim.org.za/at91_26.html.  The 2.6.30 kernel also has a set of
patches distributed by Atmel.

The 2.6.33.7-rt30 kernel is built from the same sources as the 2.6.33.7
kernel with the addition of the 2.6.33.6-rt30 patch.

I don't have enough data to say much about worst-case latency, but
after looking a few thousand samples I can say that...

 * 2.6.30 and 2.6.33.7 are pretty much the same: there is as much
   variation between test runs as there is between kernels.

 * Typical latency with RT patch is 3X the latency without it.

 * CPU idle time during test is 10% with RT patch and 30% without.

IOW: the real-time patch for 2.6.33

[PATCH] rt-tests / gitignore: Exclude patches and .a libs too.

John Kacur — 2012-05-09T15:37:36

Minor fix to make working with git nicer.
Now that we're building a lib, we need to exclude it from git status output.
Do the same for patches we generate or apply.

Signed-off-by: John Kacur <jkacur< at >redhat.com>
---
 .gitignore |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 047925c..1924e73 100644
--- a/.gitignore
+++ b/.gitignore
< at >< at > -3,6 +3,8 < at >< at >
 *.o
 *.tar.gz
 *.d
+*.patch
+*.a
 tmp
 patches
 ChangeLog

BUG - "scheduling while atomic" on a irq handler (s3c-mci)

Christophe Huriaux — 2012-05-09T14:07:13

Hi everyone,

   I am facing a problem while trying to run a rt-patched 3.2.y kernel
with PREEMPT_RT_FULL on a mini2440 board (ARM based s3c2440 SoC) :
whilst a vanilla kernel (with PREEMPT_LL) works like a charm,
PREEMPT_RTB and PREEMPT_RT_FULL makes the MMC/SD driver  (s3cmci)
hang, which result in the kernel waiting indefinitely for the root fs
to mount.

  I think that the IRQ handling of the driver is somehow disturbed by
the changes made by the RT patch. When using PREEMPT_RTB I can see the
following message in the console :

BUG: scheduling while atomic: irq/37-s3c-mci/253/0x00000102
Modules linked in:
Function entered at [<c000e90c>] from [<c029f478>]
Function entered at [<c029f478>] from [<c029fc3c>]
Function entered at [<c029fc3c>] from [<c00559c0>]
Function entered at [<c00559c0>] from [<c01dd4c8>]
Function entered at [<c01dd4c8>] from [<c0024a0c>]
Function entered at [<c0024a0c>] from [<c0024d9c>]
Function entered at [<c0024d9c>] from [<c0024fe8>]
Function entered at [<c0024fe8>] from [<c0025140>

[PATCH] rt-tests / cyclictest: Make cyclictest fail if it cannot run with requested priority.

John Kacur — 2012-05-09T14:03:03

Currently if a non-root user requests a priority higher than the soft limit in
/etc/security/limits.conf
the call to sched_setscheduler will silently fail and the user will be running
with priority of 0. Cyclictest will not complain, and display the
requested priority resulting in seemingly poor results.

The following patch fixes this by doing two things.

1. If the requested priority is higher than the soft limit but lower than the
hard limit, it will raise the soft limit to the requested priority.

2. If the requested priority is higher than the hard limit, it will fail with a
warning.

The patch should not affect privileged users.

Reported-by: Nicholas Mc Guire <der.herr< at >hofr.at>
Signed-off-by: John Kacur <jkacur< at >redhat.com>
---
 src/cyclictest/cyclictest.c |   80 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 79 insertions(+), 1 deletions(-)

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index e8649c7..c44df6a 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cy