[ANNOUNCE] rt-tests-1.10

[John Kacur]

Dear RT Folks,

I'm pleased to announce rt-tests-1.10

To download rt-tests:
using git, clone one of the following
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

The latest tag is v1.10
The correct branch is unstable/devel/latest

Tarballs are also available here:
https://kernel.org/pub/linux/utils/rt-tests

Older version tarballs are available here:
https://kernel.org/pub/linux/utils/rt-tests/older

Your fixes, development patches, comment and bug reports are always welcome!

Enjoy!

John Kacur

Anders Roxell (1):
  Makefile: manpages: only add get_cyclictest_snapshot if PYLIB

Daniel Wagner (36):
  cyclictest: Use numa library helpers in get_available_cpus()
  cyclicdeadline: Streamline usage output and man page
  cyclicdeadline: Add long command line options
  deadline_test: Streamline usage output and man page
  oslat: Streamline usage output and man page
  pip_stress: Add command line parser
  pi_stress: Streamline usage output and man page
  pmqtest: Streamline usage output and man page
  ptsematest: Streamline usage output and man page
  queuelat: Streamline usage and man page
  rt-migrate-test: Streamline usage and man page
  signaltest: Streamline usage and man page
  sigwaittest: Streamline usage and man page
  ssdd: Streamline usage and man page
  svsematest: Streamline usage and man page
  hackbench: Streamline usage and man page
  rt-utils: Introduce parse_mem_string()
  oslat: Use string parser utilies
  cyclictest: Remove deadcode checking for NUMA
  rt-numa: Introduce NUMA helpers
  cyclictest: Use parse_cpumask() from rt-numa.h
  oslat: Use parse_cpumask() from rt-numa.h
  rt-numa: Move thread placement code to rt-numa library
  signaltest: Implement thread placing
  cyclicdeadline: Remove dead code
  cyclicdeadline: Use common error handlers
  cyclicdeadline: Add quiet command line option
  pmqtest: Move statictic output into print_stat()
  pmqtest: Add quiet command line option
  ptsematest: Move statictic output into print_stat()
  ptsematest: Add quiet command line option
  svsematest: Move statictic output into print_stat()
  svsematest: Add quiet command line option
  sigwaittest: Move statictic output into print_stat()
  sigwaittest: Add quiet command line option
  rt-migrate-test: Add quiet command line option

John Kacur (24):
  rt-tests: makefile: undefine PYLIB if empty
  rt-tests: queuelat: Remove unused variable 'index'
  rt-tests: remove pi_tests.spec
  rt-tests: cyclictest: A few style changes from checkpatch.pl
  rt-tests: rt-sched.c: Style change
  rt-tests: rt-utils.c: Correct mix of spaces and tabs in code
indentation
  rt-tests: pi_stress.c: Change unsigned to unsigned int
  rt-tests: pip_stress.c: Remove unnecessary brackets
  rt-tests: pmqtest.c: Fix spacing around parentheses
  rt-tests: ptsematest.c: Fix spacing around parentheses
  rt-tests: queuelat.c: Fix various style problems
  rt-tests: rt-migrate-test.c: Fix spacing around parentheses
  rt-tests: cyclicdeadline.c: Fix spacing around commas
  rt-tests: deadline_test.c: Fix spacing around commas
  rt-tests: signaltest.c: Fix various style problems
  rt-tests: sigwaittest.c: Fix spacing around brackets
  rt-tests: ssdd.c: Remove unncessary "else"
  rt-tests: svsematest.c: Fix various style problems
  rt-tests: Don't compress man pages by default
  rt-tests: determine_maximum_mpps.sh: Add a menu to get user settings.
  rt-tests: queuelat: Remove get_cpuinfo_mhz.sh and old Makefile
  rt-tests: queuelat: Add a manpage for determine_maximum_mpps.sh
  rt-tests: determine_maximum_mpps.sh: Change the -c option to -a
  rt-tests: Makefile - update version to v1.10

Kurt Kanzenbach (4):
  rt-tests: rt-utils: Mark internal functions static
  rt-tests: rt-utils: Add function to close trace fds
  rt-tests: cyclictest: Close correct trace fds
  rt-tests: oslat: Close trace fds

Peter Xu (1):
  rt-tests: oslat: Allow build for not supported archs

Sebastian Andrzej Siewior (4):
  cyclictest: Only report the first incident
  signaltest: Remove drunk code
  signaltest: Don't expect trace interface at /proc
  signaltest: Fix break value argument

 Makefile   |  36 ++--
 src/cyclictest/cyclictest.c| 276 +---
 src/hackbench/hackbench.8  |  70 +++---
 src/hackbench/hackbench.c  | 102 +
 src/include/rt-numa.h  |  21 ++
 src/include/rt-utils.h |   2 +
 src/lib/rt-numa.c  | 135 
 src/lib/rt-sched.c |   2 +-
 src/lib/rt-utils.c |  60 +-
 src/oslat/oslat.8  |   2 +-
 src/oslat/oslat.c  | 210 ++
 src/pi_tests/pi_stress.8   |  79 ---
 src/pi_tests/pi_stress.c   | 152 +++--
 src/pi_tests/pi_

[ANNOUNCE] rt-tests-1.9

[John Kacur]

Hello rt-folks! We're pleased to announce a new release of rt-tests - v1.9

- There is a new test called oslat from Peter Xu
- Daniel Wagner started to move some shared functionality into common 
headers
- Clark Williams provided a fix to pi_stress, to put a limit on the number 
of inversion groups.
- And there are various micellaneous fixes from Yunfeng Ye, and from 
myself too.

To download rt-tests:
using git, clone one of the following
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

The latest tag is v1.9

Tarballs are also available here:
https://kernel.org/pub/linux/utils/rt-tests

Older version tarballs are available here:
https://kernel.org/pub/linux/utils/rt-tests/older

Your fixes, development or just bug reports are always welcome!

Enjoy!

John Kacur

Clark Williams (1):
  pi_stress: limit the number of inversion groups to the number of
online cores

Daniel Wagner (4):
  rt-utils: Move timestamp calc helper to common header
  rt-utils: Move time defininitions to common header
  rt-utils: Move ARRAY_SIZE to common header
  signaltest: Only print from the first thread stats when quiet

John Kacur (11):
  cyclictest: Fix setaffinity error on large NUMA machines
  rt-tests: queuelat: Fix storing unsigned long long in int
  rt-tests: improvements to the python style in get_cyclictest_snapshot
  rt-tests: pi_stress.8: Remove unused -t n from the manpage
  rt-tests: ptsematest.8: Update the ptsematest man page
  rt-tests: Add a man page for get_cyclictest_snapshot
  rt-tests: Tweak the cyclictest man page
  rt-tests: Add some files like get_cyclictest_snapshot to .gitignore
  rt-tests: get_cyclictest_snapshot: Warn if no cyclictest instance
found
  rt-tests: Install new man page get_cyclictest_snapshot.8
  rt-tests: Makefile - update version to v1.9

Peter Xu (3):
  rt-tests: cyclictest: Move ftrace helpers into rt-utils.[ch]
  rt-tests: oslat: Init commit
  rt-tests: oslat: Proper reformat of code

Yunfeng Ye (3):
  rt-tests: cyclictest: Fix -a option fail when max_cpus is more
  rt-tests: hachbench: Update the usage and man page for -F|--fifo
option
  rt-tests: cyclictest: remove the debug log "pid = xxx" in
rstat_shm_open()

 .gitignore|   7 +
 Makefile  |  13 +-
 src/backfire/sendme.c |   3 -
 src/cyclictest/cyclictest.8   |   2 +-
 src/cyclictest/cyclictest.c   | 159 +---
 src/cyclictest/get_cyclictest_snapshot.8  |  44 ++
 src/cyclictest/get_cyclictest_snapshot.py |  59 +-
 src/hackbench/hackbench.8 |   6 +-
 src/hackbench/hackbench.c |   2 +-
 src/include/rt-utils.h|  51 ++
 src/lib/rt-utils.c|  82 ++
 src/oslat/oslat.8 |  66 ++
 src/oslat/oslat.c | 871 ++
 src/pi_tests/pi_stress.8  |   6 -
 src/pi_tests/pi_stress.c  |  23 +-
 src/pmqtest/pmqtest.c |   4 -
 src/ptsematest/ptsematest.8   |   6 +-
 src/ptsematest/ptsematest.c   |   2 -
 src/queuelat/queuelat.c   |  13 +-
 src/signaltest/signaltest.c   |  22 +-
 src/sigwaittest/sigwaittest.c |   2 -
 src/svsematest/svsematest.c   |   2 -
 22 files changed, 1216 insertions(+), 229 deletions(-)
 create mode 100644 src/cyclictest/get_cyclictest_snapshot.8
 create mode 100644 src/oslat/oslat.8
 create mode 100644 src/oslat/oslat.c

Re: [PATCH] rt-tests: backfire: Don't include asm/uaccess.h directly

[John Kacur]

On Tue, 17 Sep 2019, Sultan Alsawaf wrote:

> On Mon, Sep 16, 2019 at 11:57:32PM +0200, John Kacur wrote:
> > Signed-off-by: John Kacur 
> > But please in the future
> > 1. Don't cc lkml on this
> > 2. Include the maintainers in your patch
> 
> Hi,
> 
> Thanks for the sign-off. I was following the instructions listed here:
> https://wiki.linuxfoundation.org/realtime/communication/send_rt_patches

Those are the instructions for rt kernel code.
rt-tests is a users space program to test the performance of the rt 
kernel.

Always just check if there is a MAINTAINERS file (there is)
when you clone the git repo.

Thanks

John

> 
> I couldn't find any documentation of how to send patches for rt-tests. Is 
> there
> a different set of patch submission instructions on a wiki somewhere I missed?
> 
> Thanks,
> Sultan
> 

Re: [PATCH] rt-tests: backfire: Don't include asm/uaccess.h directly

[John Kacur]

On Tue, 17 Sep 2019, Sebastian Andrzej Siewior wrote:

> On 2019-09-16 23:57:32 [+0200], John Kacur wrote:
> > Signed-off-by: John Kacur 
> 
> Hmmm. I remember this thing came up years ago in the Debian BTS and then
> that backfire module got removed from the Debian package because there
> was no need for it.
> Just to clarify: is there any need to keep this module or do I mix up
> things?
> 
> Sebastian
> 

The cost of carrying the code should anyone wish to revive this is very 
small, and it wouldn't take much effort to get it going again.

It could go either way, I'm fine with carrying it for now.

John

Re: [PATCH] rt-tests: backfire: Don't include asm/uaccess.h directly

[John Kacur]

On Tue, 3 Sep 2019, Sultan Alsawaf wrote:

> From: Sultan Alsawaf 
> 
> Architecture-specific uaccess.h headers can have dependencies on
> linux/uaccess.h (i.e., VERIFY_WRITE), so it cannot be included directly.
> Since linux/uaccess.h includes asm/uaccess.h, just do that instead.
> 
> This fixes compile errors with certain kernels and architectures.
> 
> Signed-off-by: Sultan Alsawaf 
> ---
>  src/backfire/backfire.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/backfire/backfire.c b/src/backfire/backfire.c
> index aaf9c4a..a8ac9f5 100644
> --- a/src/backfire/backfire.c
> +++ b/src/backfire/backfire.c
> @@ -30,8 +30,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#include 
>  #include 
>  
>  #define BACKFIRE_MINOR MISC_DYNAMIC_MINOR
> -- 
> 2.23.0
> 
> 

Signed-off-by: John Kacur 
But please in the future
1. Don't cc lkml on this
2. Include the maintainers in your patch

Thanks

[ANNOUNCE] rt-tests-1.5

[John Kacur]

Mostly small clean-ups and bug fixes,

There was a fix to a bug where the paramater to -t was being ignored if 
the user didn't also specify the affinity -a.

This was a bit of fallout from the changes to automatically use numa if
support for it is available.

Bug reports and patches, are always welcome.

John Kacur

Clone
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
branches

Branches
unstable/devel/latest (rt-tests: Version 1.5)
unstable/devel/latest-devel (for latest development of Version 1.5)

tarballs are available here
https://kernel.org/pub/linux/utils/rt-tests

older version tarballs are available to in
https://kernel.org/pub/linux/utils/rt-tests/older

John Kacur (3):
  rt-tests: Use gettid from rt-utils.c everywhere
  rt-tests: hwlatdetect: Remove kmodule options and clean-up help
  rt-tests: cyclictest: Without -t default to 1 thread in numa case

Kurt Kanzenbach (6):
  rt-tests: deadline: Remove duplicated code for sched_{set,get}_attr
  rt-tests: cyclicdeadline: Remove unused getcpu code
  rt-tests: deadline: Remove duplicated gettid() code
  rt-tests: cyclicdeadline: Add options to usage
  rt-tests: cyclicdeadline: Print fail only if something failed
  rt-tests: cyclicdeadline: Fix cgroup setup

Qiao Zhao (1):
  ptsematest, sigwaittest, pmqtest, svsematest reprot error "Could not
access /sys/kernel/debug/tracing/tracing_enabled"

 src/cyclictest/cyclictest.c   | 13 ++---
 src/hwlatdetect/hwlatdetect.8 | 43 +++
 src/hwlatdetect/hwlatdetect.py| 12 +
 src/pmqtest/pmqtest.c |  4 +-
 src/ptsematest/ptsematest.c   |  4 +-
 src/rt-migrate-test/rt-migrate-test.c |  2 -
 src/sched_deadline/cyclicdeadline.c   | 71 ++--
 src/sched_deadline/deadline_test.c| 78 ++-
 src/signaltest/signaltest.c   |  3 --
 src/sigwaittest/sigwaittest.c |  4 +-
 src/svsematest/svsematest.c   |  4 +-
 11 files changed, 51 insertions(+), 187 deletions(-)

-- 
2.20.1

Re: [ANNOUNCE] New release rt-tests-1.4

[John Kacur]

On Fri, 21 Jun 2019, David Runge wrote:

> Hi!
> 
> On 2019-06-20 15:26:30 (+0200), John Kacur wrote:
> > We haven't had a release in a while as people were content to work
> > from git. However, in order to make it easier to use, test, and put
> > into distributions, now would be a good time for an official release.
> Good news! :)
> 
> It seems the tag is not available yet (according to `git tag -l`).
> Could you add it? I would like to package it.
> 
> Thanks a lot!
> 
> Best,
> David
> 
> -- 
> https://sleepmap.de
> 

I just pushed the tags, let me know if you can see them now.

thanks

John

[ANNOUNCE] New release rt-tests-1.4

[John Kacur]

We haven't had a release in a while as people were content to work from 
git. However, in order to make it easier to use, test, and put into 
distributions, now would be a good time for an official release.

There have been a number of interesting changes since 1.3

I'm happy with the way the removal of the --numa from cyclictest is 
working now. What this means is that numa is dectected automatically, so 
you don't have to specify it. You can still force smp with --smp though.

In addition, cpu affinity should work correctly now. Historically there 
were combinations of options in which you couldn't specify cpu affinity, 
but these restrictions have been removed.

We have added a number of new programs to the rt-tests suite

- queuelat
- cyclicdeadline
- deadline_test
- ssdd

queuelat simulates a network queue checking for latency violations in
packet processing.

deadline_test is used to test the deadline scheduler (SCHED_DEADLINE)
cyclicdeadline also tests the deadline scheduler in a cyclictest manner

ssdd has a tracer do a bunch of PTRACE_SINGLESTEPs

There is a new feature that adds a duration option to many of the tests
as a more natural way that iterations to determine how long to test for.

There have also been a number of fix and updates, such as an update.
hwlatdetect no-longer requires a kernel module, instead it uses ftrace.
It also works with python3

CPU counters with SMI counter support has been updated, although I think 
we're due for another. Hint to Daniel :)

So the latest stable / unstable branch (yes the naming is confusing, and 
this will be changed in the future too) is

unstable/devel/latest
If you just to want to use or test the latest then use that

Development for the above is happening here
unstable/devel/latest-devel

This already has some new patches for the deadline tests
This is what developers should development against until
I merge it back into the latest.

Bug reports and patches, are all welcome.

I'd like to step up development, especially bug fixes, and
harden this up. Everything is working reasonably well, but
I'm sure with everyone working the code we can flush out some bugs
and aim for a new stable branch.


So, have fun, and send in your patches and reports!

John Kacur

Clone
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
branches

Branches
unstable/devel/latest (rt-tests: Version 1.4)
unstable/devel/latest-devel (for latest development of Version 1.4)

tarballs are available here
https://kernel.org/pub/linux/utils/rt-tests/

Re: BUG: trace-cmd: trace-cmd record -e failure

[John Kacur]

On Mon, 15 Apr 2019, John Kacur wrote:

> This is a long standing but in trace-cmd.
> 
> [root@pq6-0 tmp]# trace-cmd record -p function -e sched:* sleep 1
>   plugin 'function'
> none
> trace-cmd: Invalid argument
>   Failed filter of 
> /sys/kernel/debug/tracing/events/sched/sched_kthread_stop/filter
> 
> trace-cmd: No such file or directory
>   can not stat 'trace.dat.cpu0'
> 
> ---
> 
> This only happens on large machines, I can only get it to trigger at 
> around 200 cpus. However, it's not complicated, it's simply we're writing
> to the filter file, one per recorder thread until the size of the string
> exceeds the limit.
> 
> We're writing something crazy like this.
> 
> str = 
> (common_pid!=50883)||(common_pid!=50882)||(common_pid!=50881)||(common_pid!=50880)||(common_pid!=50879)||(common_pid!=50878)||(common_pid!=50877)||(common_pid!=50876)||(common_pid!=50875)||(common_pid!=50874)||(common_pid!=50873)||(common_pid!=50872)||(common_pid!=50871)||(common_pid!=50870)||(common_pid!=50869)||(common_pid!=50868)||(common_pid!=50867)||(common_pid!=50866)||(common_pid!=50865)||(common_pid!=50864)||(common_pid!=50863)||(common_pid!=50862)||(common_pid!=50861)||(common_pid!=50860)||(common_pid!=50859)||(common_pid!=50858)||(common_pid!=50857)||(common_pid!=50856)||(common_pid!=50855)||(common_pid!=50854)||(common_pid!=50853)||(common_pid!=50852)||(common_pid!=50851)||(common_pid!=50850)||(common_pid!=50849)||(common_pid!=50848)||(common_pid!=50847)||(common_pid!=50846)||(common_pid!=50845)||(common_pid!=50844)||(common_pid!=50843)||(common_pid!=50842)||(common_pid!=50841)||(common_pid!=50840)||(common_pid!=50839)||(common_pid!=50838)||(common_pid!=50837)||(common_pid!=50836)||(common_pid!=50835)||(common_pid!=50834)||(common_pid!=50833)||(common_pid!=50832)||(common_pid!=50831)||(common_pid!=50830)||(common_pid!=50829)||(common_pid!=50828)||(common_pid!=50827)||(common_pid!=50826)||(common_pid!=50825)||(common_pid!=50824)||(common_pid!=50823)||(common_pid!=50822)||(common_pid!=50821)||(common_pid!=50820)||(common_pid!=50819)||(common_pid!=50818)||(common_pid!=50817)||(common_pid!=50816)||(common_pid!=50815)||(common_pid!=50814)||(common_pid!=50813)||(common_pid!=50812)||(common_pid!=50811)||(common_pid!=50810)||(common_pid!=50809)||(common_pid!=50808)||(common_pid!=50807)||(common_pid!=50806)||(common_pid!=50805)||(common_pid!=50804)||(common_pid!=50803)||(common_pid!=50802)||(common_pid!=50801)||(common_pid!=50800)||(common_pid!=50799)||(common_pid!=50798)||(common_pid!=50797)||(common_pid!=50796)||(common_pid!=50795)||(common_pid!=50794)||(common_pid!=50793)||(common_pid!=50792)||(common_pid!=50791)||(common_pid!=50790)||(common_pid!=50789)||(common_pid!=50788)||(common_pid!=50787)||(common_pid!=50786)||(common_pid!=50785)||(common_pid!=50784)||(common_pid!=50783)||(common_pid!=50782)||(common_pid!=50781)||(common_pid!=50780)||(common_pid!=50779)||(common_pid!=50778)||(common_pid!=50777)||(common_pid!=50776)||(common_pid!=50775)||(common_pid!=50774)||(common_pid!=50773)||(common_pid!=50772)||(common_pid!=50771)||(common_pid!=50770)||(common_pid!=50769)||(common_pid!=50768)||(common_pid!=50767)||(common_pid!=50766)||(common_pid!=50765)||(common_pid!=50764)||(common_pid!=50763)||(common_pid!=50762)||(common_pid!=50761)||(common_pid!=50760)||(common_pid!=50759)||(common_pid!=50758)||(common_pid!=50757)||(common_pid!=50756)||(common_pid!=50755)||(common_pid!=50754)||(common_pid!=50753)||(common_pid!=50752)||(common_pid!=50751)||(common_pid!=50750)||(common_pid!=50749)||(common_pid!=50748)||(common_pid!=50747)||(common_pid!=50746)||(common_pid!=50745)||(common_pid!=50744)||(common_pid!=50743)||(common_pid!=50742)||(common_pid!=50741)||(common_pid!=50740)||(common_pid!=50739)||(common_pid!=50738)||(common_pid!=50737)||(common_pid!=50736)||(common_pid!=50735)||(common_pid!=50734)||(common_pid!=50733)||(common_pid!=50732)||(common_pid!=50731)||(common_pid!=50730)||(common_pid!=50729)||(common_pid!=50728)||(common_pid!=50727)||(common_pid!=50726)||(common_pid!=50725)||(common_pid!=50724)||(common_pid!=50723)||(common_pid!=50722)||(common_pid!=50721)||(common_pid!=50720)||(common_pid!=50719)||(common_pid!=50718)||(common_pid!=50717)||(common_pid!=50716)||(common_pid!=50715)||(common_pid!=50714)||(common_pid!=50713)||(common_pid!=50712)||(common_pid!=50711)||(common_pid!=50710)||(common_pid!=50709)||(common_pid!=50708)||(common_pid!=50707)||(common_pid!=50706)||(common_pid!=50705)||(common_pid!=50704)||(common_pid!=50703)||(common_pid!=50702)||(common_pid!=50701)||(common_pid!=50700)||(common_pid!=50699)||(common_pid!=50698)||(common_pid!=50697)||(common_pid!=50696)||(common_pid!=50695)||(common_pid!=50694)||(common_pid!=50693)||(common_pid!=50692)||(common_pid!=50691)||(common_pid!=50690)||(common_pid!=50689)||(common_pid!=50688)||(common_pid!=50687)||(common_pid!=50686)||(common_pid!=50685)||(common_pid!

BUG: trace-cmd: trace-cmd record -e failure

[John Kacur]

)||(common_pid!=50676)||(common_pid!=50675)||(common_pid!=50674)||(common_pid!=50673)||(common_pid!=50672)||(common_pid!=50671)||(common_pid!=50670)||(common_pid!=50669)||(common_pid!=50668)||(common_pid!=50667)||(common_pid!=50666)||(common_pid!=50665)||(common_pid!=50664)||(common_pid!=50663)||(common_pid!=50662)||(common_pid!=50661)||(common_pid!=50660)||(common_pid!=50659)||(common_pid!=50658)||(common_pid!=50657)||(common_pid!=50656)||(common_pid!=50655)||(common_pid!=50654)||(common_pid!=50653)||(common_pid!=50652)||(common_pid!=50651)||(common_pid!=50650)||(common_pid!=50649)||(common_pid!=50648)||(common_pid!=50647)||(common_pid!=50646)||(common_pid!=50645)||(common_pid!=50644)||(common_pid!=50643)||(common_pid!=50642)||(common_pid!=50641)||(common_pid!=50640)||(common_pid!=50639)||(common_pid!=50638)||(common_pid!=50637)||(common_pid!=50636)||(common_pid!=50635)||(common_pid!=50634)||(common_pid!=50633)||(common_pid!=50632)||(common_pid!=50631)||(common_pid!=50630)||(common_pid!=50629)||(common_pid!=50628)||(common_pid!=50627)||(common_pid!=50626)||(common_pid!=50625)||(common_pid!=50624)||(common_pid!=50623)||(common_pid!=50622)||(common_pid!=50621)||(common_pid!=50620)||(common_pid!=50619)||(common_pid!=50618)||(common_pid!=50617)||(common_pid!=50616)||(common_pid!=50615)||(common_pid!=50614)||(common_pid!=50613)||(common_pid!=50612)||(common_pid!=50611)||(common_pid!=50610)||(common_pid!=50609)||(common_pid!=50608)||(common_pid!=50607)||(common_pid!=50606)||(common_pid!=50605)||(common_pid!=50604)||(common_pid!=50603)||(common_pid!=50602)||(common_pid!=50601)||(common_pid!=50600)||(common_pid!=50599)||(common_pid!=50598)||(common_pid!=50597)||(common_pid!=50596),
 
strlen = 6046b

on an older version of traceback (but this bug still exists in the 
latest), I did a gdb session like this

Breakpoint 2, write_file (
file=0x670e40 
"/sys/kernel/debug/tracing/events/sched/sched_kthread_stop/filter", 
str=0x67f8c0 
"(common_pid!=21759)||(common_pid!=21758)||(common_pid!=21757)||(common_pid!=21756)||(common_pid!=21755)||(common_pid!=21754)||(common_pid!=21753)||(common_pid!=21752)||(common_pid!=21751)||(common_pid"...,
 
type=0x447dc4 "filter") at /root/trace-cmd/trace-record.c:1586
1586die("Failed %s of %s\n", type, file);
(gdb) print file
$7 = 0x670e40 
"/sys/kernel/debug/tracing/events/sched/sched_kthread_stop/filter"
(gdb) bt
#0  write_file (
file=0x670e40 
"/sys/kernel/debug/tracing/events/sched/sched_kthread_stop/filter", 
str=0x67f8c0 
"(common_pid!=21759)||(common_pid!=21758)||(common_pid!=21757)||(common_pid!=21756)||(common_pid!=21755)||(common_pid!=21754)||(common_pid!=21753)||(common_pid!=21752)||(common_pid!=21751)||(common_pid"...,
 
type=0x447dc4 "filter") at /root/trace-cmd/trace-record.c:1586
#1  0x0040abfd in write_filter (
file=0x670e40 
"/sys/kernel/debug/tracing/events/sched/sched_kthread_stop/filter", 
filter=0x67f8c0 
"(common_pid!=21759)||(common_pid!=21758)||(common_pid!=21757)||(common_pid!=21756)||(common_pid!=21755)||(common_pid!=21754)||(common_pid!=21753)||(common_pid!=21752)||(common_pid!=21751)||(common_pid"...)
at /root/trace-cmd/trace-record.c:1652
#2  0x0040af81 in update_event (event=0x670d30, 
filter=0x67f8c0 
"(common_pid!=21759)||(common_pid!=21758)||(common_pid!=21757)||(common_pid!=21756)||(common_pid!=21755)||(common_pid!=21754)||(common_pid!=21753)||(common_pid!=21752)||(common_pid!=21751)||(common_pid"...,
 
filter_only=1, update=49 '1') at /root/trace-cmd/trace-record.c:1785
#3  0x0040b653 in update_event_filters (
instance=0x65e5e0 ) at 
/root/trace-cmd/trace-record.c:2016
#4  0x0040b83b in update_pid_event_filters (
instance=0x65e5e0 ) at 
/root/trace-cmd/trace-record.c:2081
#5  0x00409607 in update_task_filter ()
at /root/trace-cmd/trace-record.c:971
#6  0x004118be in trace_record (argc=6, argv=0x7fffe0f8)
at /root/trace-cmd/trace-record.c:4818
#7  0x00407cb7 in main (argc=6, argv=0x7fffe0f8)
at /root/trace-cmd/trace-cmd.c:133

Note even if you don't invoke the filter, you still write the sting to the 
file.

Not sure how to fix this, but conceptually it's not hard, we need to add 
some error checking and stop writing to the filter if we exceed the limit.
The functions that do the writes however are shared in many paths.

In addition to that, perhaps we could write something saner to the file
so that it takes longer to hit the limit.

Rewriting "common_pid" over and over again for example, is probably 
unnecessary with some reworking.

John Kacur

[PATCH] rt-tests: Makefile: ssdd: Incoroporate ssdd into the rt-tests Makefile

[John Kacur]

Incoroporate ssdd into the rt-tests build

Signed-off-by: John Kacur 
---
 Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 06f399cc629d..16cd2f9bdd03 100644
--- a/Makefile
+++ b/Makefile
@@ -16,7 +16,8 @@ sources = cyclictest.c \
  svsematest.c  \
  cyclicdeadline.c \
  deadline_test.c \
- queuelat.c 
+ queuelat.c \
+ ssdd.c
 
 TARGETS = $(sources:.c=)
 LIBS   = -lrt -lpthread
@@ -86,6 +87,7 @@ VPATH += src/lib:
 VPATH  += src/hackbench:
 VPATH  += src/sched_deadline:
 VPATH  += src/queuelat:
+VPATH  += src/ssdd:
 
 $(OBJDIR)/%.o: %.c | $(OBJDIR)
$(CC) -D VERSION=$(VERSION) -c $< $(CFLAGS) $(CPPFLAGS) -o $@
@@ -146,6 +148,9 @@ hackbench: $(OBJDIR)/hackbench.o
 queuelat: $(OBJDIR)/queuelat.o $(OBJDIR)/librttest.a
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
 
+ssdd: $(OBJDIR)/ssdd.o $(OBJDIR)/librttest.a
+   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
+
 LIBOBJS =$(addprefix $(OBJDIR)/,error.o rt-get_cpu.o rt-sched.o rt-utils.o)
 $(OBJDIR)/librttest.a: $(LIBOBJS)
$(AR) rcs $@ $^
-- 
2.20.1

[PATCH] Add ssdd test to the rt-tests suite

[John Kacur]

From: Joe Korty 

The following program might make a good addition to the rt
test suite.  It tests the reliability of PTRACE_SINGLESTEP.
It does by default 10,000 ssteps against a simple,
spinner tracee.  Also by default, it spins off ten of these
tracer/tracee pairs, all of which are to run concurrently.

Starting with 4.13-rt, this test occasionally encounters a
sstep whose waitpid returns a WIFSIGNALED (signal SIGTRAP)
rather than a WIFSTOPPED.  This usually happens after
thousands of ssteps have executed.  Having multiple
tracer/tracee pairs running dramatically increases the
chances of failure.

The is what the test output looks like for a good run:

forktest#0/22872: STARTING
forktest#7/22879: STARTING
forktest#8/22880: STARTING
forktest#6/22878: STARTING
forktest#5/22877: STARTING
forktest#3/22875: STARTING
forktest#4/22876: STARTING
forktest#9/22882: STARTING
forktest#2/22874: STARTING
forktest#1/22873: STARTING
forktest#0/22872: EXITING, no error
forktest#8/22880: EXITING, no error
forktest#3/22875: EXITING, no error
forktest#7/22879: EXITING, no error
forktest#6/22878: EXITING, no error
forktest#5/22877: EXITING, no error
forktest#2/22874: EXITING, no error
forktest#4/22876: EXITING, no error
forktest#9/22882: EXITING, no error
forktest#1/22873: EXITING, no error
All tests PASSED.

Signed-off-by: Joe Korty 
Signed-off-by: John Kacur 
---
 src/ssdd/ssdd.c | 315 
 1 file changed, 315 insertions(+)
 create mode 100644 src/ssdd/ssdd.c

diff --git a/src/ssdd/ssdd.c b/src/ssdd/ssdd.c
new file mode 100644
index ..6d09d54e34e1
--- /dev/null
+++ b/src/ssdd/ssdd.c
@@ -0,0 +1,315 @@
+/*
+ * Have a tracer do a bunch of PTRACE_SINGLESTEPs against
+ * a tracee as fast as possible.  Create several of these
+ * tracer/tracee pairs and see if they can be made to
+ * interfere with each other.
+ *
+ * Usage:
+ *   ssdd nforks niters
+ * Where:
+ *   nforks - number of tracer/tracee pairs to fork off.
+ *default 10.
+ *   niters - number of PTRACE_SINGLESTEP iterations to
+ *do before declaring success, for each tracer/
+ *tracee pair set up.  Default 10,000.
+ *
+ * The tracer waits on each PTRACE_SINGLESTEP with a waitpid(2)
+ * and checks that waitpid's return values for correctness.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* do_wait return values */
+#define STATE_EXITED   1
+#define STATE_STOPPED  2
+#define STATE_SIGNALED 3
+#define STATE_UNKNOWN  4
+#define STATE_ECHILD   5
+#define STATE_EXITED_TSIG  6   /* exited with termination signal */
+#define STATE_EXITED_ERRSTAT   7   /* exited with non-zero status */
+
+char *state_name[] = {
+   [STATE_EXITED] = "STATE_EXITED",
+   [STATE_STOPPED] = "STATE_STOPPED",
+   [STATE_SIGNALED] = "STATE_SIGNALED",
+   [STATE_UNKNOWN] = "STATE_UNKNOWN",
+   [STATE_ECHILD] = "STATE_ECHILD",
+   [STATE_EXITED_TSIG] = "STATE_EXITED_TSIG",
+   [STATE_EXITED_ERRSTAT] = "STATE_EXITED_ERRSTAT"
+};
+
+const char *get_state_name(int state)
+{
+   if (state < STATE_EXITED || state > STATE_EXITED_ERRSTAT)
+   return "?";
+   return state_name[state];
+}
+
+#define unused __attribute__((unused))
+
+static int got_sigchld;
+
+static int do_wait(pid_t *wait_pid, int *ret_sig)
+{
+   int status, child_status;
+
+   *ret_sig = -1; /* initially mark 'nothing returned' */
+
+   while (1) {
+   status = waitpid(-1, _status, WUNTRACED | __WALL);
+   if (status == -1) {
+   if (errno == EINTR)
+   continue;
+   if (errno == ECHILD) {
+   *wait_pid = (pid_t)0;
+   return STATE_ECHILD;
+   }
+   printf("do_wait/%d: EXITING, ERROR: "
+  "waitpid() returned errno %d\n",
+  getpid(), errno);
+   exit(1);
+   }
+   break;
+   }
+   *wait_pid = (pid_t)status;
+
+   if (WIFEXITED(child_status)) {
+   if (WIFSIGNALED(child_status))
+   return STATE_EXITED_TSIG;
+   if (WEXITSTATUS(child_status))
+   return STATE_EXITED_ERRSTAT;
+   return STATE_EXITED;
+   }
+   if (WIFSTOPPED(child_status)) {
+   *ret_sig = WSTOPSIG(child_status);
+   return STATE_STOPPED;
+   }
+   if (WIFSIGNALED(child_status)) {
+   *ret_sig = WTERMSIG(child_status);
+   return STATE_SIGNALED;
+   }
+   return STATE_UNKNOWN;
+}
+
+int check_sigchld(void)
+{
+   int i;
+   /*
+* The signal is asynchronous so give it some
+   

Re: [ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

[John Kacur]

Sebastian: I added the test from Joe Korty to rt-tests. Working on integrating 
it into the build, but I wanted to make it available before that so you
could send me your patches.

Repo:   git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
Branch: unstable/devel/latest

Thanks
John Kacur

[ANNOUNCE]rt-tests-1.3 New Devlopment version of rt-tests

[John Kacur]

There is a new development version of rt-tests (cyclictest and friends)

As this is the unstable version, there might be some rough spots, but 
patches are welcome!

Recent development includes
- Clark Williams added python3 support for hwlatdetect
 Note: I will accept patches that make the code run correctly for 
both python3 and python2, but only if it doesn't break python3
- Marcelo Tosatti added a new test called queuelat
 Note: Please cc Marcelo on any questions / patches, etc to do with 
queuelat

Clone
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

Branch
unstable/devel/latest

Tar ball
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/snapshot/rt-tests-1.3.tar.gz

Enjoy!

John Kacur

[ANNOUNCE]rt-tests-1.3 New Devlopment version of rt-tests

[John Kacur]

There is a new development version of rt-tests (cyclictest and friends)

As this is the unstable version, there might be some rough spots, but 
patches are welcome!

Recent development includes
- Clark Williams added python3 support for hwlatdetect
 Note: I will accept patches that make the code run correctly for 
both python3 and python2, but only if it doesn't break python3
- Marcelo Tosatti added a new test called queuelat
 Note: Please cc Marcelo on any questions / patches, etc to do with 
queuelat

Clone
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

Branch
unstable/devel/latest

Tar ball
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/snapshot/rt-tests-1.3.tar.gz

Enjoy!

John Kacur

[PATCH] trace-cmd: Fix segmentation fault in trace-snapshot

[John Kacur]

To reproduce the problem:

  plugin 'wakeup'
trace-cmd: Device or resource busy
  Segmentation fault (core dumped)

When the user triggers a condition such as EBUSY the program should die
gracefully. The problem here is simply caused by an extra conversion
specifier in "die" in the write_file function

Signed-off-by: John Kacur <jka...@redhat.com>
---
 trace-snapshot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/trace-snapshot.c b/trace-snapshot.c
index 9d3608c49563..771b065ccfa4 100644
--- a/trace-snapshot.c
+++ b/trace-snapshot.c
@@ -42,7 +42,8 @@ static void write_file(const char *name, char *val)
 
n = write(fd, val, strlen(val));
if (n < 0)
-   die("failed to write '%d' to %s\n", path);
+   die("failed to write to %s\n", path);
+
tracecmd_put_tracing_file(path);
close(fd);
 }
-- 
2.5.5

[PATCH] trace-cmd: Fix segmentation fault in trace-snapshot

[John Kacur]

To reproduce the problem:

  plugin 'wakeup'
trace-cmd: Device or resource busy
  Segmentation fault (core dumped)

When the user triggers a condition such as EBUSY the program should die
gracefully. The problem here is simply caused by an extra conversion
specifier in "die" in the write_file function

Signed-off-by: John Kacur 
---
 trace-snapshot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/trace-snapshot.c b/trace-snapshot.c
index 9d3608c49563..771b065ccfa4 100644
--- a/trace-snapshot.c
+++ b/trace-snapshot.c
@@ -42,7 +42,8 @@ static void write_file(const char *name, char *val)
 
n = write(fd, val, strlen(val));
if (n < 0)
-   die("failed to write '%d' to %s\n", path);
+   die("failed to write to %s\n", path);
+
tracecmd_put_tracing_file(path);
close(fd);
 }
-- 
2.5.5

[tip:irq/core] irq/Documentation: Correct result of echnoing 5 to smp_affinity

[tip-bot for John Kacur]

Commit-ID:  99e9d958726c04cec3e36902d8583fdd8cb5b1bb
Gitweb: http://git.kernel.org/tip/99e9d958726c04cec3e36902d8583fdd8cb5b1bb
Author: John Kacur <jka...@redhat.com>
AuthorDate: Fri, 17 Jun 2016 15:05:15 +0200
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Sun, 10 Jul 2016 16:55:04 +0200

irq/Documentation: Correct result of echnoing 5 to smp_affinity

This command:

  echo 5 > /proc/irq/10/smp_affinity

means only the first and third (not fourth) CPUs can handle irqs
That is, CPU0 is the first CPU and CPU2 is the third cpu

Signed-off-by: John Kacur <jka...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1466168715-8410-1-git-send-email-jka...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 Documentation/filesystems/proc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index e8d0075..5b61eea 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -725,7 +725,7 @@ IRQ, you can set it by doing:
   > echo 1 > /proc/irq/10/smp_affinity
 
 This means that only the first CPU will handle the IRQ, but you can also echo
-5 which means that only the first and fourth CPU can handle the IRQ.
+5 which means that only the first and third CPU can handle the IRQ.
 
 The contents of each smp_affinity file is the same by default:
 

[tip:irq/core] irq/Documentation: Correct result of echnoing 5 to smp_affinity

[tip-bot for John Kacur]

Commit-ID:  99e9d958726c04cec3e36902d8583fdd8cb5b1bb
Gitweb: http://git.kernel.org/tip/99e9d958726c04cec3e36902d8583fdd8cb5b1bb
Author: John Kacur 
AuthorDate: Fri, 17 Jun 2016 15:05:15 +0200
Committer:  Ingo Molnar 
CommitDate: Sun, 10 Jul 2016 16:55:04 +0200

irq/Documentation: Correct result of echnoing 5 to smp_affinity

This command:

  echo 5 > /proc/irq/10/smp_affinity

means only the first and third (not fourth) CPUs can handle irqs
That is, CPU0 is the first CPU and CPU2 is the third cpu

Signed-off-by: John Kacur 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1466168715-8410-1-git-send-email-jka...@redhat.com
Signed-off-by: Ingo Molnar 
---
 Documentation/filesystems/proc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index e8d0075..5b61eea 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -725,7 +725,7 @@ IRQ, you can set it by doing:
   > echo 1 > /proc/irq/10/smp_affinity
 
 This means that only the first CPU will handle the IRQ, but you can also echo
-5 which means that only the first and fourth CPU can handle the IRQ.
+5 which means that only the first and third CPU can handle the IRQ.
 
 The contents of each smp_affinity file is the same by default:
 

Re: [PATCH 3/3] rt-tests: Add cyclicdeadline and deadline_test to the Make system

[John Kacur]

On Thu, 23 Jun 2016, Steven Rostedt wrote:

> On Thu, 23 Jun 2016 14:11:51 +0200
> John Kacur <jka...@redhat.com> wrote:
> 
> 
> > index 9c50456f7419..f530488545e0 100644
> > --- a/src/sched_deadline/cyclicdeadline.c
> > +++ b/src/sched_deadline/cyclicdeadline.c
> > @@ -1,4 +1,6 @@
> > +#ifndef _GNU_SOURCE
> >  #define _GNU_SOURCE
> > +#endif
> >  #include 
> >  #include 
> >  #include 
> > diff --git a/src/sched_deadline/deadline_test.c 
> > b/src/sched_deadline/deadline_test.c
> > index 8a813c494520..2794730febc4 100644
> > --- a/src/sched_deadline/deadline_test.c
> > +++ b/src/sched_deadline/deadline_test.c
> > @@ -29,7 +29,9 @@
> >   *Look for "simple_test"
> >   *
> >   */
> > +#ifndef _GNU_SOURCE
> >  #define _GNU_SOURCE
> > +#endif
> 
> I'd say nuke these if they are already defined via the Makefile or
> something. I can move the define to the Makefile in my github too.
> 
> -- Steve

Agreed.

>From 02b15d056e6127f773fb71f69c0c5fe393422a87 Mon Sep 17 00:00:00 2001
From: John Kacur <jka...@redhat.com>
Date: Fri, 24 Jun 2016 13:34:54 +0200
Subject: [PATCH] rt-tests-1.1.1: Remove _GNU_SOURCE from source files

Remove _GNU_SOURCE from source files since it is defined in the Makefile

Signed-off-by: John Kacur <jka...@redhat.com>
---
 src/rt-migrate-test/rt-migrate-test.c | 3 ---
 src/sched_deadline/cyclicdeadline.c   | 3 ---
 src/sched_deadline/deadline_test.c| 3 ---
 3 files changed, 9 deletions(-)

diff --git a/src/rt-migrate-test/rt-migrate-test.c 
b/src/rt-migrate-test/rt-migrate-test.c
index d7b68ddac3e5..0a0bb77ab661 100644
--- a/src/rt-migrate-test/rt-migrate-test.c
+++ b/src/rt-migrate-test/rt-migrate-test.c
@@ -20,9 +20,6 @@
  *
  * ~~
  */
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
 #include 
 #ifndef __USE_XOPEN2K
 # define __USE_XOPEN2K
diff --git a/src/sched_deadline/cyclicdeadline.c 
b/src/sched_deadline/cyclicdeadline.c
index f530488545e0..fd78d315563e 100644
--- a/src/sched_deadline/cyclicdeadline.c
+++ b/src/sched_deadline/cyclicdeadline.c
@@ -1,6 +1,3 @@
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
 #include 
 #include 
 #include 
diff --git a/src/sched_deadline/deadline_test.c 
b/src/sched_deadline/deadline_test.c
index 2794730febc4..196dfecbbb78 100644
--- a/src/sched_deadline/deadline_test.c
+++ b/src/sched_deadline/deadline_test.c
@@ -29,9 +29,6 @@
  *Look for "simple_test"
  *
  */
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
 #include 
 #include 
 #include 
-- 
2.4.11

Re: [PATCH 3/3] rt-tests: Add cyclicdeadline and deadline_test to the Make system

[John Kacur]

On Thu, 23 Jun 2016, Steven Rostedt wrote:

> On Thu, 23 Jun 2016 14:11:51 +0200
> John Kacur  wrote:
> 
> 
> > index 9c50456f7419..f530488545e0 100644
> > --- a/src/sched_deadline/cyclicdeadline.c
> > +++ b/src/sched_deadline/cyclicdeadline.c
> > @@ -1,4 +1,6 @@
> > +#ifndef _GNU_SOURCE
> >  #define _GNU_SOURCE
> > +#endif
> >  #include 
> >  #include 
> >  #include 
> > diff --git a/src/sched_deadline/deadline_test.c 
> > b/src/sched_deadline/deadline_test.c
> > index 8a813c494520..2794730febc4 100644
> > --- a/src/sched_deadline/deadline_test.c
> > +++ b/src/sched_deadline/deadline_test.c
> > @@ -29,7 +29,9 @@
> >   *Look for "simple_test"
> >   *
> >   */
> > +#ifndef _GNU_SOURCE
> >  #define _GNU_SOURCE
> > +#endif
> 
> I'd say nuke these if they are already defined via the Makefile or
> something. I can move the define to the Makefile in my github too.
> 
> -- Steve

Agreed.

>From 02b15d056e6127f773fb71f69c0c5fe393422a87 Mon Sep 17 00:00:00 2001
From: John Kacur 
Date: Fri, 24 Jun 2016 13:34:54 +0200
Subject: [PATCH] rt-tests-1.1.1: Remove _GNU_SOURCE from source files

Remove _GNU_SOURCE from source files since it is defined in the Makefile

Signed-off-by: John Kacur 
---
 src/rt-migrate-test/rt-migrate-test.c | 3 ---
 src/sched_deadline/cyclicdeadline.c   | 3 ---
 src/sched_deadline/deadline_test.c| 3 ---
 3 files changed, 9 deletions(-)

diff --git a/src/rt-migrate-test/rt-migrate-test.c 
b/src/rt-migrate-test/rt-migrate-test.c
index d7b68ddac3e5..0a0bb77ab661 100644
--- a/src/rt-migrate-test/rt-migrate-test.c
+++ b/src/rt-migrate-test/rt-migrate-test.c
@@ -20,9 +20,6 @@
  *
  * ~~
  */
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
 #include 
 #ifndef __USE_XOPEN2K
 # define __USE_XOPEN2K
diff --git a/src/sched_deadline/cyclicdeadline.c 
b/src/sched_deadline/cyclicdeadline.c
index f530488545e0..fd78d315563e 100644
--- a/src/sched_deadline/cyclicdeadline.c
+++ b/src/sched_deadline/cyclicdeadline.c
@@ -1,6 +1,3 @@
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
 #include 
 #include 
 #include 
diff --git a/src/sched_deadline/deadline_test.c 
b/src/sched_deadline/deadline_test.c
index 2794730febc4..196dfecbbb78 100644
--- a/src/sched_deadline/deadline_test.c
+++ b/src/sched_deadline/deadline_test.c
@@ -29,9 +29,6 @@
  *Look for "simple_test"
  *
  */
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
 #include 
 #include 
 #include 
-- 
2.4.11

[PATCH 1/3] rt-tests: Makefile, change version to 1.1

[John Kacur]

Rethinking the naming scheme, so changing the development line from 2.0
to 1.1

Signed-off-by: John Kacur <jka...@redhat.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a54d82bd8964..d60282e05931 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-VERSION = 2.0
+VERSION = 1.1
 CC?=$(CROSS_COMPILE)gcc
 AR?=$(CROSS_COMPILE)ar
 
-- 
2.4.11

[PATCH 1/3] rt-tests: Makefile, change version to 1.1

[John Kacur]

Rethinking the naming scheme, so changing the development line from 2.0
to 1.1

Signed-off-by: John Kacur 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a54d82bd8964..d60282e05931 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-VERSION = 2.0
+VERSION = 1.1
 CC?=$(CROSS_COMPILE)gcc
 AR?=$(CROSS_COMPILE)ar
 
-- 
2.4.11

[PATCH 3/3] rt-tests: Add cyclicdeadline and deadline_test to the Make system

[John Kacur]

- Add cyclicdeadline and deadline_test to the Makefile
- Conditionally define _GNU_SOURCE in the new programs
- Add the new programs to the .gitignore file

Signed-off-by: John Kacur <jka...@redhat.com>
---
 .gitignore  |  2 ++
 Makefile| 11 ++-
 src/sched_deadline/cyclicdeadline.c |  2 ++
 src/sched_deadline/deadline_test.c  |  2 ++
 4 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index ceee8bfb6e9a..b8884d547940 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,8 @@ SRPMS
 /pip_stress
 /hackbench
 /pmqtest
+/cyclicdeadline
+/deadline_test
 
 rt-tests.spec
 tags
diff --git a/Makefile b/Makefile
index d60282e05931..8c0294d197e4 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,9 @@ sources = cyclictest.c \
  sendme.c \
  signaltest.c \
  sigwaittest.c \
- svsematest.c
+ svsematest.c  \
+ cyclicdeadline.c \
+ deadline_test.c
 
 TARGETS = $(sources:.c=)
 LIBS   = -lrt -lpthread
@@ -83,6 +85,7 @@ VPATH += src/pmqtest:
 VPATH  += src/backfire:
 VPATH  += src/lib:
 VPATH  += src/hackbench:
+VPATH  += src/sched_deadline:
 
 $(OBJDIR)/%.o: %.c | $(OBJDIR)
$(CC) -D VERSION=$(VERSION) -c $< $(CFLAGS) $(CPPFLAGS) -o $@
@@ -103,6 +106,12 @@ $(OBJDIR):
 cyclictest: $(OBJDIR)/cyclictest.o $(OBJDIR)/librttest.a
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB) $(NUMA_LIBS)
 
+cyclicdeadline: $(OBJDIR)/cyclicdeadline.o $(OBJDIR)/librttest.a
+   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
+
+deadline_test: $(OBJDIR)/deadline_test.o $(OBJDIR)/librttest.a
+   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
+
 signaltest: $(OBJDIR)/signaltest.o $(OBJDIR)/librttest.a
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
 
diff --git a/src/sched_deadline/cyclicdeadline.c 
b/src/sched_deadline/cyclicdeadline.c
index 9c50456f7419..f530488545e0 100644
--- a/src/sched_deadline/cyclicdeadline.c
+++ b/src/sched_deadline/cyclicdeadline.c
@@ -1,4 +1,6 @@
+#ifndef _GNU_SOURCE
 #define _GNU_SOURCE
+#endif
 #include 
 #include 
 #include 
diff --git a/src/sched_deadline/deadline_test.c 
b/src/sched_deadline/deadline_test.c
index 8a813c494520..2794730febc4 100644
--- a/src/sched_deadline/deadline_test.c
+++ b/src/sched_deadline/deadline_test.c
@@ -29,7 +29,9 @@
  *Look for "simple_test"
  *
  */
+#ifndef _GNU_SOURCE
 #define _GNU_SOURCE
+#endif
 #include 
 #include 
 #include 
-- 
2.4.11

[PATCH 0/3] rt-tests: sched_deadline tests

[John Kacur]

First of all, I have renamed the unstable v2.0 branch to v1.1,
to make our numbering scheme more closely match other Linux projects.

Then I have added two programs written by Steven Rostedt for testing
SCHED_DEADLINE

This is our first change that is to the unstable branch only.

Thanks

John Kacur

John Kacur (3):
  rt-tests: Makefile, change version to 1.1
  rt-tests: Add cyclicdeadline and deadline_test
  rt-tests: Add cyclicdeadline and deadline_test to the Make system

 .gitignore  |2 +
 Makefile|   13 +-
 src/sched_deadline/cyclicdeadline.c | 1269 +
 src/sched_deadline/deadline_test.c  | 2099 +++
 4 files changed, 3381 insertions(+), 2 deletions(-)
 create mode 100644 src/sched_deadline/cyclicdeadline.c
 create mode 100644 src/sched_deadline/deadline_test.c

-- 
2.4.11

[PATCH 2/3] rt-tests: Add cyclicdeadline and deadline_test

[John Kacur]

Add cyclicdeadline and deadline_test - these are two programs written by
Steven Rostedet to test the functionality and performance of
SCHED_DEADLINE

Signed-off-by: John Kacur <jka...@redhat.com>
---
 src/sched_deadline/cyclicdeadline.c | 1267 +
 src/sched_deadline/deadline_test.c  | 2097 +++
 2 files changed, 3364 insertions(+)
 create mode 100644 src/sched_deadline/cyclicdeadline.c
 create mode 100644 src/sched_deadline/deadline_test.c

diff --git a/src/sched_deadline/cyclicdeadline.c 
b/src/sched_deadline/cyclicdeadline.c
new file mode 100644
index ..9c50456f7419
--- /dev/null
+++ b/src/sched_deadline/cyclicdeadline.c
@@ -0,0 +1,1267 @@
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#ifdef __i386__
+#ifndef __NR_sched_setattr
+#define __NR_sched_setattr 351
+#endif
+#ifndef __NR_sched_getattr
+#define __NR_sched_getattr 352
+#endif
+#ifndef __NR_getcpu
+#define __NR_getcpu309
+#endif
+#else /* x86_64 */
+#ifndef __NR_sched_setattr
+#define __NR_sched_setattr 314
+#endif
+#ifndef __NR_sched_getattr
+#define __NR_sched_getattr 315
+#endif
+#ifndef __NR_getcpu
+#define __NR_getcpu309
+#endif
+#endif /* i386 or x86_64 */
+#ifndef SCHED_DEADLINE
+#define SCHED_DEADLINE 6
+#endif
+
+#define _STR(x) #x
+#define STR(x) _STR(x)
+#ifndef MAXPATH
+#define MAXPATH 1024
+#endif
+
+#define CPUSET_ALL "my_cpuset_all"
+#define CPUSET_LOCAL   "my_cpuset"
+
+#define gettid() syscall(__NR_gettid)
+#define sched_setattr(pid, attr, flags) syscall(__NR_sched_setattr, pid, attr, 
flags)
+#define sched_getattr(pid, attr, size, flags) syscall(__NR_sched_getattr, pid, 
attr, size, flags)
+#define getcpu(cpup, nodep, unused) syscall(__NR_getcpu, cpup, nodep, unused)
+
+typedef unsigned long long u64;
+typedef unsigned int u32;
+typedef int s32;
+
+/* Struct to transfer parameters to the thread */
+struct thread_param {
+   u64 runtime_us;
+   u64 deadline_us;
+
+   int mode;
+   int timermode;
+   int signal;
+   int clock;
+   unsigned long max_cycles;
+   struct thread_stat *stats;
+   unsigned long interval;
+   int cpu;
+   int node;
+   int tnum;
+};
+
+/* Struct for statistics */
+struct thread_stat {
+   unsigned long cycles;
+   unsigned long cyclesread;
+   long min;
+   long max;
+   long act;
+   double avg;
+   long *values;
+   long *hist_array;
+   long *outliers;
+   pthread_t thread;
+   int threadstarted;
+   int tid;
+   long reduce;
+   long redmax;
+   long cycleofmax;
+   long hist_overflow;
+   long num_outliers;
+};
+
+struct sched_data {
+   u64 runtime_us;
+   u64 deadline_us;
+
+   int bufmsk;
+
+   struct thread_stat stat;
+
+   char buff[BUFSIZ+1];
+};
+
+struct sched_attr {
+   u32 size;
+
+   u32 sched_policy;
+   u64 sched_flags;
+
+   /* SCHED_NORMAL, SCHED_BATCH */
+   s32 sched_nice;
+
+   /* SCHED_FIFO, SCHED_RR */
+   u32 sched_priority;
+
+   /* SCHED_DEADLINE */
+   u64 sched_runtime;
+   u64 sched_deadline;
+   u64 sched_period;
+};
+
+static int shutdown;
+
+static pthread_barrier_t barrier;
+
+static int cpu_count;
+static int all_cpus;
+
+static int nr_threads;
+static int use_nsecs;
+
+static int mark_fd;
+
+static int find_mount(const char *mount, char *debugfs)
+{
+   char type[100];
+   FILE *fp;
+
+   if ((fp = fopen("/proc/mounts","r")) == NULL)
+   return 0;
+
+   while (fscanf(fp, "%*s %"
+ STR(MAXPATH)
+ "s %99s %*s %*d %*d\n",
+ debugfs, type) == 2) {
+   if (strcmp(type, mount) == 0)
+   break;
+   }
+   fclose(fp);
+
+   if (strcmp(type, mount) != 0)
+   return 0;
+   return 1;
+}
+
+static const char *find_debugfs(void)
+{
+   static int debugfs_found;
+   static char debugfs[MAXPATH+1];
+
+   if (debugfs_found)
+   return debugfs;
+
+   if (!find_mount("debugfs", debugfs))
+   return "";
+   
+   debugfs_found = 1;
+
+   return debugfs;
+}
+
+static int my_vsprintf(char *buf, int size, const char *fmt, va_list ap)
+{
+   const char *p;
+   char tmp[100];
+   char *s = buf;
+   char *end = buf + size;
+   char *str;
+   long long lng;
+   int l;
+   int i;
+
+   end[-1] = 0;
+
+   for (p = fmt; *p && s < end; p++) {
+   if (*p == '%') {
+   l = 0;
+ again:
+

[PATCH 3/3] rt-tests: Add cyclicdeadline and deadline_test to the Make system

[John Kacur]

- Add cyclicdeadline and deadline_test to the Makefile
- Conditionally define _GNU_SOURCE in the new programs
- Add the new programs to the .gitignore file

Signed-off-by: John Kacur 
---
 .gitignore  |  2 ++
 Makefile| 11 ++-
 src/sched_deadline/cyclicdeadline.c |  2 ++
 src/sched_deadline/deadline_test.c  |  2 ++
 4 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index ceee8bfb6e9a..b8884d547940 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,8 @@ SRPMS
 /pip_stress
 /hackbench
 /pmqtest
+/cyclicdeadline
+/deadline_test
 
 rt-tests.spec
 tags
diff --git a/Makefile b/Makefile
index d60282e05931..8c0294d197e4 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,9 @@ sources = cyclictest.c \
  sendme.c \
  signaltest.c \
  sigwaittest.c \
- svsematest.c
+ svsematest.c  \
+ cyclicdeadline.c \
+ deadline_test.c
 
 TARGETS = $(sources:.c=)
 LIBS   = -lrt -lpthread
@@ -83,6 +85,7 @@ VPATH += src/pmqtest:
 VPATH  += src/backfire:
 VPATH  += src/lib:
 VPATH  += src/hackbench:
+VPATH  += src/sched_deadline:
 
 $(OBJDIR)/%.o: %.c | $(OBJDIR)
$(CC) -D VERSION=$(VERSION) -c $< $(CFLAGS) $(CPPFLAGS) -o $@
@@ -103,6 +106,12 @@ $(OBJDIR):
 cyclictest: $(OBJDIR)/cyclictest.o $(OBJDIR)/librttest.a
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB) $(NUMA_LIBS)
 
+cyclicdeadline: $(OBJDIR)/cyclicdeadline.o $(OBJDIR)/librttest.a
+   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
+
+deadline_test: $(OBJDIR)/deadline_test.o $(OBJDIR)/librttest.a
+   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
+
 signaltest: $(OBJDIR)/signaltest.o $(OBJDIR)/librttest.a
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
 
diff --git a/src/sched_deadline/cyclicdeadline.c 
b/src/sched_deadline/cyclicdeadline.c
index 9c50456f7419..f530488545e0 100644
--- a/src/sched_deadline/cyclicdeadline.c
+++ b/src/sched_deadline/cyclicdeadline.c
@@ -1,4 +1,6 @@
+#ifndef _GNU_SOURCE
 #define _GNU_SOURCE
+#endif
 #include 
 #include 
 #include 
diff --git a/src/sched_deadline/deadline_test.c 
b/src/sched_deadline/deadline_test.c
index 8a813c494520..2794730febc4 100644
--- a/src/sched_deadline/deadline_test.c
+++ b/src/sched_deadline/deadline_test.c
@@ -29,7 +29,9 @@
  *Look for "simple_test"
  *
  */
+#ifndef _GNU_SOURCE
 #define _GNU_SOURCE
+#endif
 #include 
 #include 
 #include 
-- 
2.4.11

[PATCH 0/3] rt-tests: sched_deadline tests

[John Kacur]

First of all, I have renamed the unstable v2.0 branch to v1.1,
to make our numbering scheme more closely match other Linux projects.

Then I have added two programs written by Steven Rostedt for testing
SCHED_DEADLINE

This is our first change that is to the unstable branch only.

Thanks

John Kacur

John Kacur (3):
  rt-tests: Makefile, change version to 1.1
  rt-tests: Add cyclicdeadline and deadline_test
  rt-tests: Add cyclicdeadline and deadline_test to the Make system

 .gitignore  |2 +
 Makefile|   13 +-
 src/sched_deadline/cyclicdeadline.c | 1269 +
 src/sched_deadline/deadline_test.c  | 2099 +++
 4 files changed, 3381 insertions(+), 2 deletions(-)
 create mode 100644 src/sched_deadline/cyclicdeadline.c
 create mode 100644 src/sched_deadline/deadline_test.c

-- 
2.4.11

[PATCH 2/3] rt-tests: Add cyclicdeadline and deadline_test

[John Kacur]

Add cyclicdeadline and deadline_test - these are two programs written by
Steven Rostedet to test the functionality and performance of
SCHED_DEADLINE

Signed-off-by: John Kacur 
---
 src/sched_deadline/cyclicdeadline.c | 1267 +
 src/sched_deadline/deadline_test.c  | 2097 +++
 2 files changed, 3364 insertions(+)
 create mode 100644 src/sched_deadline/cyclicdeadline.c
 create mode 100644 src/sched_deadline/deadline_test.c

diff --git a/src/sched_deadline/cyclicdeadline.c 
b/src/sched_deadline/cyclicdeadline.c
new file mode 100644
index ..9c50456f7419
--- /dev/null
+++ b/src/sched_deadline/cyclicdeadline.c
@@ -0,0 +1,1267 @@
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#ifdef __i386__
+#ifndef __NR_sched_setattr
+#define __NR_sched_setattr 351
+#endif
+#ifndef __NR_sched_getattr
+#define __NR_sched_getattr 352
+#endif
+#ifndef __NR_getcpu
+#define __NR_getcpu309
+#endif
+#else /* x86_64 */
+#ifndef __NR_sched_setattr
+#define __NR_sched_setattr 314
+#endif
+#ifndef __NR_sched_getattr
+#define __NR_sched_getattr 315
+#endif
+#ifndef __NR_getcpu
+#define __NR_getcpu309
+#endif
+#endif /* i386 or x86_64 */
+#ifndef SCHED_DEADLINE
+#define SCHED_DEADLINE 6
+#endif
+
+#define _STR(x) #x
+#define STR(x) _STR(x)
+#ifndef MAXPATH
+#define MAXPATH 1024
+#endif
+
+#define CPUSET_ALL "my_cpuset_all"
+#define CPUSET_LOCAL   "my_cpuset"
+
+#define gettid() syscall(__NR_gettid)
+#define sched_setattr(pid, attr, flags) syscall(__NR_sched_setattr, pid, attr, 
flags)
+#define sched_getattr(pid, attr, size, flags) syscall(__NR_sched_getattr, pid, 
attr, size, flags)
+#define getcpu(cpup, nodep, unused) syscall(__NR_getcpu, cpup, nodep, unused)
+
+typedef unsigned long long u64;
+typedef unsigned int u32;
+typedef int s32;
+
+/* Struct to transfer parameters to the thread */
+struct thread_param {
+   u64 runtime_us;
+   u64 deadline_us;
+
+   int mode;
+   int timermode;
+   int signal;
+   int clock;
+   unsigned long max_cycles;
+   struct thread_stat *stats;
+   unsigned long interval;
+   int cpu;
+   int node;
+   int tnum;
+};
+
+/* Struct for statistics */
+struct thread_stat {
+   unsigned long cycles;
+   unsigned long cyclesread;
+   long min;
+   long max;
+   long act;
+   double avg;
+   long *values;
+   long *hist_array;
+   long *outliers;
+   pthread_t thread;
+   int threadstarted;
+   int tid;
+   long reduce;
+   long redmax;
+   long cycleofmax;
+   long hist_overflow;
+   long num_outliers;
+};
+
+struct sched_data {
+   u64 runtime_us;
+   u64 deadline_us;
+
+   int bufmsk;
+
+   struct thread_stat stat;
+
+   char buff[BUFSIZ+1];
+};
+
+struct sched_attr {
+   u32 size;
+
+   u32 sched_policy;
+   u64 sched_flags;
+
+   /* SCHED_NORMAL, SCHED_BATCH */
+   s32 sched_nice;
+
+   /* SCHED_FIFO, SCHED_RR */
+   u32 sched_priority;
+
+   /* SCHED_DEADLINE */
+   u64 sched_runtime;
+   u64 sched_deadline;
+   u64 sched_period;
+};
+
+static int shutdown;
+
+static pthread_barrier_t barrier;
+
+static int cpu_count;
+static int all_cpus;
+
+static int nr_threads;
+static int use_nsecs;
+
+static int mark_fd;
+
+static int find_mount(const char *mount, char *debugfs)
+{
+   char type[100];
+   FILE *fp;
+
+   if ((fp = fopen("/proc/mounts","r")) == NULL)
+   return 0;
+
+   while (fscanf(fp, "%*s %"
+ STR(MAXPATH)
+ "s %99s %*s %*d %*d\n",
+ debugfs, type) == 2) {
+   if (strcmp(type, mount) == 0)
+   break;
+   }
+   fclose(fp);
+
+   if (strcmp(type, mount) != 0)
+   return 0;
+   return 1;
+}
+
+static const char *find_debugfs(void)
+{
+   static int debugfs_found;
+   static char debugfs[MAXPATH+1];
+
+   if (debugfs_found)
+   return debugfs;
+
+   if (!find_mount("debugfs", debugfs))
+   return "";
+   
+   debugfs_found = 1;
+
+   return debugfs;
+}
+
+static int my_vsprintf(char *buf, int size, const char *fmt, va_list ap)
+{
+   const char *p;
+   char tmp[100];
+   char *s = buf;
+   char *end = buf + size;
+   char *str;
+   long long lng;
+   int l;
+   int i;
+
+   end[-1] = 0;
+
+   for (p = fmt; *p && s < end; p++) {
+   if (*p == '%') {
+   l = 0;
+ again:
+   p++;
+ 

[PATCH] Documentation: Correct result of echnoing 5 to smp_affinity

[John Kacur]

echo 5 > /proc/irq/10/smp_affinity

means only the first and third (not fourth) cpus can handle irqs
That is, cpu0 is the first cpu and cpu2 is the third cpu

Signed-off-by: John Kacur <jka...@redhat.com>
---
 Documentation/filesystems/proc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index e8d00759bfa5..5b61eeae3f6e 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -725,7 +725,7 @@ IRQ, you can set it by doing:
   > echo 1 > /proc/irq/10/smp_affinity
 
 This means that only the first CPU will handle the IRQ, but you can also echo
-5 which means that only the first and fourth CPU can handle the IRQ.
+5 which means that only the first and third CPU can handle the IRQ.
 
 The contents of each smp_affinity file is the same by default:
 
-- 
2.4.11

[PATCH] Documentation: Correct result of echnoing 5 to smp_affinity

[John Kacur]

echo 5 > /proc/irq/10/smp_affinity

means only the first and third (not fourth) cpus can handle irqs
That is, cpu0 is the first cpu and cpu2 is the third cpu

Signed-off-by: John Kacur 
---
 Documentation/filesystems/proc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index e8d00759bfa5..5b61eeae3f6e 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -725,7 +725,7 @@ IRQ, you can set it by doing:
   > echo 1 > /proc/irq/10/smp_affinity
 
 This means that only the first CPU will handle the IRQ, but you can also echo
-5 which means that only the first and fourth CPU can handle the IRQ.
+5 which means that only the first and third CPU can handle the IRQ.
 
 The contents of each smp_affinity file is the same by default:
 
-- 
2.4.11

[ANNOUNCE] rt-tests version 1.0

[John Kacur]

Okay, I think it's finally time to release version 1.0 of rt-tests.

There aren't too many interesting changes this round, just a bunch of house 
keeping things, like adding missing man-pages, and updating old ones.

Two interesting changes though are:

 - We now compile with HAVE_PARSE_CPUSTRING_ALL=1 by default which assumes that
numa_parse_cpustring_all() is available. This gives us the ability to include 
isolated cpus in the affinity string.

 - When using the new option --tracemark --notrace, so that cyclictest leaves 
the actually tracing to external programs (primariliy trace-cmd is intended), 
we have to immediately turn off tracing when we hit a breaktrace threshold, or 
we won't have the relevant information left in the buffer.

Now that we've released rt-tests-1.0 the API should be considered closed. We 
will still maintain it of course to fix any problems. There are two exceptions 
to changing the API - there is still some discussion about how to handle 
affinity since there are legitimate reasons to run cyclictest on isolated cpus 
not in the affinity mask. There will probably some changes there in the future.

Also, If Carsten Emde requests any changes, he's probably the one person we 
would accept them from. He does very exstensive testing, and if he requires 
changes to make the latest version more compatible with some older versions, 
that would also be okay.

I am starting a new-development line, or unstable version, where we will be 
free to make more exstensive changes. For now you will want to run with the 
stable version for testing, and use the new development line if you want to get 
creative with rt-tests.

The unstable or development line is called v2.0

If you want to make some radical changes there though, it's probably a good 
idea to discuss that with the list before you spend too much time on them. Of 
course you can always maintain something on the side until you overwhelm us 
with the worth of your new ideas!

Happy Hacking,

Cheers!

John Kacur

To fetch the latest version

Clone one of the following if needed.

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

Stable Version
tag: v1.0
branch: stable/v1.0

Development Version
tag v2.0
branch: devel/v2.0

You can also fetch tarballs here

https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-1.0.tar.gz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-1.0.tar.xz

And older versions here

https://www.kernel.org/pub/linux/utils/rt-tests/older/

Changes

Clark Williams (1):
  cyclictest: stop any tracing after hitting a breaktrace threshold

John Kacur (8):
  rt-tests: Makefile: Assume numa_parse_cpustring_all available
  rt-tests: Add man page for rt-migrate-test
  rt-tests: Update the cyclictest man page
  rt-tests: Add missing option to hwlatdetect man page
  rt-tests: Housekeeping fix some spelling errors.
  rt-tests: hwlat.txt: smidetect renamed to hwlatdetect
  rt-tests: Remove doc/release-checklist.txt
  rt-tests: Makefile - bump version to 1.0

 Makefile  |  15 +--
 doc/release-checklist.txt |   9 --
 src/backfire/sendme.8 |   2 +-
 src/cyclictest/cyclictest.8   | 173 ++
 src/cyclictest/cyclictest.c   |  67 -
 src/hwlatdetect/hwlat.txt |  17 ++--
 src/hwlatdetect/hwlatdetect.8 |  12 ++-
 src/pi_tests/pi_stress.8  |   2 +-
 src/pmqtest/pmqtest.8 |   4 +-
 src/ptsematest/ptsematest.8   |   6 +-
 src/rt-migrate-test/rt-migrate-test.8 |  56 +++
 src/signaltest/signaltest.8   |   2 +-
 src/sigwaittest/sigwaittest.8 |   8 +-
 src/svsematest/svsematest.8   |   6 +-
 14 files changed, 234 insertions(+), 145 deletions(-)
 delete mode 100644 doc/release-checklist.txt
 create mode 100644 src/rt-migrate-test/rt-migrate-test.8

-- 
2.4.11

[ANNOUNCE] rt-tests version 1.0

[John Kacur]

Okay, I think it's finally time to release version 1.0 of rt-tests.

There aren't too many interesting changes this round, just a bunch of house 
keeping things, like adding missing man-pages, and updating old ones.

Two interesting changes though are:

 - We now compile with HAVE_PARSE_CPUSTRING_ALL=1 by default which assumes that
numa_parse_cpustring_all() is available. This gives us the ability to include 
isolated cpus in the affinity string.

 - When using the new option --tracemark --notrace, so that cyclictest leaves 
the actually tracing to external programs (primariliy trace-cmd is intended), 
we have to immediately turn off tracing when we hit a breaktrace threshold, or 
we won't have the relevant information left in the buffer.

Now that we've released rt-tests-1.0 the API should be considered closed. We 
will still maintain it of course to fix any problems. There are two exceptions 
to changing the API - there is still some discussion about how to handle 
affinity since there are legitimate reasons to run cyclictest on isolated cpus 
not in the affinity mask. There will probably some changes there in the future.

Also, If Carsten Emde requests any changes, he's probably the one person we 
would accept them from. He does very exstensive testing, and if he requires 
changes to make the latest version more compatible with some older versions, 
that would also be okay.

I am starting a new-development line, or unstable version, where we will be 
free to make more exstensive changes. For now you will want to run with the 
stable version for testing, and use the new development line if you want to get 
creative with rt-tests.

The unstable or development line is called v2.0

If you want to make some radical changes there though, it's probably a good 
idea to discuss that with the list before you spend too much time on them. Of 
course you can always maintain something on the side until you overwhelm us 
with the worth of your new ideas!

Happy Hacking,

Cheers!

John Kacur

To fetch the latest version

Clone one of the following if needed.

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

Stable Version
tag: v1.0
branch: stable/v1.0

Development Version
tag v2.0
branch: devel/v2.0

You can also fetch tarballs here

https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-1.0.tar.gz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-1.0.tar.xz

And older versions here

https://www.kernel.org/pub/linux/utils/rt-tests/older/

Changes

Clark Williams (1):
  cyclictest: stop any tracing after hitting a breaktrace threshold

John Kacur (8):
  rt-tests: Makefile: Assume numa_parse_cpustring_all available
  rt-tests: Add man page for rt-migrate-test
  rt-tests: Update the cyclictest man page
  rt-tests: Add missing option to hwlatdetect man page
  rt-tests: Housekeeping fix some spelling errors.
  rt-tests: hwlat.txt: smidetect renamed to hwlatdetect
  rt-tests: Remove doc/release-checklist.txt
  rt-tests: Makefile - bump version to 1.0

 Makefile  |  15 +--
 doc/release-checklist.txt |   9 --
 src/backfire/sendme.8 |   2 +-
 src/cyclictest/cyclictest.8   | 173 ++
 src/cyclictest/cyclictest.c   |  67 -
 src/hwlatdetect/hwlat.txt |  17 ++--
 src/hwlatdetect/hwlatdetect.8 |  12 ++-
 src/pi_tests/pi_stress.8  |   2 +-
 src/pmqtest/pmqtest.8 |   4 +-
 src/ptsematest/ptsematest.8   |   6 +-
 src/rt-migrate-test/rt-migrate-test.8 |  56 +++
 src/signaltest/signaltest.8   |   2 +-
 src/sigwaittest/sigwaittest.8 |   8 +-
 src/svsematest/svsematest.8   |   6 +-
 14 files changed, 234 insertions(+), 145 deletions(-)
 delete mode 100644 doc/release-checklist.txt
 create mode 100644 src/rt-migrate-test/rt-migrate-test.8

-- 
2.4.11

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

[John Kacur]

On Wed, 4 May 2016, Luiz Capitulino wrote:

> On Tue, 3 May 2016 15:28:39 -0500
> Clark Williams <willi...@redhat.com> wrote:
> 
> > The intent is to be able to do something like this:
> > 
> > trace-cmd start -e all -p function
> > rteval --duration=12h --cyclictest-breaktrace=150
> > trace-cmd extract
> 
> Ah, ok, I get it now. This makes sense.
> 
> I think I'd refactor the code opening tracing_on to its own
> function so that we avoid the duplicate code in setup_tracer(),
> but in any case:
> 
> Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>
> --

Sorry, resending with a sane mailer

I don't see a better solution for now, so
adding Luiz Reviewed by
Signed-off-by: John Kacur <jka...@redhat.com>

and pushed to devel

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

[John Kacur]

On Wed, 4 May 2016, Luiz Capitulino wrote:

> On Tue, 3 May 2016 15:28:39 -0500
> Clark Williams  wrote:
> 
> > The intent is to be able to do something like this:
> > 
> > trace-cmd start -e all -p function
> > rteval --duration=12h --cyclictest-breaktrace=150
> > trace-cmd extract
> 
> Ah, ok, I get it now. This makes sense.
> 
> I think I'd refactor the code opening tracing_on to its own
> function so that we avoid the duplicate code in setup_tracer(),
> but in any case:
> 
> Reviewed-by: Luiz Capitulino 
> --

Sorry, resending with a sane mailer

I don't see a better solution for now, so
adding Luiz Reviewed by
Signed-off-by: John Kacur 

and pushed to devel

Re: [PATCH] cyclictest: avoid using libnuma cpumask parsing functions

[John Kacur]

On Thu, 14 Apr 2016, Luiz Capitulino wrote:

> On Wed, 13 Apr 2016 15:37:00 -0500
> Clark Williams  wrote:
> 
> > John,
> > 
> > I ran into issues with parsing cpu masks when trying to run this command:
> > 
> > sudo ./cyclictest -i100 -qmu -h 2000 -p95 -t1 -a3
> > 
> > I had previously booted a 4-core system with these boot options:
> > 
> > isolcpus=3 nohz_full=3 rcu_nocbs=3
> > 
> > The intent was to run loads on cpus 0-2 while running cyclictest on the 
> > isolated cpu 3. 
> > 
> > Unfortunately, the libnuma function numa_parse_cpumask() (which we use when 
> > it's available) seems to check the current affinity mask and fails the 
> > parse if any of the cpus in the input string are not in the current 
> > affinity mask. I find this "unhelpful" when trying to place a measurement 
> > thread on an isolated cpu. 
> > 
> > This patch removes the wrapper function which uses libnuma cpumask parsing 
> > functions and instead uses the parser function we wrote for when libnuma is 
> > not available. 
> 
> There's an alternative solution that I was working on some time ago,
> which is having a simple configure script. This is usually done
> by simple projects that don't need a full blown autoconf machinery.
> 
> The patch below adds such a script. It detects librt, libpthread and
> libnuma. It solves the problem you mention and it removes hardcoded
> lib details from the Makefile.
> 
> If there's interest for this solution I can finish it and post for
> inclusion.

I find this interesting, maybe for the coming new devel system, I wouldn't 
want to stick it in now right before a stable release though. Also, I 
like this much better than full blown auto-tools, but I don't want to lose 
control over 
the compiling process either. In otherwords, there should be some way to 
override what the script detects.

Thanks

John

> 
> From 4228140e9dbb7fbb1bb495663ae3d896fc447f8f Mon Sep 17 00:00:00 2001
> From: Luiz Capitulino 
> Date: Tue, 23 Feb 2016 15:53:43 -0500
> Subject: [PATCH] add configure script
> 
> Signed-off-by: Luiz Capitulino 
> ---
>  .gitignore |   1 +
>  Makefile   |  22 ++--
>  configure  | 116 
> +
>  3 files changed, 120 insertions(+), 19 deletions(-)
>  create mode 100755 configure
> 
> diff --git a/.gitignore b/.gitignore
> index ceee8bf..5b3e4cc 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -34,3 +34,4 @@ SRPMS
>  rt-tests.spec
>  tags
>  TAGS
> +config.mk
> diff --git a/Makefile b/Makefile
> index 280fd3b..dad0175 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,3 +1,5 @@
> +include config.mk
> +
>  VERSION = 0.97
>  CC?=$(CROSS_COMPILE)gcc
>  AR?=$(CROSS_COMPILE)ar
> @@ -17,7 +19,6 @@ sources = cyclictest.c \
> svsematest.c
>  
>  TARGETS = $(sources:.c=)
> -LIBS = -lrt -lpthread
>  RTTESTLIB = -lrttest -L$(OBJDIR)
>  EXTRA_LIBS ?= -ldl   # for get_cpu
>  DESTDIR  ?=
> @@ -48,26 +49,9 @@ ostype := $(lastword $(subst -, ,$(dumpmachine)))
>  machinetype := $(shell echo $(dumpmachine)| \
>  sed -e 's/-.*//' -e 's/i.86/i386/' -e 's/mips.*/mips/' -e 
> 's/ppc.*/powerpc/')
>  
> -# The default is to assume you have libnuma installed, which is fine to do
> -# even on non-numa machines. If you don't want to install the numa libs, for
> -# example, they might not be available in an embedded environment, then
> -# compile with
> -# make NUMA=0
> -ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
> -NUMA := 1
> -endif
> -
> -# The default is to assume that you only have numa_parse_cpustring
> -# If you are sure you have a version of libnuma with numa_parse_cpustring_all
> -# then compile with
> -# make HAVE_PARSE_CPUSTRING_ALL=1
> -ifeq ($(NUMA),1)
> - CFLAGS += -DNUMA
> - NUMA_LIBS = -lnuma
>  ifdef HAVE_PARSE_CPUSTRING_ALL
>   CFLAGS += -DHAVE_PARSE_CPUSTRING_ALL
>  endif
> -endif
>  
>  include src/arch/android/Makefile
>  
> @@ -100,7 +84,7 @@ $(OBJDIR):
>  -include $(addprefix $(OBJDIR)/,$(sources:.c=.d))
>  
>  cyclictest: $(OBJDIR)/cyclictest.o $(OBJDIR)/librttest.a
> - $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB) $(NUMA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
>  
>  signaltest: $(OBJDIR)/signaltest.o $(OBJDIR)/librttest.a
>   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
> diff --git a/configure b/configure
> new file mode 100755
> index 000..1d17ef9
> --- /dev/null
> +++ b/configure
> @@ -0,0 +1,116 @@
> +#!/bin/sh
> +
> +build_config=config.mk
> +temp_dir=$(mktemp -d)
> +temp_file=$temp_dir/file.c
> +
> +LIBS=
> +NUMA_LIBS=
> +EXTRA_CFLAGS=
> +has_numa=n
> +has_numa_cpustring_all=n
> +
> +build_test()
> +{
> + local libs=$*
> + local ret=
> +
> + cd $temp_dir
> + cc -o prog $temp_file $libs 2> /dev/null
> + ret=$?
> + cd - > /dev/null
> + return $ret
> +}
> +
> +#
> +# -lpthread
> +#
> 

Re: [PATCH] cyclictest: avoid using libnuma cpumask parsing functions

[John Kacur]

On Thu, 14 Apr 2016, Luiz Capitulino wrote:

> On Wed, 13 Apr 2016 15:37:00 -0500
> Clark Williams  wrote:
> 
> > John,
> > 
> > I ran into issues with parsing cpu masks when trying to run this command:
> > 
> > sudo ./cyclictest -i100 -qmu -h 2000 -p95 -t1 -a3
> > 
> > I had previously booted a 4-core system with these boot options:
> > 
> > isolcpus=3 nohz_full=3 rcu_nocbs=3
> > 
> > The intent was to run loads on cpus 0-2 while running cyclictest on the 
> > isolated cpu 3. 
> > 
> > Unfortunately, the libnuma function numa_parse_cpumask() (which we use when 
> > it's available) seems to check the current affinity mask and fails the 
> > parse if any of the cpus in the input string are not in the current 
> > affinity mask. I find this "unhelpful" when trying to place a measurement 
> > thread on an isolated cpu. 
> > 
> > This patch removes the wrapper function which uses libnuma cpumask parsing 
> > functions and instead uses the parser function we wrote for when libnuma is 
> > not available. 
> 
> There's an alternative solution that I was working on some time ago,
> which is having a simple configure script. This is usually done
> by simple projects that don't need a full blown autoconf machinery.
> 
> The patch below adds such a script. It detects librt, libpthread and
> libnuma. It solves the problem you mention and it removes hardcoded
> lib details from the Makefile.
> 
> If there's interest for this solution I can finish it and post for
> inclusion.

I find this interesting, maybe for the coming new devel system, I wouldn't 
want to stick it in now right before a stable release though. Also, I 
like this much better than full blown auto-tools, but I don't want to lose 
control over 
the compiling process either. In otherwords, there should be some way to 
override what the script detects.

Thanks

John

> 
> From 4228140e9dbb7fbb1bb495663ae3d896fc447f8f Mon Sep 17 00:00:00 2001
> From: Luiz Capitulino 
> Date: Tue, 23 Feb 2016 15:53:43 -0500
> Subject: [PATCH] add configure script
> 
> Signed-off-by: Luiz Capitulino 
> ---
>  .gitignore |   1 +
>  Makefile   |  22 ++--
>  configure  | 116 
> +
>  3 files changed, 120 insertions(+), 19 deletions(-)
>  create mode 100755 configure
> 
> diff --git a/.gitignore b/.gitignore
> index ceee8bf..5b3e4cc 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -34,3 +34,4 @@ SRPMS
>  rt-tests.spec
>  tags
>  TAGS
> +config.mk
> diff --git a/Makefile b/Makefile
> index 280fd3b..dad0175 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,3 +1,5 @@
> +include config.mk
> +
>  VERSION = 0.97
>  CC?=$(CROSS_COMPILE)gcc
>  AR?=$(CROSS_COMPILE)ar
> @@ -17,7 +19,6 @@ sources = cyclictest.c \
> svsematest.c
>  
>  TARGETS = $(sources:.c=)
> -LIBS = -lrt -lpthread
>  RTTESTLIB = -lrttest -L$(OBJDIR)
>  EXTRA_LIBS ?= -ldl   # for get_cpu
>  DESTDIR  ?=
> @@ -48,26 +49,9 @@ ostype := $(lastword $(subst -, ,$(dumpmachine)))
>  machinetype := $(shell echo $(dumpmachine)| \
>  sed -e 's/-.*//' -e 's/i.86/i386/' -e 's/mips.*/mips/' -e 
> 's/ppc.*/powerpc/')
>  
> -# The default is to assume you have libnuma installed, which is fine to do
> -# even on non-numa machines. If you don't want to install the numa libs, for
> -# example, they might not be available in an embedded environment, then
> -# compile with
> -# make NUMA=0
> -ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
> -NUMA := 1
> -endif
> -
> -# The default is to assume that you only have numa_parse_cpustring
> -# If you are sure you have a version of libnuma with numa_parse_cpustring_all
> -# then compile with
> -# make HAVE_PARSE_CPUSTRING_ALL=1
> -ifeq ($(NUMA),1)
> - CFLAGS += -DNUMA
> - NUMA_LIBS = -lnuma
>  ifdef HAVE_PARSE_CPUSTRING_ALL
>   CFLAGS += -DHAVE_PARSE_CPUSTRING_ALL
>  endif
> -endif
>  
>  include src/arch/android/Makefile
>  
> @@ -100,7 +84,7 @@ $(OBJDIR):
>  -include $(addprefix $(OBJDIR)/,$(sources:.c=.d))
>  
>  cyclictest: $(OBJDIR)/cyclictest.o $(OBJDIR)/librttest.a
> - $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB) $(NUMA_LIBS)
> + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
>  
>  signaltest: $(OBJDIR)/signaltest.o $(OBJDIR)/librttest.a
>   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
> diff --git a/configure b/configure
> new file mode 100755
> index 000..1d17ef9
> --- /dev/null
> +++ b/configure
> @@ -0,0 +1,116 @@
> +#!/bin/sh
> +
> +build_config=config.mk
> +temp_dir=$(mktemp -d)
> +temp_file=$temp_dir/file.c
> +
> +LIBS=
> +NUMA_LIBS=
> +EXTRA_CFLAGS=
> +has_numa=n
> +has_numa_cpustring_all=n
> +
> +build_test()
> +{
> + local libs=$*
> + local ret=
> +
> + cd $temp_dir
> + cc -o prog $temp_file $libs 2> /dev/null
> + ret=$?
> + cd - > /dev/null
> + return $ret
> +}
> +
> +#
> +# -lpthread
> +#
> +pthread_lib=-lpthread
> +
> +cat > $temp_file << EOF
> +#include 
> +static void 

Re: [PATCH] cyclictest: avoid using libnuma cpumask parsing functions

[John Kacur]

On Wed, 13 Apr 2016, Clark Williams wrote:

> John,
> 
> I ran into issues with parsing cpu masks when trying to run this command:
> 
> sudo ./cyclictest -i100 -qmu -h 2000 -p95 -t1 -a3
> 
> I had previously booted a 4-core system with these boot options:
> 
>   isolcpus=3 nohz_full=3 rcu_nocbs=3
> 
> The intent was to run loads on cpus 0-2 while running cyclictest on the 
> isolated cpu 3. 
> 
> Unfortunately, the libnuma function numa_parse_cpumask() (which we use when 
> it's available) seems to check the current affinity mask and fails the parse 
> if any of the cpus in the input string are not in the current affinity mask. 
> I find this "unhelpful" when trying to place a measurement thread on an 
> isolated cpu. 
> 
> This patch removes the wrapper function which uses libnuma cpumask parsing 
> functions and instead uses the parser function we wrote for when libnuma is 
> not available. 
> 
> Signed-off-by: Clark Williams 

For the record, I tested isolating cpus using two methods.
1. Using tuna after booting.
2. Using the isolcpus kernel parameter

The default way of compiling rt-tests (and cyclictest) uses 
numa_parse_cpustring() which fails if the cpu is not in the current cpuset 
as you described above.

Distributions that have libnuma versions with
numa_parse_cpustring_all() that can parse all possible cpus, can compile 
like this

make HAVE_PARSE_CPUSTRING_ALL=1

When I did this, cyclictest is able to run your test scenario without 
returning an error.

The default compile is the ultra safe method, but it could be that we are 
maintaining backwards compatibility for an old libnuma version that nobody 
really cares about anymore.

I'm a bit reluctant to replace the libnuma version with our own version 
right before we'd like to freeze a stable version, when you can simply 
compile this correctly for your system to get the desired results. Perhaps 
we can do this for the devel version? On the otherhand, if we don't care 
about maintaining backwards compatability with a library that no-one cares 
about anymore, we can just drop the the old version and use 
numa_parse_cpustring_all(). Maybe that's what we can do going forward.

For this version, we could also swap the default to assume that 
numa_parse_cpustring_all() is available, and make people compile with 
NO_PARSE_CPUSTRING_ALL or something like that if they care about backwards 
compatibility.

Thanks

John


> ---
>  src/cyclictest/rt_numa.h | 82 
> ++--
>  1 file changed, 38 insertions(+), 44 deletions(-)
> 
> diff --git a/src/cyclictest/rt_numa.h b/src/cyclictest/rt_numa.h
> index ec2994314e80..d65cd421863b 100644
> --- a/src/cyclictest/rt_numa.h
> +++ b/src/cyclictest/rt_numa.h
> @@ -32,6 +32,12 @@ static int numa = 0;
>  #define LIBNUMA_API_VERSION 1
>  #endif
>  
> +#ifndef BITS_PER_LONG
> +#define BITS_PER_LONG(8*sizeof(long))
> +#endif
> +
> +
> +
>  static void *
>  threadalloc(size_t size, int node)
>  {
> @@ -89,22 +95,6 @@ static inline unsigned int rt_numa_bitmask_isbitset( const 
> struct bitmask *mask,
>   return numa_bitmask_isbitset(mask,i);
>  }
>  
> -static inline struct bitmask* rt_numa_parse_cpustring(const char* s,
> - int max_cpus)
> -{
> -#ifdef HAVE_PARSE_CPUSTRING_ALL  /* Currently not defined 
> anywhere.  No
> -autotools build. */
> - return numa_parse_cpustring_all(s);
> -#else
> - /* We really need numa_parse_cpustring_all(), so we can assign threads
> -  * to cores which are part of an isolcpus set, but early 2.x versions of
> -  * libnuma do not have this function.  A work around should be to run
> -  * your command with e.g. taskset -c 9-15 
> -  */
> - return numa_parse_cpustring((char *)s);
> -#endif
> -}
> -
>  static inline void rt_bitmask_free(struct bitmask *mask)
>  {
>   numa_bitmask_free(mask);
> @@ -157,32 +147,6 @@ static inline unsigned int rt_numa_bitmask_isbitset( 
> const struct bitmask *mask,
>   return (bit != 0);
>  }
>  
> -static inline struct bitmask* rt_numa_parse_cpustring(const char* s,
> - int max_cpus)
> -{
> - int cpu;
> - struct bitmask *mask = NULL;
> - cpu = atoi(s);
> - if (0 <= cpu && cpu < max_cpus) {
> - mask = malloc(sizeof(*mask));
> - if (mask) {
> - /* Round up to integral number of longs to contain
> -  * max_cpus bits */
> - int nlongs = (max_cpus+BITS_PER_LONG-1)/BITS_PER_LONG;
> -
> - mask->maskp = calloc(nlongs, sizeof(long));
> - if (mask->maskp) {
> - mask->maskp[cpu/BITS_PER_LONG] |=
> - (1UL << (cpu % BITS_PER_LONG));
> - mask->size = max_cpus;
> - } else {
> - free(mask);
> - mask = 

Re: [PATCH] cyclictest: avoid using libnuma cpumask parsing functions

[John Kacur]

On Wed, 13 Apr 2016, Clark Williams wrote:

> John,
> 
> I ran into issues with parsing cpu masks when trying to run this command:
> 
> sudo ./cyclictest -i100 -qmu -h 2000 -p95 -t1 -a3
> 
> I had previously booted a 4-core system with these boot options:
> 
>   isolcpus=3 nohz_full=3 rcu_nocbs=3
> 
> The intent was to run loads on cpus 0-2 while running cyclictest on the 
> isolated cpu 3. 
> 
> Unfortunately, the libnuma function numa_parse_cpumask() (which we use when 
> it's available) seems to check the current affinity mask and fails the parse 
> if any of the cpus in the input string are not in the current affinity mask. 
> I find this "unhelpful" when trying to place a measurement thread on an 
> isolated cpu. 
> 
> This patch removes the wrapper function which uses libnuma cpumask parsing 
> functions and instead uses the parser function we wrote for when libnuma is 
> not available. 
> 
> Signed-off-by: Clark Williams 

For the record, I tested isolating cpus using two methods.
1. Using tuna after booting.
2. Using the isolcpus kernel parameter

The default way of compiling rt-tests (and cyclictest) uses 
numa_parse_cpustring() which fails if the cpu is not in the current cpuset 
as you described above.

Distributions that have libnuma versions with
numa_parse_cpustring_all() that can parse all possible cpus, can compile 
like this

make HAVE_PARSE_CPUSTRING_ALL=1

When I did this, cyclictest is able to run your test scenario without 
returning an error.

The default compile is the ultra safe method, but it could be that we are 
maintaining backwards compatibility for an old libnuma version that nobody 
really cares about anymore.

I'm a bit reluctant to replace the libnuma version with our own version 
right before we'd like to freeze a stable version, when you can simply 
compile this correctly for your system to get the desired results. Perhaps 
we can do this for the devel version? On the otherhand, if we don't care 
about maintaining backwards compatability with a library that no-one cares 
about anymore, we can just drop the the old version and use 
numa_parse_cpustring_all(). Maybe that's what we can do going forward.

For this version, we could also swap the default to assume that 
numa_parse_cpustring_all() is available, and make people compile with 
NO_PARSE_CPUSTRING_ALL or something like that if they care about backwards 
compatibility.

Thanks

John


> ---
>  src/cyclictest/rt_numa.h | 82 
> ++--
>  1 file changed, 38 insertions(+), 44 deletions(-)
> 
> diff --git a/src/cyclictest/rt_numa.h b/src/cyclictest/rt_numa.h
> index ec2994314e80..d65cd421863b 100644
> --- a/src/cyclictest/rt_numa.h
> +++ b/src/cyclictest/rt_numa.h
> @@ -32,6 +32,12 @@ static int numa = 0;
>  #define LIBNUMA_API_VERSION 1
>  #endif
>  
> +#ifndef BITS_PER_LONG
> +#define BITS_PER_LONG(8*sizeof(long))
> +#endif
> +
> +
> +
>  static void *
>  threadalloc(size_t size, int node)
>  {
> @@ -89,22 +95,6 @@ static inline unsigned int rt_numa_bitmask_isbitset( const 
> struct bitmask *mask,
>   return numa_bitmask_isbitset(mask,i);
>  }
>  
> -static inline struct bitmask* rt_numa_parse_cpustring(const char* s,
> - int max_cpus)
> -{
> -#ifdef HAVE_PARSE_CPUSTRING_ALL  /* Currently not defined 
> anywhere.  No
> -autotools build. */
> - return numa_parse_cpustring_all(s);
> -#else
> - /* We really need numa_parse_cpustring_all(), so we can assign threads
> -  * to cores which are part of an isolcpus set, but early 2.x versions of
> -  * libnuma do not have this function.  A work around should be to run
> -  * your command with e.g. taskset -c 9-15 
> -  */
> - return numa_parse_cpustring((char *)s);
> -#endif
> -}
> -
>  static inline void rt_bitmask_free(struct bitmask *mask)
>  {
>   numa_bitmask_free(mask);
> @@ -157,32 +147,6 @@ static inline unsigned int rt_numa_bitmask_isbitset( 
> const struct bitmask *mask,
>   return (bit != 0);
>  }
>  
> -static inline struct bitmask* rt_numa_parse_cpustring(const char* s,
> - int max_cpus)
> -{
> - int cpu;
> - struct bitmask *mask = NULL;
> - cpu = atoi(s);
> - if (0 <= cpu && cpu < max_cpus) {
> - mask = malloc(sizeof(*mask));
> - if (mask) {
> - /* Round up to integral number of longs to contain
> -  * max_cpus bits */
> - int nlongs = (max_cpus+BITS_PER_LONG-1)/BITS_PER_LONG;
> -
> - mask->maskp = calloc(nlongs, sizeof(long));
> - if (mask->maskp) {
> - mask->maskp[cpu/BITS_PER_LONG] |=
> - (1UL << (cpu % BITS_PER_LONG));
> - mask->size = max_cpus;
> - } else {
> - free(mask);
> - mask = NULL;
> -

[ANNOUNCE] rt-tests-v0.97

[John Kacur]

Dear RT Folks

We are pleased to announce the latest version of rt-tests

We have a number of interesting enhancements.

Firstly Clark has formally removed the requirement to compile hwlatdetect as a 
module.

Daniel Bristot de Oliveira has added a hardware SMI count detection using 
the MSR/SMI counter if available. Using the --smi option adds the count to 
the end of the output, it looks like this (per thread)

 T: 0 ( 2285) P:80 I:1000 C:   9975 Min:  2 Act:3 Avg:4 Max:   
20831 SMI:   2

Finally Luis Capitulino has added an option to bypass cyclictest's built-in 
tracing so that this functionality can be handed off to another program - in 
particular trace-cmd. cyclictest continues to write to the 
/sys/kernel/debug/tracing/trace_maker file, but trace-cmd handles the tracing.

trace-cmd record [...] cyclictest [...] -bX --tracemark

We are nearing a 1.0 version of rt-tests.
I'd like to have a round of bugfix/clean-up  patches, and patches to add 
anything 
missing and then create a 1.0 version of rt-tests that we will continue to 
maintain,
 but that won't accept any new enhancements. We will also spin-off a 
development version (v2.x?) that will allow api changes.

In the development version we are planning on ripping out the built-in tracing 
support for tighter integration with trace-cmd.
The options in cyclictest have also become quite crufty and complicated and 
need to be radically reworked / simplified. The tests could also share code 
much better than they currently do.

To fetch the latest version

Clone one of the following if needed.

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.97

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.97.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.97.tar.gz

older versions are in
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests/older

I have created a new devel branch which will beome 1.0 (unless we need a v0.99)

devel/v0.98

I'll create the development line for 2.0 once we freeze 1.0

Thanks for all your hardwork

Cheers!

John Kacur

Clark Williams (4):
  Makefile: fixed dropped quote in help target text
  hwlatdetect: handle hwlat_detector being builtin rather than module
  hwlatdetect: modify to handle python3 prints
  hwlatdetect: make reading sample date work with python2 and python3

Daniel Bristot de Oliveira (2):
  cyclictest: SMI count/detection via MSR/SMI counter
  cyclictest: Add --smi description on cyclictest man page

John Kacur (6):
  Remove rt-tests.spec-in
  gitattributes: add doc, remove rt.spec-in
  Makefile: Remove anything to do with rpms, specs etc
  Revert changes to rt-migrate-test for exit(1)
  cyclictest: Make the tracemark option imply notrace
  rt-tests: Makefile: Bump version number to 0.97

Khem Raj (1):
  Makefile: Set CC/AR variable only if it doesn't have a value

Luiz Capitulino (5):
  don't use exit(-1) for failures
  cyclictest: move tracemark_fd handling to its own function
  cyclictest: tracing(): check for notrace
  cyclictest: move debugfs init code to its own function
  cyclictest: add --tracemark option

 .gitattributes |   2 +-
 Makefile   |  62 +
 rt-tests.spec-in   | 524 -
 src/cyclictest/cyclictest.8|   4 +
 src/cyclictest/cyclictest.c| 287 --
 src/hwlatdetect/hwlatdetect.py |  42 +++-
 src/pi_tests/pi_stress.c   |   2 +-
 src/pi_tests/pip_stress.c  |   6 +-
 src/signaltest/signaltest.c|   2 +-
 9 files changed, 316 insertions(+), 615 deletions(-)
 delete mode 100644 rt-tests.spec-in

-- 
2.4.3

[ANNOUNCE] rt-tests-v0.97

[John Kacur]

Dear RT Folks

We are pleased to announce the latest version of rt-tests

We have a number of interesting enhancements.

Firstly Clark has formally removed the requirement to compile hwlatdetect as a 
module.

Daniel Bristot de Oliveira has added a hardware SMI count detection using 
the MSR/SMI counter if available. Using the --smi option adds the count to 
the end of the output, it looks like this (per thread)

 T: 0 ( 2285) P:80 I:1000 C:   9975 Min:  2 Act:3 Avg:4 Max:   
20831 SMI:   2

Finally Luis Capitulino has added an option to bypass cyclictest's built-in 
tracing so that this functionality can be handed off to another program - in 
particular trace-cmd. cyclictest continues to write to the 
/sys/kernel/debug/tracing/trace_maker file, but trace-cmd handles the tracing.

trace-cmd record [...] cyclictest [...] -bX --tracemark

We are nearing a 1.0 version of rt-tests.
I'd like to have a round of bugfix/clean-up  patches, and patches to add 
anything 
missing and then create a 1.0 version of rt-tests that we will continue to 
maintain,
 but that won't accept any new enhancements. We will also spin-off a 
development version (v2.x?) that will allow api changes.

In the development version we are planning on ripping out the built-in tracing 
support for tighter integration with trace-cmd.
The options in cyclictest have also become quite crufty and complicated and 
need to be radically reworked / simplified. The tests could also share code 
much better than they currently do.

To fetch the latest version

Clone one of the following if needed.

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.97

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.97.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.97.tar.gz

older versions are in
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests/older

I have created a new devel branch which will beome 1.0 (unless we need a v0.99)

devel/v0.98

I'll create the development line for 2.0 once we freeze 1.0

Thanks for all your hardwork

Cheers!

John Kacur

Clark Williams (4):
  Makefile: fixed dropped quote in help target text
  hwlatdetect: handle hwlat_detector being builtin rather than module
  hwlatdetect: modify to handle python3 prints
  hwlatdetect: make reading sample date work with python2 and python3

Daniel Bristot de Oliveira (2):
  cyclictest: SMI count/detection via MSR/SMI counter
  cyclictest: Add --smi description on cyclictest man page

John Kacur (6):
  Remove rt-tests.spec-in
  gitattributes: add doc, remove rt.spec-in
  Makefile: Remove anything to do with rpms, specs etc
  Revert changes to rt-migrate-test for exit(1)
  cyclictest: Make the tracemark option imply notrace
  rt-tests: Makefile: Bump version number to 0.97

Khem Raj (1):
  Makefile: Set CC/AR variable only if it doesn't have a value

Luiz Capitulino (5):
  don't use exit(-1) for failures
  cyclictest: move tracemark_fd handling to its own function
  cyclictest: tracing(): check for notrace
  cyclictest: move debugfs init code to its own function
  cyclictest: add --tracemark option

 .gitattributes |   2 +-
 Makefile   |  62 +
 rt-tests.spec-in   | 524 -
 src/cyclictest/cyclictest.8|   4 +
 src/cyclictest/cyclictest.c| 287 --
 src/hwlatdetect/hwlatdetect.py |  42 +++-
 src/pi_tests/pi_stress.c   |   2 +-
 src/pi_tests/pip_stress.c  |   6 +-
 src/signaltest/signaltest.c|   2 +-
 9 files changed, 316 insertions(+), 615 deletions(-)
 delete mode 100644 rt-tests.spec-in

-- 
2.4.3

[PATCH] trace-cmd: trace-cmd.c call free only once on tracing and path

[John Kacur]

>From 33102b6423ba64798d91aee9de4ecb21189dd49e Mon Sep 17 00:00:00 2001
From: John Kacur 
Date: Thu, 3 Dec 2015 23:29:05 +0100
Subject: [PATCH] trace-cmd: don't call free on tracing and path more than once

In version trace-cmd-stable-v2.2 it is possible to call free on
tracing and path more than once.

Ensure this only happens once by moving this block to after the call
to out_free

Signed-off-by: John Kacur 
---
 trace-recorder.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/trace-recorder.c b/trace-recorder.c
index 540765bc9c65..cfdc45e053ab 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -97,15 +97,15 @@ struct tracecmd_recorder *tracecmd_create_recorder_fd(int 
fd, int cpu, unsigned
if (recorder->trace_fd < 0)
goto out_free;
 
-   free(tracing);
-   free(path);
-
if ((recorder->flags & TRACECMD_RECORD_NOSPLICE) == 0) {
ret = pipe(recorder->brass);
if (ret < 0)
goto out_free;
}
 
+   free(tracing);
+   free(path);
+
return recorder;
 
  out_free:
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trace-cmd: trace-cmd.c call free only once on tracing and path

[John Kacur]

>From 33102b6423ba64798d91aee9de4ecb21189dd49e Mon Sep 17 00:00:00 2001
From: John Kacur <jka...@redhat.com>
Date: Thu, 3 Dec 2015 23:29:05 +0100
Subject: [PATCH] trace-cmd: don't call free on tracing and path more than once

In version trace-cmd-stable-v2.2 it is possible to call free on
tracing and path more than once.

Ensure this only happens once by moving this block to after the call
to out_free

Signed-off-by: John Kacur <jka...@redhat.com>
---
 trace-recorder.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/trace-recorder.c b/trace-recorder.c
index 540765bc9c65..cfdc45e053ab 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -97,15 +97,15 @@ struct tracecmd_recorder *tracecmd_create_recorder_fd(int 
fd, int cpu, unsigned
if (recorder->trace_fd < 0)
goto out_free;
 
-   free(tracing);
-   free(path);
-
if ((recorder->flags & TRACECMD_RECORD_NOSPLICE) == 0) {
ret = pipe(recorder->brass);
if (ret < 0)
goto out_free;
}
 
+   free(tracing);
+   free(path);
+
return recorder;
 
  out_free:
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trace-cmd: Documentation, include *.5 files in .gitignore

[John Kacur]

>From 7935646fed739d2bd102f71766a2700a56d6258b Mon Sep 17 00:00:00 2001
From: John Kacur 
Date: Wed, 18 Nov 2015 15:30:15 +0100
Subject: [PATCH] trace-cmd: Documentation, include *.5 files in .gitignore

Most trace-cmd man pages are *.1 but we have trace-cmd.dat.5 now
with the .5 ending. Add this to .gitignore in the Documentation
directory to clean up the output of git status

Signed-off-by: John Kacur 
---
 Documentation/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index f7e585b87a69..8c7bbbe79522 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1 +1,2 @@
 *.1
+*.5
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trace-cmd: Documentation, include *.5 files in .gitignore

[John Kacur]

>From 7935646fed739d2bd102f71766a2700a56d6258b Mon Sep 17 00:00:00 2001
From: John Kacur <jka...@redhat.com>
Date: Wed, 18 Nov 2015 15:30:15 +0100
Subject: [PATCH] trace-cmd: Documentation, include *.5 files in .gitignore

Most trace-cmd man pages are *.1 but we have trace-cmd.dat.5 now
with the .5 ending. Add this to .gitignore in the Documentation
directory to clean up the output of git status

Signed-off-by: John Kacur <jka...@redhat.com>
---
 Documentation/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index f7e585b87a69..8c7bbbe79522 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1 +1,2 @@
 *.1
+*.5
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] trace-cmd: record crashes if -f is used before -e event.

[John Kacur]

On Mon, 20 Jul 2015, Daniel Bristot de Oliveira wrote:

> The trace-cmd record command is crashing if a -f filter is used before
> a -e event.
> 
> The usage a -f before a -e is a command line error, and trace-cmd
> record detects this error by checking if the last_event pointer is NULL.
> 
> However, the last_event is not initialized as NULL and this command line
> error is not detected. Then, the last_event is used to save the filter
> options and this causes a segmentation fault because last_event was not
> initialized yet.
> 
> This problem is fixed by initializing last_event as NULL.
> 
> How-to reproduce:
>   # trace-cmd record -f foo
>   Segmentation fault
> 
> Expected output:
>   # trace-cmd record -f foo
>   filter must come after event
> 
> Signed-off-by: Daniel Bristot de Oliveira 
> ---
>  trace-record.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/trace-record.c b/trace-record.c
> index 3e5def2..45826b6 100644
> --- a/trace-record.c
> +++ b/trace-record.c
> @@ -2686,7 +2686,7 @@ void trace_record (int argc, char **argv)
>   const char *output = NULL;
>   const char *option;
>   struct event_list *event;
> - struct event_list *last_event;
> + struct event_list *last_event = NULL;
>   struct tracecmd_event_list *list;
>   struct buffer_instance *instance = _instance;
>   enum trace_type type;
> -- 
> 2.1.0
> 
Tested-by: John Kacur 

Works well, please apply
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] trace-cmd: record crashes if -f is used before -e event.

[John Kacur]

On Mon, 20 Jul 2015, Daniel Bristot de Oliveira wrote:

> The trace-cmd record command is crashing if a -f filter is used before
> a -e event.
> 
> The usage a -f before a -e is a command line error, and trace-cmd
> record detects this error by checking if the last_event pointer is NULL.
> 
> However, the last_event is not initialized as NULL and this command line
> error is not detected. Then, the last_event is used to save the filter
> options and this causes a segmentation fault because last_event was not
> initialized yet.
> 
> This problem is fixed by initializing last_event as NULL.
> 
> How-to reproduce:
>   # trace-cmd record -f foo
>   Segmentation fault
> 
> Expected output:
>   # trace-cmd record -f foo
>   filter must come after event
> 
> Signed-off-by: Daniel Bristot de Oliveira <bris...@redhat.com>
> ---
>  trace-record.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/trace-record.c b/trace-record.c
> index 3e5def2..45826b6 100644
> --- a/trace-record.c
> +++ b/trace-record.c
> @@ -2686,7 +2686,7 @@ void trace_record (int argc, char **argv)
>   const char *output = NULL;
>   const char *option;
>   struct event_list *event;
> - struct event_list *last_event;
> + struct event_list *last_event = NULL;
>   struct tracecmd_event_list *list;
>   struct buffer_instance *instance = _instance;
>   enum trace_type type;
> -- 
> 2.1.0
> 
Tested-by: John Kacur <jka...@redhat.com>

Works well, please apply
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trace-cmd: Makefile: Determine install in lib or lib64

[John Kacur]

>From 89ca0b6a2c278435d16e1f23ac7cd33515f9 Mon Sep 17 00:00:00 
2001
From: Jon Stanley 
Date: Fri, 13 Nov 2015 15:22:58 +0100
Subject: [PATCH] trace-cmd: Makefile: Determine whether to install to lib or
 lib64

Determine whether an arch is 64 or 32 bit in order to determine
whether to install to lib or lib64

Original patch from Jon Stanley found in Fedora git repo, modified to
omit extraneous parts and simplifiy it a bit.

Signed-off-by: John Kacur 
---
 Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 507af59bef69..8459204346fa 100644
--- a/Makefile
+++ b/Makefile
@@ -31,6 +31,12 @@ $(call allow-override,AR,$(CROSS_COMPILE)ar)
 EXT = -std=gnu99
 INSTALL = install
 
+# figure out what arch we are on and install to right place
+ARCH = $(shell getconf LONG_BIT)
+LIBDIR_32 = lib
+LIBDIR_64 = lib64
+LIBDIR=$(LIBDIR_$(ARCH))
+
 # Use DESTDIR for installing into a different root directory.
 # This is useful for building a package. The program will be
 # installed in this directory as if it was the root directory.
@@ -47,7 +53,7 @@ html_install = $(prefix)/share/kernelshark/html
 html_install_SQ = '$(subst ','\'',$(html_install))'
 img_install = $(prefix)/share/kernelshark/html/images
 img_install_SQ = '$(subst ','\'',$(img_install))'
-libdir ?= lib
+libdir ?= $(LIBDIR)
 
 export man_dir man_dir_SQ html_install html_install_SQ INSTALL
 export img_install img_install_SQ
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trace-cmd: Makefile: Determine install in lib or lib64

[John Kacur]

>From 89ca0b6a2c278435d16e1f23ac7cd33515f9 Mon Sep 17 00:00:00 
2001
From: Jon Stanley <jonstan...@gmail.com>
Date: Fri, 13 Nov 2015 15:22:58 +0100
Subject: [PATCH] trace-cmd: Makefile: Determine whether to install to lib or
 lib64

Determine whether an arch is 64 or 32 bit in order to determine
whether to install to lib or lib64

Original patch from Jon Stanley found in Fedora git repo, modified to
omit extraneous parts and simplifiy it a bit.

Signed-off-by: John Kacur <jka...@redhat.com>
---
 Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 507af59bef69..8459204346fa 100644
--- a/Makefile
+++ b/Makefile
@@ -31,6 +31,12 @@ $(call allow-override,AR,$(CROSS_COMPILE)ar)
 EXT = -std=gnu99
 INSTALL = install
 
+# figure out what arch we are on and install to right place
+ARCH = $(shell getconf LONG_BIT)
+LIBDIR_32 = lib
+LIBDIR_64 = lib64
+LIBDIR=$(LIBDIR_$(ARCH))
+
 # Use DESTDIR for installing into a different root directory.
 # This is useful for building a package. The program will be
 # installed in this directory as if it was the root directory.
@@ -47,7 +53,7 @@ html_install = $(prefix)/share/kernelshark/html
 html_install_SQ = '$(subst ','\'',$(html_install))'
 img_install = $(prefix)/share/kernelshark/html/images
 img_install_SQ = '$(subst ','\'',$(img_install))'
-libdir ?= lib
+libdir ?= $(LIBDIR)
 
 export man_dir man_dir_SQ html_install html_install_SQ INSTALL
 export img_install img_install_SQ
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] rt-tests-v0.96

[John Kacur]

Dear RT Folks

We are pleased to announce the latest version of rt-tests

There is the usual round of clean-ups.
- we are continuing to improve the make system
- Henrik cleaned up the new feature to run cyclictest in Android
specifically he removed all the ugly #ifdefs to an android specific file

There is a new feature to trace information about latency spikes,
to see if we can find any patterns to the spikes

Here is what a sample run with the new feature looks like. (non-rt kernel)

su -c './cyclictest -t4 -p99 --spike=30 --duration=60'
Password:
policy: fifo: loadavg: 0.69 0.78 0.60 1/641 6420

T: 0 ( 6385) P:99 I:1000 C:  59996 Min:  2 Act:2 Avg:2 Max:
1476
T: 1 ( 6386) P:99 I:1500 C:  3 Min:  1 Act:2 Avg:2 Max:
952
T: 2 ( 6387) P:99 I:2000 C:  2 Min:  2 Act:2 Avg:3 Max:
504
T: 3 ( 6388) P:99 I:2500 C:  23999 Min:  1 Act:2 Avg:2 Max:
1423

T: 2 Spike: 504: TS:490531620
T: 2 Spike: 270: TS:526847386
T: 2 Spike:  51: TS:527211167
T: 2 Spike:  44: TS:528261160
T: 1 Spike:  31: TS:528952631
T: 2 Spike:  32: TS:529253148
T: 2 Spike:  52: TS:529317169
T: 0 Spike:1444: TS:530049519
T: 1 Spike: 419: TS:530049520
T: 0 Spike:1476: TS:530318551
T: 1 Spike: 952: TS:530318553
T: 3 Spike:1423: TS:530318551
T: 0 Spike: 972: TS:531532046
T: 0 Spike:  34: TS:531987109
spikes = 14

Summary of Changes
--

Clark Williams (3):
  Makefile: add target to create OBJDIR before use
  specfile: add signaltest manpage to files section and remove trailing
whitespace in changelog
  Makefile: have distclean remove .asc file for tarball

Henrik Austad (4):
  Android: clean up the bypass ifdeffery
  Android: rename arch from bionic to android
  Android: Expand match for android in ostype
  rt-sched.h: do not unconditionally define syscall-numbers

John Kacur (6):
  cyclictest: Clean-ups in timerthread before working on it
  Makefile: OBJDIR should be an order-only-prerequisite
  Makefile: Move TARGETS back to a more logical place in the Makefile
  cyclictest: Add a feature to record spikes
  cyclictest: fix #ifdef broken by NO_PTHREAD_SETAFFINITY
  Makefile: Version bump to v0.96

Uwe Kleine-König (1):
  Fix some trivial typos found by codespell(1)

You can fetch it via git by cloning one of the following repos

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.96

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.96.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.96.tar.gz

older versions are in
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests/older

I've pushed a branch for new development, so you can start sending us your 
patches, and bug reports.

branch: devel/v0.97

Enjoy!

John Kacur

[ANNOUNCE] rt-tests-v0.96

[John Kacur]

Dear RT Folks

We are pleased to announce the latest version of rt-tests

There is the usual round of clean-ups.
- we are continuing to improve the make system
- Henrik cleaned up the new feature to run cyclictest in Android
specifically he removed all the ugly #ifdefs to an android specific file

There is a new feature to trace information about latency spikes,
to see if we can find any patterns to the spikes

Here is what a sample run with the new feature looks like. (non-rt kernel)

su -c './cyclictest -t4 -p99 --spike=30 --duration=60'
Password:
policy: fifo: loadavg: 0.69 0.78 0.60 1/641 6420

T: 0 ( 6385) P:99 I:1000 C:  59996 Min:  2 Act:2 Avg:2 Max:
1476
T: 1 ( 6386) P:99 I:1500 C:  3 Min:  1 Act:2 Avg:2 Max:
952
T: 2 ( 6387) P:99 I:2000 C:  2 Min:  2 Act:2 Avg:3 Max:
504
T: 3 ( 6388) P:99 I:2500 C:  23999 Min:  1 Act:2 Avg:2 Max:
1423

T: 2 Spike: 504: TS:490531620
T: 2 Spike: 270: TS:526847386
T: 2 Spike:  51: TS:527211167
T: 2 Spike:  44: TS:528261160
T: 1 Spike:  31: TS:528952631
T: 2 Spike:  32: TS:529253148
T: 2 Spike:  52: TS:529317169
T: 0 Spike:1444: TS:530049519
T: 1 Spike: 419: TS:530049520
T: 0 Spike:1476: TS:530318551
T: 1 Spike: 952: TS:530318553
T: 3 Spike:1423: TS:530318551
T: 0 Spike: 972: TS:531532046
T: 0 Spike:  34: TS:531987109
spikes = 14

Summary of Changes
--

Clark Williams (3):
  Makefile: add target to create OBJDIR before use
  specfile: add signaltest manpage to files section and remove trailing
whitespace in changelog
  Makefile: have distclean remove .asc file for tarball

Henrik Austad (4):
  Android: clean up the bypass ifdeffery
  Android: rename arch from bionic to android
  Android: Expand match for android in ostype
  rt-sched.h: do not unconditionally define syscall-numbers

John Kacur (6):
  cyclictest: Clean-ups in timerthread before working on it
  Makefile: OBJDIR should be an order-only-prerequisite
  Makefile: Move TARGETS back to a more logical place in the Makefile
  cyclictest: Add a feature to record spikes
  cyclictest: fix #ifdef broken by NO_PTHREAD_SETAFFINITY
  Makefile: Version bump to v0.96

Uwe Kleine-König (1):
  Fix some trivial typos found by codespell(1)

You can fetch it via git by cloning one of the following repos

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.96

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.96.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.96.tar.gz

older versions are in
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests/older

I've pushed a branch for new development, so you can start sending us your 
patches, and bug reports.

branch: devel/v0.97

Enjoy!

John Kacur

[ANNOUNCE] rt-tests-v0.95

[John Kacur]

Dear RT Folks
We're pleased to announce the latest version of rt-tests

The previous version included the first addition of the ability to build 
some of the tests for android which uses the bionic library. (Thank you to 
Henrik Austad for that) Henrik is continuing his development work on 
that.

This version includes a lot of changes to the build system that you will 
hopefully find makes working with rt-tests a lot easier and more pleasant. 
Chiefly the addition of a bld directory for the object files, plus some 
clarification in the comments for different ways to build rt-tests. A 
separate Makefile for bionic, and more.

To clear-up any previous confusion, we do support building without the 
numa libs.

And there are a few odds and ends, clean-ups and a new man page

You can fetch it via git by cloning one of the following repos

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.95

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.95.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.95.tar.gz

older versions are in
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests/older

I've pushed a branch for new development, so you can start sending us your 
patches, and bug reports.

branch: devel/v0.96

Enjoy!

List of Changes

Henrik Austad (1):
  cyclictest: move redefine of CPUSET back to uclib

John Kacur (11):
  Explicitly separate VPATH paths with a colon
  build: Generate .o, .a, and .d files in bld dir
  signaltest: call process_options before calling check_privs
  signaltest: Check the status of pthread_create
  rt-utils: Add John Kacur to the copyright
  rt-utils: Fix some checkpatch errors in rt-utils.c
  signaltest: Add a man page to signaltest
  Makefile: Document certain compiling options
  Makefile: Only call cc -dumpmachine once in the makefile
  Bionic: Move android functionality into it's own arch Makefile
  maintainence: VERSION bump and Change-log update

Uwe Kleine-König (4):
  backfire: remove unused header file
  remove several unused Makefiles
  rt-migrate-test: remove space before \n
  drop compiling without NPTL support

[ANNOUNCE] rt-tests-v0.95

[John Kacur]

Dear RT Folks
We're pleased to announce the latest version of rt-tests

The previous version included the first addition of the ability to build 
some of the tests for android which uses the bionic library. (Thank you to 
Henrik Austad for that) Henrik is continuing his development work on 
that.

This version includes a lot of changes to the build system that you will 
hopefully find makes working with rt-tests a lot easier and more pleasant. 
Chiefly the addition of a bld directory for the object files, plus some 
clarification in the comments for different ways to build rt-tests. A 
separate Makefile for bionic, and more.

To clear-up any previous confusion, we do support building without the 
numa libs.

And there are a few odds and ends, clean-ups and a new man page

You can fetch it via git by cloning one of the following repos

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.95

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.95.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.95.tar.gz

older versions are in
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests/older

I've pushed a branch for new development, so you can start sending us your 
patches, and bug reports.

branch: devel/v0.96

Enjoy!

List of Changes

Henrik Austad (1):
  cyclictest: move redefine of CPUSET back to uclib

John Kacur (11):
  Explicitly separate VPATH paths with a colon
  build: Generate .o, .a, and .d files in bld dir
  signaltest: call process_options before calling check_privs
  signaltest: Check the status of pthread_create
  rt-utils: Add John Kacur to the copyright
  rt-utils: Fix some checkpatch errors in rt-utils.c
  signaltest: Add a man page to signaltest
  Makefile: Document certain compiling options
  Makefile: Only call cc -dumpmachine once in the makefile
  Bionic: Move android functionality into it's own arch Makefile
  maintainence: VERSION bump and Change-log update

Uwe Kleine-König (4):
  backfire: remove unused header file
  remove several unused Makefiles
  rt-migrate-test: remove space before \n
  drop compiling without NPTL support

[ANNOUNCE]rt-tests-0.94

[John Kacur]

We're pleased to announce a new release of rt-tests

You can fetch it via git by cloning one of the following repos

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.94

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.94.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.94.tar.gz

Enjoy!

Clark Williams (2):
  hwlatdetect: initial cut at tracking the amount of SMIs that occurred
during a run
  rt-migrate-test: updated to latest code from rostedt

Darren Hart (2):
  rt-tests: Allow for user-specified PYLIB
  rt-tests: Break out install_hwlatdetect

Henrik Austad (5):
  Add CROSS_COMPILE-switch to CC and AR
  Add syscall-number for sched_(gs)etattr() for tile
  Add a rebuild-switch to Makefile
  Makefile: add librttest to rt-migrate-test
  android: adjust target for android

John Kacur (3):
  Fix VERSION in rt-migrate-test
  numa_on_and_available: Remove from main in cyclictest
  Version bump to v0.94

Josh Cartwright (8):
  rt-tests: workaround poor gzip implementations
  hackbench: cleanup error handling in create_worker
  cyclictest: consistently make all functions 'static'
  cyclictest: use correct type when allocating cpu bitmask size
  cyclictest: drop impossible use_fifo conditional
  cyclictest: fail if use_fifo && thread creation failed
  error: mark fatal, err_exit, err_quit as being noreturn
  cyclictest: add option for dumping the histogram in a file

 Makefile  |  72 +++
 src/cyclictest/cyclictest.c   | 162 
++
 src/cyclictest/rt_numa.h  |  20 +++--
 src/hackbench/hackbench.c |  36 
 src/hwlatdetect/hwlatdetect.py|  25 ++
 src/include/error.h   |   6 +-
 src/include/rt-sched.h|   5 ++
 src/rt-migrate-test/rt-migrate-test.c |  47 +-
 8 files changed, 247 insertions(+), 126 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE]rt-tests-0.94

[John Kacur]

We're pleased to announce a new release of rt-tests

You can fetch it via git by cloning one of the following repos

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.94

You can also fetch the tarball here
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.94.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.94.tar.gz

Enjoy!

Clark Williams (2):
  hwlatdetect: initial cut at tracking the amount of SMIs that occurred
during a run
  rt-migrate-test: updated to latest code from rostedt

Darren Hart (2):
  rt-tests: Allow for user-specified PYLIB
  rt-tests: Break out install_hwlatdetect

Henrik Austad (5):
  Add CROSS_COMPILE-switch to CC and AR
  Add syscall-number for sched_(gs)etattr() for tile
  Add a rebuild-switch to Makefile
  Makefile: add librttest to rt-migrate-test
  android: adjust target for android

John Kacur (3):
  Fix VERSION in rt-migrate-test
  numa_on_and_available: Remove from main in cyclictest
  Version bump to v0.94

Josh Cartwright (8):
  rt-tests: workaround poor gzip implementations
  hackbench: cleanup error handling in create_worker
  cyclictest: consistently make all functions 'static'
  cyclictest: use correct type when allocating cpu bitmask size
  cyclictest: drop impossible use_fifo conditional
  cyclictest: fail if use_fifo && thread creation failed
  error: mark fatal, err_exit, err_quit as being noreturn
  cyclictest: add option for dumping the histogram in a file

 Makefile  |  72 +++
 src/cyclictest/cyclictest.c   | 162 
++
 src/cyclictest/rt_numa.h  |  20 +++--
 src/hackbench/hackbench.c |  36 
 src/hwlatdetect/hwlatdetect.py|  25 ++
 src/include/error.h   |   6 +-
 src/include/rt-sched.h|   5 ++
 src/rt-migrate-test/rt-migrate-test.c |  47 +-
 8 files changed, 247 insertions(+), 126 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] rt-tests-0.93

[John Kacur]

On Mon, 17 Aug 2015, Uwe Kleine-König wrote:

> Hello John,
> 
> On Thu, Aug 13, 2015 at 05:20:26PM +0100, John Kacur wrote:
> > Clark Williams and I are pleased to announce a new rt-tests release.
> > Note we have a new git location, 
> > make sure you update your repo to one of the following
> > 
> > git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
> > https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
> > https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git
> 
> https://www.kernel.org/pub/linux/utils/rt-tests/ doesn't have 0.93 yet.
> (This URL is used to feed
> https://qa.debian.org/cgi-bin/watch?pkg=rt-tests_0.92-1, so adding the
> tarball there should make me aware there is a 0.93 release available :-)

It's there now, you can find the following three files
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.93.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.93.tar.sign
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.93.tar.gz

And I've archived the older ones at
https://www.kernel.org/pub/linux/utils/rt-tests/older/

Cheers!

John Kacur

Re: [ANNOUNCE] rt-tests-0.93

[John Kacur]

On Mon, 17 Aug 2015, Uwe Kleine-König wrote:

 Hello John,
 
 On Thu, Aug 13, 2015 at 05:20:26PM +0100, John Kacur wrote:
  Clark Williams and I are pleased to announce a new rt-tests release.
  Note we have a new git location, 
  make sure you update your repo to one of the following
  
  git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
  https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
  https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git
 
 https://www.kernel.org/pub/linux/utils/rt-tests/ doesn't have 0.93 yet.
 (This URL is used to feed
 https://qa.debian.org/cgi-bin/watch?pkg=rt-tests_0.92-1, so adding the
 tarball there should make me aware there is a 0.93 release available :-)

It's there now, you can find the following three files
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.93.tar.xz
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.93.tar.sign
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-0.93.tar.gz

And I've archived the older ones at
https://www.kernel.org/pub/linux/utils/rt-tests/older/

Cheers!

John Kacur

[ANNOUNCE] rt-tests-0.93

[John Kacur]

Clark Williams and I are pleased to announce a new rt-tests release.
Note we have a new git location, 
make sure you update your repo to one of the following

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.93

Alexander Stein (1):
  cyclictest: Fix long priority help text option

Clark Williams (4):
  makefile: fixed release target
  hwlatdetect: added --watch option to watch output in realtime
  doc: fix VERSION in release-checklist.txt
  Version bump to v0.93

John Kacur (6):
  Fix warning: unused variable ‘c’
  Fix possible exit on error without releasing mutex
  Create a .gitattribute file to specify what files git-archive should
ignore
  Add .tar files to .gitignore
  Change VERSION_STRING to VERSION
  Create an rt-tests.tar file using git-archive

Cheers!

John Kacur

[ANNOUNCE] rt-tests-0.93

[John Kacur]

Clark Williams and I are pleased to announce a new rt-tests release.
Note we have a new git location, 
make sure you update your repo to one of the following

git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
https://kernel.googlesource.com/pub/scm/utils/rt-tests/rt-tests.git

tag: v0.93

Alexander Stein (1):
  cyclictest: Fix long priority help text option

Clark Williams (4):
  makefile: fixed release target
  hwlatdetect: added --watch option to watch output in realtime
  doc: fix VERSION in release-checklist.txt
  Version bump to v0.93

John Kacur (6):
  Fix warning: unused variable ‘c’
  Fix possible exit on error without releasing mutex
  Create a .gitattribute file to specify what files git-archive should
ignore
  Add .tar files to .gitignore
  Change VERSION_STRING to VERSION
  Create an rt-tests.tar file using git-archive

Cheers!

John Kacur

Re: [RFC][PATCH 0/2] preempt: Track unmatched preempt_enable() to preempt_disable()

[John Kacur]

On Thu, Jan 16, 2014 at 6:18 PM, Steven Rostedt  wrote:
>
> Back in the original real-time patch there was a nice debug feature
> that tracked where preemption was disabled and not matched by a preempt
> enable. This information made debugging scheduling while atomic much
> easier, especially when a function was buried in a function chain
> that happened just before the schedule. For example:
>
> bar() {
>   preempt_disable();
>   [...]
>   if (ret < 0)
>  return;
>   [...]
> }
>
> foo() {
>   [...]
>   bar();
>   [...]
> }
>
> foo();
> schedule();
>
> Getting the "scheduling while atomic" warning detects the bug, but it
> does not let you know where the bug happened. It may take several trials
> to figure out where the missing preempt_enable() was. Some times those
> functions are very deep and that makes it even more difficult to find.
>
> Although this bug does not happen often, this feature is extremely helpful
> when it does. I decided to take Ingo's code, which was just written for
> debugging the -rt patch, and clean it up for something that is suitable
> for mainline.
>
> I started with his code and modified it to be a bit simpler, as he never
> meant that code to be mainline. First, as preempt disabling is really more
> of a CPU state and not a process state, I made the stacks just per cpu
> arrays. This eliminates any changes needed by sched.h or the task_struct.
>
> The only times the preempt trace is needed is when scheduling while atomic
> or might sleep bugs are found. This information is only printed in those
> cases (not on all bug reports).
>
> I renamed the config option from PREEMPT_TRACE to PREEMPT_STACK to prevent
> confusion from the tracing facility PREEMPT_TRACER that traces the length
> that preemption is disabled.
>
> Using a struct to save the ip and parent ip together also keeps the code
> a bit cleaner than using two different arrays.
>
> Using a module that creates a kernel thread that calls a function
> bad_preempt_disable() that just calls preempt_disable() with no matching
> preempt_enable(), and then calls schedule, the output can be seen as the
> following:
>
> BUG: scheduling while atomic: task1/3889/0x0002
> Modules linked in: sched_bug(O) [..]
> CPU: 7 PID: 3889 Comm: task1 Tainted: G   O 3.13.0-rc8-test+ #28
> Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 
> 05/07/2012
>  0007 8800c87a1dd8 81627676 88011ebcf5d0
>  8800ca0eaf00 8800c87a1df8 81623825 0002
>  88011ebd3600 8800c87a1e78 8162b0f5 8800c87a1e28
> Call Trace:
>  [] dump_stack+0x4f/0x7c
>  [] __schedule_bug+0x59/0x6e
>  [] __schedule+0x6b5/0x7e0
>  [] ? preempt_count_sub+0xb1/0x100
>  [] ? bad_preempt_disable+0x20/0x20 [sched_bug]
>  [] schedule+0x29/0x70
>  [] dead_thread+0x18/0x78 [sched_bug]
>  [] kthread+0xc9/0xe0
>  [] ? pci_add_new_bus+0x150/0x3b0
>  [] ? flush_kthread_worker+0xb0/0xb0
>  [] ret_from_fork+0x7c/0xb0
>  [] ? flush_kthread_worker+0xb0/0xb0
> ---
> | preempt count: 0002 ]
> | 2-level deep critical section nesting:
> 
> .. []  bad_preempt_disable+0x13/0x20 [sched_bug]
> .[] ..   ( <= dead_thread+0x13/0x78 [sched_bug])
> .. []  __schedule+0x49/0x7e0
> .[] ..   ( <= schedule+0x29/0x70)
>
>
> Steven Rostedt (Red Hat) (2):
>   preempt: Add CONFIG_DEBUG_PREEMPT_COUNT to consolidate ifdef logic
>   preempt: Show preempt disable stack on schedule bugs
>
> 
>  include/linux/preempt.h |  2 +-
>  kernel/sched/core.c | 63 
> ++---
>  kernel/trace/Kconfig|  1 +
>  lib/Kconfig.debug   | 20 
>  4 files changed, 82 insertions(+), 4 deletions(-)
> --

fwiw - I have found this feature useful in the past, and would love to
see it mainstream.

Thanks

John Kacur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 0/2] preempt: Track unmatched preempt_enable() to preempt_disable()

[John Kacur]

On Thu, Jan 16, 2014 at 6:18 PM, Steven Rostedt rost...@goodmis.org wrote:

 Back in the original real-time patch there was a nice debug feature
 that tracked where preemption was disabled and not matched by a preempt
 enable. This information made debugging scheduling while atomic much
 easier, especially when a function was buried in a function chain
 that happened just before the schedule. For example:

 bar() {
   preempt_disable();
   [...]
   if (ret  0)
  return;
   [...]
 }

 foo() {
   [...]
   bar();
   [...]
 }

 foo();
 schedule();

 Getting the scheduling while atomic warning detects the bug, but it
 does not let you know where the bug happened. It may take several trials
 to figure out where the missing preempt_enable() was. Some times those
 functions are very deep and that makes it even more difficult to find.

 Although this bug does not happen often, this feature is extremely helpful
 when it does. I decided to take Ingo's code, which was just written for
 debugging the -rt patch, and clean it up for something that is suitable
 for mainline.

 I started with his code and modified it to be a bit simpler, as he never
 meant that code to be mainline. First, as preempt disabling is really more
 of a CPU state and not a process state, I made the stacks just per cpu
 arrays. This eliminates any changes needed by sched.h or the task_struct.

 The only times the preempt trace is needed is when scheduling while atomic
 or might sleep bugs are found. This information is only printed in those
 cases (not on all bug reports).

 I renamed the config option from PREEMPT_TRACE to PREEMPT_STACK to prevent
 confusion from the tracing facility PREEMPT_TRACER that traces the length
 that preemption is disabled.

 Using a struct to save the ip and parent ip together also keeps the code
 a bit cleaner than using two different arrays.

 Using a module that creates a kernel thread that calls a function
 bad_preempt_disable() that just calls preempt_disable() with no matching
 preempt_enable(), and then calls schedule, the output can be seen as the
 following:

 BUG: scheduling while atomic: task1/3889/0x0002
 Modules linked in: sched_bug(O) [..]
 CPU: 7 PID: 3889 Comm: task1 Tainted: G   O 3.13.0-rc8-test+ #28
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 
 05/07/2012
  0007 8800c87a1dd8 81627676 88011ebcf5d0
  8800ca0eaf00 8800c87a1df8 81623825 0002
  88011ebd3600 8800c87a1e78 8162b0f5 8800c87a1e28
 Call Trace:
  [81627676] dump_stack+0x4f/0x7c
  [81623825] __schedule_bug+0x59/0x6e
  [8162b0f5] __schedule+0x6b5/0x7e0
  [816329f1] ? preempt_count_sub+0xb1/0x100
  [a06d9020] ? bad_preempt_disable+0x20/0x20 [sched_bug]
  [8162b339] schedule+0x29/0x70
  [a06d9038] dead_thread+0x18/0x78 [sched_bug]
  [81073559] kthread+0xc9/0xe0
  [8162] ? pci_add_new_bus+0x150/0x3b0
  [81073490] ? flush_kthread_worker+0xb0/0xb0
  [8163676c] ret_from_fork+0x7c/0xb0
  [81073490] ? flush_kthread_worker+0xb0/0xb0
 ---
 | preempt count: 0002 ]
 | 2-level deep critical section nesting:
 
 .. [a06d9013]  bad_preempt_disable+0x13/0x20 [sched_bug]
 .[a06d9033] ..   ( = dead_thread+0x13/0x78 [sched_bug])
 .. [8162aa89]  __schedule+0x49/0x7e0
 .[8162b339] ..   ( = schedule+0x29/0x70)


 Steven Rostedt (Red Hat) (2):
   preempt: Add CONFIG_DEBUG_PREEMPT_COUNT to consolidate ifdef logic
   preempt: Show preempt disable stack on schedule bugs

 
  include/linux/preempt.h |  2 +-
  kernel/sched/core.c | 63 
 ++---
  kernel/trace/Kconfig|  1 +
  lib/Kconfig.debug   | 20 
  4 files changed, 82 insertions(+), 4 deletions(-)
 --

fwiw - I have found this feature useful in the past, and would love to
see it mainstream.

Thanks

John Kacur
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [SCSI]: Remove Kconfig text referring to non-existent scsi_wait_scan_module

[John Kacur]

The scsi_wait_scan_module was removed in linux-3.6 with
commit 6072609d9bb91ff54aee3ef29304bd5b4fc88aae

Remove the text referring to it under config SCSI_SCAN_ASYNC

Signed-off-by: John Kacur 
---
 drivers/scsi/Kconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index fe25677..49d7768 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -253,13 +253,6 @@ config SCSI_SCAN_ASYNC
  system continues booting, and even probe devices on different
  busses in parallel, leading to a significant speed-up.
 
- If you have built SCSI as modules, enabling this option can
- be a problem as the devices may not have been found by the
- time your system expects them to have been.  You can load the
- scsi_wait_scan module to ensure that all scans have completed.
- If you build your SCSI drivers into the kernel, then everything
- will work fine if you say Y here.
-
  You can override this choice by specifying "scsi_mod.scan=sync"
  or async on the kernel's command line.
 
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [SCSI]: Remove Kconfig text referring to non-existent scsi_wait_scan_module

[John Kacur]

The scsi_wait_scan_module was removed in linux-3.6 with
commit 6072609d9bb91ff54aee3ef29304bd5b4fc88aae

Remove the text referring to it under config SCSI_SCAN_ASYNC

Signed-off-by: John Kacur jka...@redhat.com
---
 drivers/scsi/Kconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index fe25677..49d7768 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -253,13 +253,6 @@ config SCSI_SCAN_ASYNC
  system continues booting, and even probe devices on different
  busses in parallel, leading to a significant speed-up.
 
- If you have built SCSI as modules, enabling this option can
- be a problem as the devices may not have been found by the
- time your system expects them to have been.  You can load the
- scsi_wait_scan module to ensure that all scans have completed.
- If you build your SCSI drivers into the kernel, then everything
- will work fine if you say Y here.
-
  You can override this choice by specifying scsi_mod.scan=sync
  or async on the kernel's command line.
 
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hpsa: fix warning with smp_processor_id() in preemptible

[John Kacur]

- Original Message -
> * John Kacur | 2013-07-26 16:42:30 [+0200]:
> 
> >Signed-off-by: John Kacur 
> >Acked-by: Stephen 
> 
> ping.
> 
> I checked the branches for-next, scsi-fixes, fixes and misc at [0] and I
> didn't see it. I'm going to take this for 3.10-rt but please don't lose
> it on its way to Linus :)
> 
> [0] git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git


I hope it was clear to everyone that this patch was intended for upstream.
It was discovered by running the real-time kernel, but it exposes a (minor) 
problem
that should be fixed in the mainline kernel. Please apply it there Stephen, and
push it upstream appropriately.

Thank You.

John Kacur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hpsa: fix warning with smp_processor_id() in preemptible

[John Kacur]

- Original Message -
 * John Kacur | 2013-07-26 16:42:30 [+0200]:
 
 Signed-off-by: John Kacur jka...@redhat.com
 Acked-by: Stephen scame...@beardog.cce.hp.com
 
 ping.
 
 I checked the branches for-next, scsi-fixes, fixes and misc at [0] and I
 didn't see it. I'm going to take this for 3.10-rt but please don't lose
 it on its way to Linus :)
 
 [0] git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git


I hope it was clear to everyone that this patch was intended for upstream.
It was discovered by running the real-time kernel, but it exposes a (minor) 
problem
that should be fixed in the mainline kernel. Please apply it there Stephen, and
push it upstream appropriately.

Thank You.

John Kacur
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] hpsa: fix warning with smp_processor_id() in preemptible

[John Kacur]

>From 4c01ac362210c38cdbaddd0a75c24c7070e77dfa Mon Sep 17 00:00:00 2001
From: John Kacur 
Date: Fri, 26 Jul 2013 16:06:18 +0200
Subject: [PATCH] hpsa: fix warning with smp_processor_id() in preemptible
 section Signed-off-by: John Kacur 

On a 3.6-rt (real-time patch) kernel we are seeing the following BUG
However, it appears to be relevant for non-realtime (mainline) as well.

[   49.688847] hpsa :03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC
[   49.749928] scsi0 : hpsa
[   49.784437] BUG: using smp_processor_id() in preemptible [
] code: kworker/u:0/6
[   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
[   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
3.6.11.5-rt37.52.el6rt.x86_64.debug #1
[   49.784471] Call Trace:
[   49.784512]  [] debug_smp_processor_id+0x123/0x150
[   49.784520]  [] enqueue_cmd_and_start_io+0x5a/0x100
[hpsa]
[   49.784529]  []
hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
[   49.784537]  [] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784544]  [] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784553]  []
hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
[   49.784562]  []
hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
[   49.784571]  []
hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
[   49.784580]  [] hpsa_update_scsi_devices+0x11f/0x4f0
[hpsa]
[   49.784592]  [] ? sub_preempt_count+0xa9/0xe0
[   49.784601]  [] hpsa_scan_start+0xfd/0x150 [hpsa]
[   49.784613]  [] ? rt_spin_lock_slowunlock+0x78/0x90
[   49.784626]  [] do_scsi_scan_host+0x37/0xa0
[   49.784632]  [] do_scan_async+0x1a/0x30
[   49.784643]  [] async_run_entry_fn+0x9b/0x1d0
[   49.784655]  [] process_one_work+0x1f2/0x620
[   49.784661]  [] ? process_one_work+0x180/0x620
[   49.784668]  [] ? worker_thread+0x5e/0x3a0
[   49.784674]  [] ? async_schedule+0x20/0x20
[   49.784681]  [] worker_thread+0x133/0x3a0
[   49.784688]  [] ? manage_workers+0x190/0x190
[   49.784696]  [] kthread+0xa6/0xb0
[   49.784707]  [] kernel_thread_helper+0x4/0x10
[   49.784715]  [] ? finish_task_switch+0x8c/0x110
[   49.784721]  [] ? _raw_spin_unlock_irq+0x3b/0x70
[   49.784727]  [] ? retint_restore_args+0xe/0xe
[   49.784734]  [] ? kthreadd+0x1e0/0x1e0
[   49.784739]  [] ? gs_change+0xb/0xb

---

This is caused by
enqueue_cmd_and_start_io()->
set_performant_mode()->
smp_processor_id()
Which if you have debugging enabled calls debug_processor_id() and triggers the 
warning.

The code here is
 c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues;

Since it is not critical that the code complete on the same processor,
but the cpu is a hint used in generating the ReplyQueue and will still work if
the cpu migrates or is preempted, it is safe to use the raw_smp_processor_id()
to surpress the false positve warning.

Signed-off-by: John Kacur 
Acked-by: Stephen 
---
 drivers/scsi/hpsa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..4e19267 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h, struct 
CommandList *c)
c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1);
if (likely(h->msix_vector))
c->Header.ReplyQueue =
-   smp_processor_id() % h->nreply_queues;
+   raw_smp_processor_id() % h->nreply_queues;
}
 }
 
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6

[John Kacur]

- Original Message -
> On Fri, Jul 26, 2013 at 06:28:02AM -0400, John Kacur wrote:
> > 
> > 
> > - Original Message -
> > > [Adding missing cc to linux-scsi]
> > > On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote:
> > > > Hi
> > > > 
> > > > We're seeing this on a 3.6 kernel with the real-time patch applied, but
> > > > it
> > > > looks like it is relevant with the real-time patch in the latest kernel
> > 
> > This should read, "it looks like it is relevant WITHOUT the real-time patch
> > in the latest kernel".
> > 
> > 
> > > > too.
> > > > 
> > > > [   49.688847] hpsa :03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC
> > > > [   49.749928] scsi0 : hpsa
> > > > [   49.784437] BUG: using smp_processor_id() in preemptible [
> > > > ] code: kworker/u:0/6
> > > > [   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
> > > > [   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
> > > > 3.6.11.5-rt37.52.el6rt.x86_64.debug #1
> > > > [   49.784471] Call Trace:
> > > > [   49.784512]  [] debug_smp_processor_id+0x123/0x150
> > > > [   49.784520]  []
> > > > enqueue_cmd_and_start_io+0x5a/0x100
> > > > [hpsa]
> > > > [   49.784529]  []
> > > > hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
> > > > [   49.784537]  [] ?
> > > > swiotlb_dma_mapping_error+0x18/0x30
> > > > [   49.784544]  [] ?
> > > > swiotlb_dma_mapping_error+0x18/0x30
> > > > [   49.784553]  []
> > > > hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
> > > > [   49.784562]  []
> > > > hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
> > > > [   49.784571]  []
> > > > hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
> > > > [   49.784580]  []
> > > > hpsa_update_scsi_devices+0x11f/0x4f0
> > > > [hpsa]
> > > > [   49.784592]  [] ? sub_preempt_count+0xa9/0xe0
> > > > [   49.784601]  [] hpsa_scan_start+0xfd/0x150 [hpsa]
> > > > [   49.784613]  [] ?
> > > > rt_spin_lock_slowunlock+0x78/0x90
> > > > [   49.784626]  [] do_scsi_scan_host+0x37/0xa0
> > > > [   49.784632]  [] do_scan_async+0x1a/0x30
> > > > [   49.784643]  [] async_run_entry_fn+0x9b/0x1d0
> > > > [   49.784655]  [] process_one_work+0x1f2/0x620
> > > > [   49.784661]  [] ? process_one_work+0x180/0x620
> > > > [   49.784668]  [] ? worker_thread+0x5e/0x3a0
> > > > [   49.784674]  [] ? async_schedule+0x20/0x20
> > > > [   49.784681]  [] worker_thread+0x133/0x3a0
> > > > [   49.784688]  [] ? manage_workers+0x190/0x190
> > > > [   49.784696]  [] kthread+0xa6/0xb0
> > > > [   49.784707]  [] kernel_thread_helper+0x4/0x10
> > > > [   49.784715]  [] ? finish_task_switch+0x8c/0x110
> > > > [   49.784721]  [] ? _raw_spin_unlock_irq+0x3b/0x70
> > > > [   49.784727]  [] ? retint_restore_args+0xe/0xe
> > > > [   49.784734]  [] ? kthreadd+0x1e0/0x1e0
> > > > [   49.784739]  [] ? gs_change+0xb/0xb
> > > > 
> > > > ---
> > > > 
> > > > When I look at the code I see this call chain
> > > > enqueue_cmd_and_start_io()->
> > > > set_performant_mode()->
> > > > smp_processor_id()
> > > > Which if you have debugging enabled calls debug_processor_id() and
> > > > triggers the warning.
> > > > 
> > > > I'm not very familiar with the hpsa code, so I'm not entirely sure what
> > > > the purpose of this line is
> > > > 
> > > > c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues;
> > > > 
> > > > Is the purpose to simply try to get a range of ReplyQueue numbers, but
> > > > somewhat arbitrary?  Or is it necessary that the current processor_id
> > > > is used? If it is the former, and you're not accessing per cpu
> > > > structures,
> > > > or pinning a cpu, or anything like that then I would think it is safe
> > > > to
> > > > change this to a raw_smp_processor_id() to get rid of a false positive
> > > > warning.
> 
> It's not critical that they match (will work if they don't) but for certain
> workloads you can get more performance if you pin processes to cpus and
> arrange msix interrupt vectors so that comman

Re: hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6

[John Kacur]

- Original Message -
> [Adding missing cc to linux-scsi]
> On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote:
> > Hi
> > 
> > We're seeing this on a 3.6 kernel with the real-time patch applied, but it
> > looks like it is relevant with the real-time patch in the latest kernel

This should read, "it looks like it is relevant WITHOUT the real-time patch in 
the latest kernel".


> > too.
> > 
> > [   49.688847] hpsa :03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC
> > [   49.749928] scsi0 : hpsa
> > [   49.784437] BUG: using smp_processor_id() in preemptible [
> > ] code: kworker/u:0/6
> > [   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
> > [   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
> > 3.6.11.5-rt37.52.el6rt.x86_64.debug #1
> > [   49.784471] Call Trace:
> > [   49.784512]  [] debug_smp_processor_id+0x123/0x150
> > [   49.784520]  [] enqueue_cmd_and_start_io+0x5a/0x100
> > [hpsa]
> > [   49.784529]  []
> > hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
> > [   49.784537]  [] ? swiotlb_dma_mapping_error+0x18/0x30
> > [   49.784544]  [] ? swiotlb_dma_mapping_error+0x18/0x30
> > [   49.784553]  []
> > hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
> > [   49.784562]  []
> > hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
> > [   49.784571]  []
> > hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
> > [   49.784580]  [] hpsa_update_scsi_devices+0x11f/0x4f0
> > [hpsa]
> > [   49.784592]  [] ? sub_preempt_count+0xa9/0xe0
> > [   49.784601]  [] hpsa_scan_start+0xfd/0x150 [hpsa]
> > [   49.784613]  [] ? rt_spin_lock_slowunlock+0x78/0x90
> > [   49.784626]  [] do_scsi_scan_host+0x37/0xa0
> > [   49.784632]  [] do_scan_async+0x1a/0x30
> > [   49.784643]  [] async_run_entry_fn+0x9b/0x1d0
> > [   49.784655]  [] process_one_work+0x1f2/0x620
> > [   49.784661]  [] ? process_one_work+0x180/0x620
> > [   49.784668]  [] ? worker_thread+0x5e/0x3a0
> > [   49.784674]  [] ? async_schedule+0x20/0x20
> > [   49.784681]  [] worker_thread+0x133/0x3a0
> > [   49.784688]  [] ? manage_workers+0x190/0x190
> > [   49.784696]  [] kthread+0xa6/0xb0
> > [   49.784707]  [] kernel_thread_helper+0x4/0x10
> > [   49.784715]  [] ? finish_task_switch+0x8c/0x110
> > [   49.784721]  [] ? _raw_spin_unlock_irq+0x3b/0x70
> > [   49.784727]  [] ? retint_restore_args+0xe/0xe
> > [   49.784734]  [] ? kthreadd+0x1e0/0x1e0
> > [   49.784739]  [] ? gs_change+0xb/0xb
> > 
> > ---
> > 
> > When I look at the code I see this call chain
> > enqueue_cmd_and_start_io()->
> > set_performant_mode()->
> > smp_processor_id()
> > Which if you have debugging enabled calls debug_processor_id() and
> > triggers the warning.
> > 
> > I'm not very familiar with the hpsa code, so I'm not entirely sure what
> > the purpose of this line is
> > 
> > c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues;
> > 
> > Is the purpose to simply try to get a range of ReplyQueue numbers, but
> > somewhat arbitrary? Or is it necessary that the current processor_id
> > is used? If it is the former, and you're not accessing per cpu structures,
> > or pinning a cpu, or anything like that then I would think it is safe to
> > change this to a raw_smp_processor_id() to get rid of a false positive
> > warning.
> > 
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > index 7f4f790..4e19267 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h,
> > struct CommandList *c)
> > c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1);
> > if (likely(h->msix_vector))
> > c->Header.ReplyQueue =
> > -   smp_processor_id() % h->nreply_queues;
> > +   raw_smp_processor_id() % h->nreply_queues;
> > }
> >  }
> >  
> > 
> > Thanks
> > 
> > John Kacur
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6

[John Kacur]

- Original Message -
 [Adding missing cc to linux-scsi]
 On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote:
  Hi
  
  We're seeing this on a 3.6 kernel with the real-time patch applied, but it
  looks like it is relevant with the real-time patch in the latest kernel

This should read, it looks like it is relevant WITHOUT the real-time patch in 
the latest kernel.


  too.
  
  [   49.688847] hpsa :03:00.0: hpsa0: 0x323a at IRQ 67 using DAC
  [   49.749928] scsi0 : hpsa
  [   49.784437] BUG: using smp_processor_id() in preemptible [
  ] code: kworker/u:0/6
  [   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
  [   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
  3.6.11.5-rt37.52.el6rt.x86_64.debug #1
  [   49.784471] Call Trace:
  [   49.784512]  [812abe83] debug_smp_processor_id+0x123/0x150
  [   49.784520]  [a009043a] enqueue_cmd_and_start_io+0x5a/0x100
  [hpsa]
  [   49.784529]  [a00905cb]
  hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
  [   49.784537]  [812b09c8] ? swiotlb_dma_mapping_error+0x18/0x30
  [   49.784544]  [812b09c8] ? swiotlb_dma_mapping_error+0x18/0x30
  [   49.784553]  [a0090701]
  hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
  [   49.784562]  [a0093558]
  hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
  [   49.784571]  [a00935ea]
  hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
  [   49.784580]  [a00963df] hpsa_update_scsi_devices+0x11f/0x4f0
  [hpsa]
  [   49.784592]  [81592019] ? sub_preempt_count+0xa9/0xe0
  [   49.784601]  [a00968ad] hpsa_scan_start+0xfd/0x150 [hpsa]
  [   49.784613]  [8158cba8] ? rt_spin_lock_slowunlock+0x78/0x90
  [   49.784626]  [813b04d7] do_scsi_scan_host+0x37/0xa0
  [   49.784632]  [813b05da] do_scan_async+0x1a/0x30
  [   49.784643]  [8107c4ab] async_run_entry_fn+0x9b/0x1d0
  [   49.784655]  [8106ae92] process_one_work+0x1f2/0x620
  [   49.784661]  [8106ae20] ? process_one_work+0x180/0x620
  [   49.784668]  [8106d4fe] ? worker_thread+0x5e/0x3a0
  [   49.784674]  [8107c410] ? async_schedule+0x20/0x20
  [   49.784681]  [8106d5d3] worker_thread+0x133/0x3a0
  [   49.784688]  [8106d4a0] ? manage_workers+0x190/0x190
  [   49.784696]  [81073236] kthread+0xa6/0xb0
  [   49.784707]  [815970a4] kernel_thread_helper+0x4/0x10
  [   49.784715]  [81082a7c] ? finish_task_switch+0x8c/0x110
  [   49.784721]  [8158e44b] ? _raw_spin_unlock_irq+0x3b/0x70
  [   49.784727]  [8158e85d] ? retint_restore_args+0xe/0xe
  [   49.784734]  [81073190] ? kthreadd+0x1e0/0x1e0
  [   49.784739]  [815970a0] ? gs_change+0xb/0xb
  
  ---
  
  When I look at the code I see this call chain
  enqueue_cmd_and_start_io()-
  set_performant_mode()-
  smp_processor_id()
  Which if you have debugging enabled calls debug_processor_id() and
  triggers the warning.
  
  I'm not very familiar with the hpsa code, so I'm not entirely sure what
  the purpose of this line is
  
  c-Header.ReplyQueue = smp_processor_id() % h-nreply_queues;
  
  Is the purpose to simply try to get a range of ReplyQueue numbers, but
  somewhat arbitrary? Or is it necessary that the current processor_id
  is used? If it is the former, and you're not accessing per cpu structures,
  or pinning a cpu, or anything like that then I would think it is safe to
  change this to a raw_smp_processor_id() to get rid of a false positive
  warning.
  
  diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
  index 7f4f790..4e19267 100644
  --- a/drivers/scsi/hpsa.c
  +++ b/drivers/scsi/hpsa.c
  @@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h,
  struct CommandList *c)
  c-busaddr |= 1 | (h-blockFetchTable[c-Header.SGList]  1);
  if (likely(h-msix_vector))
  c-Header.ReplyQueue =
  -   smp_processor_id() % h-nreply_queues;
  +   raw_smp_processor_id() % h-nreply_queues;
  }
   }
   
  
  Thanks
  
  John Kacur
 
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6

[John Kacur]

- Original Message -
 On Fri, Jul 26, 2013 at 06:28:02AM -0400, John Kacur wrote:
  
  
  - Original Message -
   [Adding missing cc to linux-scsi]
   On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote:
Hi

We're seeing this on a 3.6 kernel with the real-time patch applied, but
it
looks like it is relevant with the real-time patch in the latest kernel
  
  This should read, it looks like it is relevant WITHOUT the real-time patch
  in the latest kernel.
  
  
too.

[   49.688847] hpsa :03:00.0: hpsa0: 0x323a at IRQ 67 using DAC
[   49.749928] scsi0 : hpsa
[   49.784437] BUG: using smp_processor_id() in preemptible [
] code: kworker/u:0/6
[   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
[   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
3.6.11.5-rt37.52.el6rt.x86_64.debug #1
[   49.784471] Call Trace:
[   49.784512]  [812abe83] debug_smp_processor_id+0x123/0x150
[   49.784520]  [a009043a]
enqueue_cmd_and_start_io+0x5a/0x100
[hpsa]
[   49.784529]  [a00905cb]
hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
[   49.784537]  [812b09c8] ?
swiotlb_dma_mapping_error+0x18/0x30
[   49.784544]  [812b09c8] ?
swiotlb_dma_mapping_error+0x18/0x30
[   49.784553]  [a0090701]
hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
[   49.784562]  [a0093558]
hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
[   49.784571]  [a00935ea]
hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
[   49.784580]  [a00963df]
hpsa_update_scsi_devices+0x11f/0x4f0
[hpsa]
[   49.784592]  [81592019] ? sub_preempt_count+0xa9/0xe0
[   49.784601]  [a00968ad] hpsa_scan_start+0xfd/0x150 [hpsa]
[   49.784613]  [8158cba8] ?
rt_spin_lock_slowunlock+0x78/0x90
[   49.784626]  [813b04d7] do_scsi_scan_host+0x37/0xa0
[   49.784632]  [813b05da] do_scan_async+0x1a/0x30
[   49.784643]  [8107c4ab] async_run_entry_fn+0x9b/0x1d0
[   49.784655]  [8106ae92] process_one_work+0x1f2/0x620
[   49.784661]  [8106ae20] ? process_one_work+0x180/0x620
[   49.784668]  [8106d4fe] ? worker_thread+0x5e/0x3a0
[   49.784674]  [8107c410] ? async_schedule+0x20/0x20
[   49.784681]  [8106d5d3] worker_thread+0x133/0x3a0
[   49.784688]  [8106d4a0] ? manage_workers+0x190/0x190
[   49.784696]  [81073236] kthread+0xa6/0xb0
[   49.784707]  [815970a4] kernel_thread_helper+0x4/0x10
[   49.784715]  [81082a7c] ? finish_task_switch+0x8c/0x110
[   49.784721]  [8158e44b] ? _raw_spin_unlock_irq+0x3b/0x70
[   49.784727]  [8158e85d] ? retint_restore_args+0xe/0xe
[   49.784734]  [81073190] ? kthreadd+0x1e0/0x1e0
[   49.784739]  [815970a0] ? gs_change+0xb/0xb

---

When I look at the code I see this call chain
enqueue_cmd_and_start_io()-
set_performant_mode()-
smp_processor_id()
Which if you have debugging enabled calls debug_processor_id() and
triggers the warning.

I'm not very familiar with the hpsa code, so I'm not entirely sure what
the purpose of this line is

c-Header.ReplyQueue = smp_processor_id() % h-nreply_queues;

Is the purpose to simply try to get a range of ReplyQueue numbers, but
somewhat arbitrary?  Or is it necessary that the current processor_id
is used? If it is the former, and you're not accessing per cpu
structures,
or pinning a cpu, or anything like that then I would think it is safe
to
change this to a raw_smp_processor_id() to get rid of a false positive
warning.
 
 It's not critical that they match (will work if they don't) but for certain
 workloads you can get more performance if you pin processes to cpus and
 arrange msix interrupt vectors so that commands are likely to complete on
 the same cpu they originated from.
 
 In any case, I think your analysis is correct.  Thanks.
 

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..4e19267 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info
*h,
struct CommandList *c)
c-busaddr |= 1 | (h-blockFetchTable[c-Header.SGList] 
 1);
if (likely(h-msix_vector))
c-Header.ReplyQueue =
-   smp_processor_id() % h-nreply_queues;
+   raw_smp_processor_id() % 
h-nreply_queues;
}
 }
 
 Ack.
 
 -- steve
 

Ok, thanks, I'll put the patch in another mail with my sign-off.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message

[PATCH] hpsa: fix warning with smp_processor_id() in preemptible

[John Kacur]

From 4c01ac362210c38cdbaddd0a75c24c7070e77dfa Mon Sep 17 00:00:00 2001
From: John Kacur jka...@redhat.com
Date: Fri, 26 Jul 2013 16:06:18 +0200
Subject: [PATCH] hpsa: fix warning with smp_processor_id() in preemptible
 section Signed-off-by: John Kacur jka...@redhat.com

On a 3.6-rt (real-time patch) kernel we are seeing the following BUG
However, it appears to be relevant for non-realtime (mainline) as well.

[   49.688847] hpsa :03:00.0: hpsa0: 0x323a at IRQ 67 using DAC
[   49.749928] scsi0 : hpsa
[   49.784437] BUG: using smp_processor_id() in preemptible [
] code: kworker/u:0/6
[   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
[   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
3.6.11.5-rt37.52.el6rt.x86_64.debug #1
[   49.784471] Call Trace:
[   49.784512]  [812abe83] debug_smp_processor_id+0x123/0x150
[   49.784520]  [a009043a] enqueue_cmd_and_start_io+0x5a/0x100
[hpsa]
[   49.784529]  [a00905cb]
hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
[   49.784537]  [812b09c8] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784544]  [812b09c8] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784553]  [a0090701]
hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
[   49.784562]  [a0093558]
hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
[   49.784571]  [a00935ea]
hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
[   49.784580]  [a00963df] hpsa_update_scsi_devices+0x11f/0x4f0
[hpsa]
[   49.784592]  [81592019] ? sub_preempt_count+0xa9/0xe0
[   49.784601]  [a00968ad] hpsa_scan_start+0xfd/0x150 [hpsa]
[   49.784613]  [8158cba8] ? rt_spin_lock_slowunlock+0x78/0x90
[   49.784626]  [813b04d7] do_scsi_scan_host+0x37/0xa0
[   49.784632]  [813b05da] do_scan_async+0x1a/0x30
[   49.784643]  [8107c4ab] async_run_entry_fn+0x9b/0x1d0
[   49.784655]  [8106ae92] process_one_work+0x1f2/0x620
[   49.784661]  [8106ae20] ? process_one_work+0x180/0x620
[   49.784668]  [8106d4fe] ? worker_thread+0x5e/0x3a0
[   49.784674]  [8107c410] ? async_schedule+0x20/0x20
[   49.784681]  [8106d5d3] worker_thread+0x133/0x3a0
[   49.784688]  [8106d4a0] ? manage_workers+0x190/0x190
[   49.784696]  [81073236] kthread+0xa6/0xb0
[   49.784707]  [815970a4] kernel_thread_helper+0x4/0x10
[   49.784715]  [81082a7c] ? finish_task_switch+0x8c/0x110
[   49.784721]  [8158e44b] ? _raw_spin_unlock_irq+0x3b/0x70
[   49.784727]  [8158e85d] ? retint_restore_args+0xe/0xe
[   49.784734]  [81073190] ? kthreadd+0x1e0/0x1e0
[   49.784739]  [815970a0] ? gs_change+0xb/0xb

---

This is caused by
enqueue_cmd_and_start_io()-
set_performant_mode()-
smp_processor_id()
Which if you have debugging enabled calls debug_processor_id() and triggers the 
warning.

The code here is
 c-Header.ReplyQueue = smp_processor_id() % h-nreply_queues;

Since it is not critical that the code complete on the same processor,
but the cpu is a hint used in generating the ReplyQueue and will still work if
the cpu migrates or is preempted, it is safe to use the raw_smp_processor_id()
to surpress the false positve warning.

Signed-off-by: John Kacur jka...@redhat.com
Acked-by: Stephen scame...@beardog.cce.hp.com
---
 drivers/scsi/hpsa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..4e19267 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h, struct 
CommandList *c)
c-busaddr |= 1 | (h-blockFetchTable[c-Header.SGList]  1);
if (likely(h-msix_vector))
c-Header.ReplyQueue =
-   smp_processor_id() % h-nreply_queues;
+   raw_smp_processor_id() % h-nreply_queues;
}
 }
 
-- 
1.7.11.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6

[John Kacur]

Hi

We're seeing this on a 3.6 kernel with the real-time patch applied, but it 
looks like it is relevant with the real-time patch in the latest kernel 
too.

[   49.688847] hpsa :03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC
[   49.749928] scsi0 : hpsa
[   49.784437] BUG: using smp_processor_id() in preemptible [ 
] code: kworker/u:0/6
[   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
[   49.784468] Pid: 6, comm: kworker/u:0 Not tainted 
3.6.11.5-rt37.52.el6rt.x86_64.debug #1
[   49.784471] Call Trace:
[   49.784512]  [] debug_smp_processor_id+0x123/0x150
[   49.784520]  [] enqueue_cmd_and_start_io+0x5a/0x100 
[hpsa]
[   49.784529]  [] 
hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
[   49.784537]  [] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784544]  [] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784553]  [] 
hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
[   49.784562]  [] 
hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
[   49.784571]  [] 
hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
[   49.784580]  [] hpsa_update_scsi_devices+0x11f/0x4f0 
[hpsa]
[   49.784592]  [] ? sub_preempt_count+0xa9/0xe0
[   49.784601]  [] hpsa_scan_start+0xfd/0x150 [hpsa]
[   49.784613]  [] ? rt_spin_lock_slowunlock+0x78/0x90
[   49.784626]  [] do_scsi_scan_host+0x37/0xa0
[   49.784632]  [] do_scan_async+0x1a/0x30
[   49.784643]  [] async_run_entry_fn+0x9b/0x1d0
[   49.784655]  [] process_one_work+0x1f2/0x620
[   49.784661]  [] ? process_one_work+0x180/0x620
[   49.784668]  [] ? worker_thread+0x5e/0x3a0
[   49.784674]  [] ? async_schedule+0x20/0x20
[   49.784681]  [] worker_thread+0x133/0x3a0
[   49.784688]  [] ? manage_workers+0x190/0x190
[   49.784696]  [] kthread+0xa6/0xb0
[   49.784707]  [] kernel_thread_helper+0x4/0x10
[   49.784715]  [] ? finish_task_switch+0x8c/0x110
[   49.784721]  [] ? _raw_spin_unlock_irq+0x3b/0x70
[   49.784727]  [] ? retint_restore_args+0xe/0xe
[   49.784734]  [] ? kthreadd+0x1e0/0x1e0
[   49.784739]  [] ? gs_change+0xb/0xb

---

When I look at the code I see this call chain
enqueue_cmd_and_start_io()->
set_performant_mode()->
smp_processor_id()
Which if you have debugging enabled calls debug_processor_id() and 
triggers the warning.

I'm not very familiar with the hpsa code, so I'm not entirely sure what 
the purpose of this line is

c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues;

Is the purpose to simply try to get a range of ReplyQueue numbers, but 
somewhat arbitrary? Or is it necessary that the current processor_id 
is used? If it is the former, and you're not accessing per cpu structures, 
or pinning a cpu, or anything like that then I would think it is safe to 
change this to a raw_smp_processor_id() to get rid of a false positive 
warning.

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..4e19267 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h, struct 
CommandList *c)
c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1);
if (likely(h->msix_vector))
c->Header.ReplyQueue =
-   smp_processor_id() % h->nreply_queues;
+   raw_smp_processor_id() % h->nreply_queues;
}
 }
 

Thanks

John Kacur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6

[John Kacur]

Hi

We're seeing this on a 3.6 kernel with the real-time patch applied, but it 
looks like it is relevant with the real-time patch in the latest kernel 
too.

[   49.688847] hpsa :03:00.0: hpsa0: 0x323a at IRQ 67 using DAC
[   49.749928] scsi0 : hpsa
[   49.784437] BUG: using smp_processor_id() in preemptible [ 
] code: kworker/u:0/6
[   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
[   49.784468] Pid: 6, comm: kworker/u:0 Not tainted 
3.6.11.5-rt37.52.el6rt.x86_64.debug #1
[   49.784471] Call Trace:
[   49.784512]  [812abe83] debug_smp_processor_id+0x123/0x150
[   49.784520]  [a009043a] enqueue_cmd_and_start_io+0x5a/0x100 
[hpsa]
[   49.784529]  [a00905cb] 
hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
[   49.784537]  [812b09c8] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784544]  [812b09c8] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784553]  [a0090701] 
hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
[   49.784562]  [a0093558] 
hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
[   49.784571]  [a00935ea] 
hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
[   49.784580]  [a00963df] hpsa_update_scsi_devices+0x11f/0x4f0 
[hpsa]
[   49.784592]  [81592019] ? sub_preempt_count+0xa9/0xe0
[   49.784601]  [a00968ad] hpsa_scan_start+0xfd/0x150 [hpsa]
[   49.784613]  [8158cba8] ? rt_spin_lock_slowunlock+0x78/0x90
[   49.784626]  [813b04d7] do_scsi_scan_host+0x37/0xa0
[   49.784632]  [813b05da] do_scan_async+0x1a/0x30
[   49.784643]  [8107c4ab] async_run_entry_fn+0x9b/0x1d0
[   49.784655]  [8106ae92] process_one_work+0x1f2/0x620
[   49.784661]  [8106ae20] ? process_one_work+0x180/0x620
[   49.784668]  [8106d4fe] ? worker_thread+0x5e/0x3a0
[   49.784674]  [8107c410] ? async_schedule+0x20/0x20
[   49.784681]  [8106d5d3] worker_thread+0x133/0x3a0
[   49.784688]  [8106d4a0] ? manage_workers+0x190/0x190
[   49.784696]  [81073236] kthread+0xa6/0xb0
[   49.784707]  [815970a4] kernel_thread_helper+0x4/0x10
[   49.784715]  [81082a7c] ? finish_task_switch+0x8c/0x110
[   49.784721]  [8158e44b] ? _raw_spin_unlock_irq+0x3b/0x70
[   49.784727]  [8158e85d] ? retint_restore_args+0xe/0xe
[   49.784734]  [81073190] ? kthreadd+0x1e0/0x1e0
[   49.784739]  [815970a0] ? gs_change+0xb/0xb

---

When I look at the code I see this call chain
enqueue_cmd_and_start_io()-
set_performant_mode()-
smp_processor_id()
Which if you have debugging enabled calls debug_processor_id() and 
triggers the warning.

I'm not very familiar with the hpsa code, so I'm not entirely sure what 
the purpose of this line is

c-Header.ReplyQueue = smp_processor_id() % h-nreply_queues;

Is the purpose to simply try to get a range of ReplyQueue numbers, but 
somewhat arbitrary? Or is it necessary that the current processor_id 
is used? If it is the former, and you're not accessing per cpu structures, 
or pinning a cpu, or anything like that then I would think it is safe to 
change this to a raw_smp_processor_id() to get rid of a false positive 
warning.

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..4e19267 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h, struct 
CommandList *c)
c-busaddr |= 1 | (h-blockFetchTable[c-Header.SGList]  1);
if (likely(h-msix_vector))
c-Header.ReplyQueue =
-   smp_processor_id() % h-nreply_queues;
+   raw_smp_processor_id() % h-nreply_queues;
}
 }
 

Thanks

John Kacur
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trace-cmd 2/2] git-housekeeping: Add the .gitattributes file

[John Kacur]

By adding the .gitattributes file, git-archive can be informed not to
includes files such as .gitignore and ironically .gitattributes

Signed-off-by: John Kacur 
---
 .gitattributes | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000..5966153
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+.gitattributes export-ignore
+.gitignore export-ignore
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trace-cmd 1/2] Makefile: add libdir variable

[John Kacur]

This will allow build scripts such as rpm to set libdir=lib64
Signed-off-by: John Kacur 
---
 Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 83329ca..d53cde3 100644
--- a/Makefile
+++ b/Makefile
@@ -47,6 +47,7 @@ html_install = $(prefix)/share/kernelshark/html
 html_install_SQ = '$(subst ','\'',$(html_install))'
 img_install = $(prefix)/share/kernelshark/html/images
 img_install_SQ = '$(subst ','\'',$(img_install))'
+libdir ?= lib
 
 export man_dir man_dir_SQ html_install html_install_SQ INSTALL
 export img_install img_install_SQ
@@ -56,8 +57,8 @@ ifeq ($(prefix),$(HOME))
 plugin_dir = $(HOME)/.trace-cmd/plugins
 python_dir = $(HOME)/.trace-cmd/python
 else
-plugin_dir = $(prefix)/lib/trace-cmd/plugins
-python_dir = $(prefix)/lib/trace-cmd/python
+plugin_dir = $(prefix)/$(libdir)/trace-cmd/plugins
+python_dir = $(prefix)/$(libdir)/trace-cmd/python
 PLUGIN_DIR = -DPLUGIN_DIR="$(plugin_dir)"
 PYTHON_DIR = -DPYTHON_DIR="$(python_dir)"
 PLUGIN_DIR_SQ = '$(subst ','\'',$(PLUGIN_DIR))'
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trace-cmd 2/2] git-housekeeping: Add the .gitattributes file

[John Kacur]

By adding the .gitattributes file, git-archive can be informed not to
includes files such as .gitignore and ironically .gitattributes

Signed-off-by: John Kacur jka...@redhat.com
---
 .gitattributes | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000..5966153
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+.gitattributes export-ignore
+.gitignore export-ignore
-- 
1.7.11.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trace-cmd 1/2] Makefile: add libdir variable

[John Kacur]

This will allow build scripts such as rpm to set libdir=lib64
Signed-off-by: John Kacur jka...@redhat.com
---
 Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 83329ca..d53cde3 100644
--- a/Makefile
+++ b/Makefile
@@ -47,6 +47,7 @@ html_install = $(prefix)/share/kernelshark/html
 html_install_SQ = '$(subst ','\'',$(html_install))'
 img_install = $(prefix)/share/kernelshark/html/images
 img_install_SQ = '$(subst ','\'',$(img_install))'
+libdir ?= lib
 
 export man_dir man_dir_SQ html_install html_install_SQ INSTALL
 export img_install img_install_SQ
@@ -56,8 +57,8 @@ ifeq ($(prefix),$(HOME))
 plugin_dir = $(HOME)/.trace-cmd/plugins
 python_dir = $(HOME)/.trace-cmd/python
 else
-plugin_dir = $(prefix)/lib/trace-cmd/plugins
-python_dir = $(prefix)/lib/trace-cmd/python
+plugin_dir = $(prefix)/$(libdir)/trace-cmd/plugins
+python_dir = $(prefix)/$(libdir)/trace-cmd/python
 PLUGIN_DIR = -DPLUGIN_DIR=$(plugin_dir)
 PYTHON_DIR = -DPYTHON_DIR=$(python_dir)
 PLUGIN_DIR_SQ = '$(subst ','\'',$(PLUGIN_DIR))'
-- 
1.7.11.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.8.10-rt6

[John Kacur]

On Mon, 29 Apr 2013, Clark Williams wrote:

> On Mon, 29 Apr 2013 22:12:02 +0200
> Sebastian Andrzej Siewior  wrote:
> > - suspend / resume seems to program program the timer wrong and wait
> >   ages until it continues.
> > 
> 
> It has to be something we're doing when we apply RT to v3.8.x, since
> v3.8.x suspends/resumes with no issues and I was able to suspend and
> resume fine with the 3.6-rt series.

Our v3.8x series is currently no different than "vanilla" rt.
quilt-import on top of v3.8.10, with no RH patches. So, I know you said 
that just as a polite way to say, "maybe we messed up, but...", however 
I'm confident we didn't.

Also, that must be a typo, you meant to say that v3.8.x does have issues 
with suspend / resume right?
 
> 
> I'm looking at a git diff between 3.6.11-rt30 and 3.8.9-rt4,
> specifically in kernel/time* and arch/x86/kernel but so far I'm not
> seeing much that's RT specific.
> 
> Clark
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.8.10-rt6

[John Kacur]

On Mon, 29 Apr 2013, Clark Williams wrote:

 On Mon, 29 Apr 2013 22:12:02 +0200
 Sebastian Andrzej Siewior bige...@linutronix.de wrote:
  - suspend / resume seems to program program the timer wrong and wait
ages until it continues.
  
 
 It has to be something we're doing when we apply RT to v3.8.x, since
 v3.8.x suspends/resumes with no issues and I was able to suspend and
 resume fine with the 3.6-rt series.

Our v3.8x series is currently no different than vanilla rt.
quilt-import on top of v3.8.10, with no RH patches. So, I know you said 
that just as a polite way to say, maybe we messed up, but..., however 
I'm confident we didn't.

Also, that must be a typo, you meant to say that v3.8.x does have issues 
with suspend / resume right?
 
 
 I'm looking at a git diff between 3.6.11-rt30 and 3.8.9-rt4,
 specifically in kernel/time* and arch/x86/kernel but so far I'm not
 seeing much that's RT specific.
 
 Clark
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.8.4-rt2

[John Kacur]

On Mon, Apr 8, 2013 at 8:30 PM, Sebastian Andrzej Siewior
 wrote:
> * Paul Gortmaker | 2013-04-05 19:35:51 [-0400]:
>
>>Thanks for the work in putting this together.  Just a heads up that the
>>split queue fails on a patch with no author/date/subject as follows:
>>
>>[...]
>>git am of percpu-rwsem-compilefix.patch failed.
>>
>>This "treercu-use-simple-waitqueue.patch" has the exact same problem.
>>
>>Note that I'm using git directly, and not quilt -- which is more
>>strict in what it will accept, hence it catches these kinds of things.
>
> I just fixed up those two. "git quiltimport" works now.
>

Where did you fix these up? Can we have access?

Thanks

John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.8.4-rt2

[John Kacur]

On Mon, Apr 8, 2013 at 8:30 PM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
 * Paul Gortmaker | 2013-04-05 19:35:51 [-0400]:

Thanks for the work in putting this together.  Just a heads up that the
split queue fails on a patch with no author/date/subject as follows:

[...]
git am of percpu-rwsem-compilefix.patch failed.

This treercu-use-simple-waitqueue.patch has the exact same problem.

Note that I'm using git directly, and not quilt -- which is more
strict in what it will accept, hence it catches these kinds of things.

 I just fixed up those two. git quiltimport works now.


Where did you fix these up? Can we have access?

Thanks

John
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.6.11.1-rt32

[John Kacur]

On Tue, 2 Apr 2013, Carsten Emde wrote:

> Steven,
> 
> > I'm pleased to announce the 3.6.11.1-rt32 stable release.
> Unfortunately, there is another compile error:
> drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_wait_for_error’:
> drivers/gpu/drm/i915/i915_gem.c:118:3: warning: passing argument 1 of
> ‘rt_spin_lock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/spinlock.h:273:0,
>  from include/linux/wait.h:24,
>  from include/linux/fs.h:396,
>  from include/drm/drmP.h:47,
>  from drivers/gpu/drm/i915/i915_gem.c:28:
> include/linux/spinlock_rt.h:21:24: note: expected ‘struct spinlock_t *’ but
> argument is of type ‘struct raw_spinlock_t *’
> drivers/gpu/drm/i915/i915_gem.c:120:3: warning: passing argument 1 of
> ‘rt_spin_unlock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/spinlock.h:273:0,
>  from include/linux/wait.h:24,
>  from include/linux/fs.h:396,
>  from include/drm/drmP.h:47,
>  from drivers/gpu/drm/i915/i915_gem.c:28:
> include/linux/spinlock_rt.h:24:24: note: expected ‘struct spinlock_t *’ but
> argument is of type ‘struct raw_spinlock_t *’
> drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_check_wedge’:
> drivers/gpu/drm/i915/i915_gem.c:1890:3: warning: passing argument 1 of
> ‘rt_spin_lock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/spinlock.h:273:0,
>  from include/linux/wait.h:24,
>  from include/linux/fs.h:396,
>  from include/drm/drmP.h:47,
>  from drivers/gpu/drm/i915/i915_gem.c:28:
> include/linux/spinlock_rt.h:21:24: note: expected ‘struct spinlock_t *’ but
> argument is of type ‘struct raw_spinlock_t *’
> drivers/gpu/drm/i915/i915_gem.c:1892:3: warning: passing argument 1 of
> ‘rt_spin_unlock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/spinlock.h:273:0,
>  from include/linux/wait.h:24,
>  from include/linux/fs.h:396,
>  from include/drm/drmP.h:47,
>  from drivers/gpu/drm/i915/i915_gem.c:28:
> include/linux/spinlock_rt.h:24:24: note: expected ‘struct spinlock_t *’ but
> argument is of type ‘struct raw_spinlock_t *’
> 
> I would propose to adopt the mechanism that Sebastian introduced in
> 3.8.4-rt2 (https://lkml.org/lkml/2013/3/26/600). The kernel compiles
> and runs without any problem with the below patch on a system that
> requires the i915 driver module.
> 
>   -Carsten.
> 
> 
> 
> From: Sebastian Andrzej Siewior 
> Subject: gpu/i915: don't open code these things
> 
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
>  drivers/gpu/drm/i915/i915_gem.c |   10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> Index: linux-3.6.11.1-rt32/drivers/gpu/drm/i915/i915_gem.c
> ===
> --- linux-3.6.11.1-rt32.orig/drivers/gpu/drm/i915/i915_gem.c
> +++ linux-3.6.11.1-rt32/drivers/gpu/drm/i915/i915_gem.c
> @@ -90,7 +90,6 @@ i915_gem_wait_for_error(struct drm_devic
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct completion *x = _priv->error_completion;
> - unsigned long flags;
>   int ret;
> 
>   if (!atomic_read(_priv->mm.wedged))
> @@ -115,9 +114,7 @@ i915_gem_wait_for_error(struct drm_devic
>* end up waiting upon a subsequent completion event that
>* will never happen.
>*/
> - spin_lock_irqsave(>wait.lock, flags);
> - x->done++;
> - spin_unlock_irqrestore(>wait.lock, flags);
> + complete(x);
>   }
>   return 0;
>  }
> @@ -1884,12 +1881,9 @@ i915_gem_check_wedge(struct drm_i915_pri
>   if (atomic_read(_priv->mm.wedged)) {
>   struct completion *x = _priv->error_completion;
>   bool recovery_complete;
> - unsigned long flags;
> 
>   /* Give the error handler a chance to run. */
> - spin_lock_irqsave(>wait.lock, flags);
> - recovery_complete = x->done > 0;
> - spin_unlock_irqrestore(>wait.lock, flags);
> + recovery_complete = completion_done(x);
> 
>   /* Non-interruptible callers can't handle -EAGAIN, hence
> return
>* -EIO unconditionally for these. */
> 
> 

Is there a reason you left off the last hunk?

@@ -4366,7 +4360,7 @@ static bool mutex_is_locked_by(struct mu
if (!mutex_is_locked(mutex))
return false;
 
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
+#if (defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)) && 
!defined(CONFIG_PREEMPT_RT_BASE)
return mutex->owner == task;
 #else
/* Since UP may be pre-empted, we cannot assume that we 

Re: [ANNOUNCE] 3.6.11.1-rt32

[John Kacur]

On Tue, 2 Apr 2013, Carsten Emde wrote:

 Steven,
 
  I'm pleased to announce the 3.6.11.1-rt32 stable release.
 Unfortunately, there is another compile error:
 drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_wait_for_error’:
 drivers/gpu/drm/i915/i915_gem.c:118:3: warning: passing argument 1 of
 ‘rt_spin_lock’ from incompatible pointer type [enabled by default]
 In file included from include/linux/spinlock.h:273:0,
  from include/linux/wait.h:24,
  from include/linux/fs.h:396,
  from include/drm/drmP.h:47,
  from drivers/gpu/drm/i915/i915_gem.c:28:
 include/linux/spinlock_rt.h:21:24: note: expected ‘struct spinlock_t *’ but
 argument is of type ‘struct raw_spinlock_t *’
 drivers/gpu/drm/i915/i915_gem.c:120:3: warning: passing argument 1 of
 ‘rt_spin_unlock’ from incompatible pointer type [enabled by default]
 In file included from include/linux/spinlock.h:273:0,
  from include/linux/wait.h:24,
  from include/linux/fs.h:396,
  from include/drm/drmP.h:47,
  from drivers/gpu/drm/i915/i915_gem.c:28:
 include/linux/spinlock_rt.h:24:24: note: expected ‘struct spinlock_t *’ but
 argument is of type ‘struct raw_spinlock_t *’
 drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_check_wedge’:
 drivers/gpu/drm/i915/i915_gem.c:1890:3: warning: passing argument 1 of
 ‘rt_spin_lock’ from incompatible pointer type [enabled by default]
 In file included from include/linux/spinlock.h:273:0,
  from include/linux/wait.h:24,
  from include/linux/fs.h:396,
  from include/drm/drmP.h:47,
  from drivers/gpu/drm/i915/i915_gem.c:28:
 include/linux/spinlock_rt.h:21:24: note: expected ‘struct spinlock_t *’ but
 argument is of type ‘struct raw_spinlock_t *’
 drivers/gpu/drm/i915/i915_gem.c:1892:3: warning: passing argument 1 of
 ‘rt_spin_unlock’ from incompatible pointer type [enabled by default]
 In file included from include/linux/spinlock.h:273:0,
  from include/linux/wait.h:24,
  from include/linux/fs.h:396,
  from include/drm/drmP.h:47,
  from drivers/gpu/drm/i915/i915_gem.c:28:
 include/linux/spinlock_rt.h:24:24: note: expected ‘struct spinlock_t *’ but
 argument is of type ‘struct raw_spinlock_t *’
 
 I would propose to adopt the mechanism that Sebastian introduced in
 3.8.4-rt2 (https://lkml.org/lkml/2013/3/26/600). The kernel compiles
 and runs without any problem with the below patch on a system that
 requires the i915 driver module.
 
   -Carsten.
 
 
 
 From: Sebastian Andrzej Siewior bige...@linutronix.de
 Subject: gpu/i915: don't open code these things
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/gpu/drm/i915/i915_gem.c |   10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)
 
 Index: linux-3.6.11.1-rt32/drivers/gpu/drm/i915/i915_gem.c
 ===
 --- linux-3.6.11.1-rt32.orig/drivers/gpu/drm/i915/i915_gem.c
 +++ linux-3.6.11.1-rt32/drivers/gpu/drm/i915/i915_gem.c
 @@ -90,7 +90,6 @@ i915_gem_wait_for_error(struct drm_devic
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct completion *x = dev_priv-error_completion;
 - unsigned long flags;
   int ret;
 
   if (!atomic_read(dev_priv-mm.wedged))
 @@ -115,9 +114,7 @@ i915_gem_wait_for_error(struct drm_devic
* end up waiting upon a subsequent completion event that
* will never happen.
*/
 - spin_lock_irqsave(x-wait.lock, flags);
 - x-done++;
 - spin_unlock_irqrestore(x-wait.lock, flags);
 + complete(x);
   }
   return 0;
  }
 @@ -1884,12 +1881,9 @@ i915_gem_check_wedge(struct drm_i915_pri
   if (atomic_read(dev_priv-mm.wedged)) {
   struct completion *x = dev_priv-error_completion;
   bool recovery_complete;
 - unsigned long flags;
 
   /* Give the error handler a chance to run. */
 - spin_lock_irqsave(x-wait.lock, flags);
 - recovery_complete = x-done  0;
 - spin_unlock_irqrestore(x-wait.lock, flags);
 + recovery_complete = completion_done(x);
 
   /* Non-interruptible callers can't handle -EAGAIN, hence
 return
* -EIO unconditionally for these. */
 
 

Is there a reason you left off the last hunk?

@@ -4366,7 +4360,7 @@ static bool mutex_is_locked_by(struct mu
if (!mutex_is_locked(mutex))
return false;
 
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
+#if (defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES))  
!defined(CONFIG_PREEMPT_RT_BASE)
return mutex-owner == task;
 #else
/* Since UP may be pre-empted, we cannot assume that we own the 
lock */

Re: [PATCH] futex: fix unbalanced spin_lock/spin_unlock() in exit_pi_state_list()

[John Kacur]

On Fri, Mar 1, 2013 at 1:01 PM, John Kacur  wrote:
> On Fri, Mar 1, 2013 at 2:36 AM, Yong Zhang  wrote:
>> From: Yong Zhang 
>>
>> Otherwise, below warning is shown somtimes when running some test:
>
> It would be nice to know which test!
> ->o SNIP

Luis points out to me that you can tell from the PID that the test is
http://fxr.watson.org/fxr/source/nptl/tst-robust8.c?v=GLIBC27
of the NPTL project (sys/nptl/tst-robust8.c)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] futex: fix unbalanced spin_lock/spin_unlock() in exit_pi_state_list()

[John Kacur]

On Fri, Mar 1, 2013 at 2:36 AM, Yong Zhang  wrote:
> From: Yong Zhang 
>
> Otherwise, below warning is shown somtimes when running some test:

It would be nice to know which test!
->o SNIP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] futex: fix unbalanced spin_lock/spin_unlock() in exit_pi_state_list()

[John Kacur]

On Fri, Mar 1, 2013 at 2:36 AM, Yong Zhang yong.zha...@gmail.com wrote:
 From: Yong Zhang yong.zh...@windriver.com

 Otherwise, below warning is shown somtimes when running some test:

It would be nice to know which test!
-o SNIP
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] futex: fix unbalanced spin_lock/spin_unlock() in exit_pi_state_list()

[John Kacur]

On Fri, Mar 1, 2013 at 1:01 PM, John Kacur jka...@redhat.com wrote:
 On Fri, Mar 1, 2013 at 2:36 AM, Yong Zhang yong.zha...@gmail.com wrote:
 From: Yong Zhang yong.zh...@windriver.com

 Otherwise, below warning is shown somtimes when running some test:

 It would be nice to know which test!
 -o SNIP

Luis points out to me that you can tell from the PID that the test is
http://fxr.watson.org/fxr/source/nptl/tst-robust8.c?v=GLIBC27
of the NPTL project (sys/nptl/tst-robust8.c)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH RT] acpi/rt: Convert acpi lock back to a raw_spinlock_t

[John Kacur]

On Wed, 13 Feb 2013, Thomas Gleixner wrote:

> On Wed, 13 Feb 2013, John Kacur wrote:
> > 
> > Thanks Steven. That looks way better than the previous revert.
> 
> I can't tell as I haven't seen the previous revert. And looks good is
> not really a good review criteria.

Absolutely true, and I wasn't claiming to have reviewed it, just wanted to 
let everyone know that testing on it was to begin.
> 
> The patch is converting _all_ the spin_locks in acpi to raw spinlocks,
> which will give you a nice bunch of "BUG: sleeping function called
> from invalid context" splats depending on the ACPI functionality of
> your machine.
> 
> The lock which is related to this splat is: acpi_gbl_hardware_lock and
> that's the only lock which can be safely converted to a raw spinlock.
> 
> Untested patch below.
> 
> Thanks,
> 
>   tglx


Thank you Thomas, adding this version instead to our test queue.

John

-SNIP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH RT 4/4 v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

[John Kacur]

On Thu, 13 Dec 2012, Steven Rostedt wrote:

> I didn't get a chance to test the latest IPI patch series on the 40 core
> box, and only had my 4 way box to test on. But I was able to test it
> last night and found some issues.
> 
> The RT_PUSH_IPI doesn't get automatically set because just doing the
> sched_feat_enable() wasn't enough. Below is the corrected patch.
> 
> Also, for some reason patch 3 caused the box to hang. Perhaps it
> required the RT_PUSH_IPI set, because it worked with the original patch
> series. But that series only did the push ipi. I removed it on the 40
> core before noticing that the RT_PUSH_IPI wasn't being automatically
> enabled.
> 
> Here's an update of patch 4:
> 
> sched/rt: Use IPI to trigger RT task push migration instead of pulling
> 
> When debugging the latencies on a 40 core box, where we hit 300 to
> 500 microsecond latencies, I found there was a huge contention on the
> runqueue locks.
> 
> Investigating it further, running ftrace, I found that it was due to
> the pulling of RT tasks.
> 
> The test that was run was the following:
> 
>  cyclictest --numa -p95 -m -d0 -i100
> 
> This created a thread on each CPU, that would set its wakeup in interations
> of 100 microseconds. The -d0 means that all the threads had the same
> interval (100us). Each thread sleeps for 100us and wakes up and measures
> its latencies.
> 
> What happened was another RT task would be scheduled on one of the CPUs
> that was running our test, when the other CPUS test went to sleep and
> scheduled idle. This cause the "pull" operation to execute on all
> these CPUs. Each one of these saw the RT task that was overloaded on
> the CPU of the test that was still running, and each one tried
> to grab that task in a thundering herd way.
> 
> To grab the task, each thread would do a double rq lock grab, grabbing
> its own lock as well as the rq of the overloaded CPU. As the sched
> domains on this box was rather flat for its size, I saw up to 12 CPUs
> block on this lock at once. This caused a ripple affect with the
> rq locks. As these locks were blocked, any wakeups or load balanceing
> on these CPUs would also block on these locks, and the wait time escalated.
> 
> I've tried various methods to lesson the load, but things like an
> atomic counter to only let one CPU grab the task wont work, because
> the task may have a limited affinity, and we may pick the wrong
> CPU to take that lock and do the pull, to only find out that the
> CPU we picked isn't in the task's affinity.
> 
> Instead of doing the PULL, I now have the CPUs that want the pull to
> send over an IPI to the overloaded CPU, and let that CPU pick what
> CPU to push the task to. No more need to grab the rq lock, and the
> push/pull algorithm still works fine.
> 
> With this patch, the latency dropped to just 150us over a 20 hour run.
> Without the patch, the huge latencies would trigger in seconds.
> 
> Now, this issue only seems to apply to boxes with greater than 16 CPUs.
> We noticed this on a 24 CPU box, and things got much worse on 40 (and
> presumably more CPUs would get even worse yet). But running with 16
> CPUs and below, the lock contention caused by the pulling of RT tasks
> is not noticable.
> 
> I've created a new sched feature called RT_PUSH_IPI, which by default
> on 16 and less core CPUs is disabled, and on 17 or more CPUs it is
> enabled. That seems to be heuristic limit where the pulling logic
> causes higher latencies than IPIs. Of course with all heuristics, things
> could be different with different architectures.
> 
> When RT_PUSH_IPI is not enabled, the old method of grabbing the rq locks
> and having the pulling CPU do the work is implemented. When RT_PUSH_IPI
> is enabled, the IPI is sent to the overloaded CPU to do a push.
> 
> To enabled or disable this at run time:
> 
>  # mount -t debugfs nodev /sys/kernel/debug
>  # echo RT_PUSH_IPI > /sys/kernel/debug/sched_features
> or
>  # echo NO_RT_PUSH_IPI > /sys/kernel/debug/sched_features
> 
> Signed-off-by: Steven Rostedt 
> 
> Index: rt-linux.git/kernel/sched/core.c
> ===
> --- rt-linux.git.orig/kernel/sched/core.c
> +++ rt-linux.git/kernel/sched/core.c
> @@ -1538,6 +1538,9 @@ static void sched_ttwu_pending(void)
>  
>  void scheduler_ipi(void)
>  {
> + if (sched_feat(RT_PUSH_IPI))
> + sched_rt_push_check();
> +
>   if (llist_empty(_rq()->wake_list) && !got_nohz_idle_kick())
>   return;
>  
> @@ -7541,6 +7544,21 @@ void __init sched_init_smp(void)
>   free_cpumask_var(non_isolated_cpus);
>  
>   init_sched_rt_class();
> +
> + /*
> +  * To avoid heavy contention on large CPU boxes,
> +  * when there is an RT overloaded CPU (two or more RT tasks
> +  * queued to run on a CPU and one of the waiting RT tasks
> +  * can migrate) and another CPU lowers its priority, instead
> +  * of grabbing both rq locks of the CPUS (as many CPUs lowering
> + 

Re: [RFC][PATCH RT] acpi/rt: Convert acpi lock back to a raw_spinlock_t

[John Kacur]

On Wed, 13 Feb 2013, Steven Rostedt wrote:

> We hit the following bug with 3.6-rt:
> 
> [5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002 
> [5.898991] no locks held by swapper/3/0. 
> [5.898993] Modules linked in: 
> [5.898996] Pid: 0, comm: swapper/3 Not tainted 
> 3.6.11-rt28.19.el6rt.x86_64.debug #1 
> [5.898997] Call Trace: 
> [5.899011]  [] __schedule_bug+0x67/0x90 
> [5.899028]  [] __schedule+0x793/0x7a0 
> [5.899032]  [] ? 
> debug_rt_mutex_print_deadlock+0x50/0x200 
> [5.899034]  [] schedule+0x29/0x70 
> [5.899036] BUG: scheduling while atomic: swapper/7/0/0x0002 
> [5.899037] no locks held by swapper/7/0. 
> [5.899039]  [] rt_spin_lock_slowlock+0xe5/0x2f0 
> [5.899040] Modules linked in: 
> [5.899041]  
> [5.899045]  [] ? _raw_spin_unlock_irqrestore+0x38/0x90 
> [5.899046] Pid: 0, comm: swapper/7 Not tainted 
> 3.6.11-rt28.19.el6rt.x86_64.debug #1 
> [5.899047] Call Trace: 
> [5.899049]  [] rt_spin_lock+0x16/0x40 
> [5.899052]  [] __schedule_bug+0x67/0x90 
> [5.899054]  [] ? notifier_call_chain+0x80/0x80 
> [5.899056]  [] __schedule+0x793/0x7a0 
> [5.899059]  [] acpi_os_acquire_lock+0x1f/0x23 
> [5.899062]  [] ? 
> debug_rt_mutex_print_deadlock+0x50/0x200 
> [5.899068]  [] acpi_write_bit_register+0x33/0xb0 
> [5.899071]  [] schedule+0x29/0x70 
> [5.899072]  [] ? acpi_read_bit_register+0x33/0x51 
> [5.899074]  [] rt_spin_lock_slowlock+0xe5/0x2f0 
> [5.899077]  [] acpi_idle_enter_bm+0x8a/0x28e 
> [5.899079]  [] ? _raw_spin_unlock_irqrestore+0x38/0x90 
> [5.899081]  [] ? this_cpu_load+0x1a/0x30 
> [5.899083]  [] rt_spin_lock+0x16/0x40 
> [5.899087]  [] cpuidle_enter+0x19/0x20 
> [5.899088]  [] ? notifier_call_chain+0x80/0x80 
> [5.899090]  [] cpuidle_enter_state+0x17/0x50 
> [5.899092]  [] acpi_os_acquire_lock+0x1f/0x23 
> [5.899094]  [] cpuidle899101]  [] ? 
> 
> As the acpi code disables interrupts in acpi_idle_enter_bm, and calls
> code that grabs the acpi lock, it causes issues as the lock is currently
> in RT a sleeping lock.
> 
> The lock was converted from a raw to a sleeping lock due to some
> previous issues, and tests that showed it didn't seem to matter.
> Unfortunately, it did matter for one of our boxes.
> 
> This patch converts the lock back to a raw lock. I've run this code on a
> few of my own machines, one being my laptop that uses the acpi quite
> extensively. I've been able to suspend and resume without issues.
> 
> But as it may have issues still with other hardware, I'm posting this as
> an RFC.
> 
> Signed-off-by: Steven Rostedt 
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 9eaf708..83d38ed 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -1432,7 +1432,7 @@ void acpi_os_delete_lock(acpi_spinlock handle)
>  acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
>  {
>   acpi_cpu_flags flags;
> - spin_lock_irqsave(lockp, flags);
> + raw_spin_lock_irqsave(lockp, flags);
>   return flags;
>  }
>  
> @@ -1442,7 +1442,7 @@ acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
>  
>  void acpi_os_release_lock(acpi_spinlock lockp, acpi_cpu_flags flags)
>  {
> - spin_unlock_irqrestore(lockp, flags);
> + raw_spin_unlock_irqrestore(lockp, flags);
>  }
>  
>  #ifndef ACPI_USE_LOCAL_CACHE
> diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
> index 7509be3..484cf8c 100644
> --- a/include/acpi/platform/aclinux.h
> +++ b/include/acpi/platform/aclinux.h
> @@ -71,7 +71,7 @@
>  #define strtoul simple_strtoul
>  
>  #define acpi_cache_tstruct kmem_cache
> -#define acpi_spinlock   spinlock_t *
> +#define acpi_spinlock   raw_spinlock_t *
>  #define acpi_cpu_flags  unsigned long
>  
>  #else /* !__KERNEL__ */
> @@ -170,7 +170,7 @@ static inline void *acpi_os_acquire_object(acpi_cache_t * 
> cache)
>   \
>   if (lock) { \
>   *(__handle) = lock; \
> - spin_lock_init(*(__handle));\
> + raw_spin_lock_init(*(__handle));\
>   }   \
>   lock ? AE_OK : AE_NO_MEMORY;\
>  })
> 
> 

Thanks Steven. That looks way better than the previous revert.
Applying to the latest RH testing queue, will let you know.

John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH RT] acpi/rt: Convert acpi lock back to a raw_spinlock_t

[John Kacur]

On Wed, 13 Feb 2013, Steven Rostedt wrote:

 We hit the following bug with 3.6-rt:
 
 [5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002 
 [5.898991] no locks held by swapper/3/0. 
 [5.898993] Modules linked in: 
 [5.898996] Pid: 0, comm: swapper/3 Not tainted 
 3.6.11-rt28.19.el6rt.x86_64.debug #1 
 [5.898997] Call Trace: 
 [5.899011]  [810804e7] __schedule_bug+0x67/0x90 
 [5.899028]  [81577923] __schedule+0x793/0x7a0 
 [5.899032]  [810b4e40] ? 
 debug_rt_mutex_print_deadlock+0x50/0x200 
 [5.899034]  [81577b89] schedule+0x29/0x70 
 [5.899036] BUG: scheduling while atomic: swapper/7/0/0x0002 
 [5.899037] no locks held by swapper/7/0. 
 [5.899039]  [81578525] rt_spin_lock_slowlock+0xe5/0x2f0 
 [5.899040] Modules linked in: 
 [5.899041]  
 [5.899045]  [81579a58] ? _raw_spin_unlock_irqrestore+0x38/0x90 
 [5.899046] Pid: 0, comm: swapper/7 Not tainted 
 3.6.11-rt28.19.el6rt.x86_64.debug #1 
 [5.899047] Call Trace: 
 [5.899049]  [81578bc6] rt_spin_lock+0x16/0x40 
 [5.899052]  [810804e7] __schedule_bug+0x67/0x90 
 [5.899054]  [8157d3f0] ? notifier_call_chain+0x80/0x80 
 [5.899056]  [81577923] __schedule+0x793/0x7a0 
 [5.899059]  [812f2034] acpi_os_acquire_lock+0x1f/0x23 
 [5.899062]  [810b4e40] ? 
 debug_rt_mutex_print_deadlock+0x50/0x200 
 [5.899068]  [8130be64] acpi_write_bit_register+0x33/0xb0 
 [5.899071]  [81577b89] schedule+0x29/0x70 
 [5.899072]  [8130be13] ? acpi_read_bit_register+0x33/0x51 
 [5.899074]  [81578525] rt_spin_lock_slowlock+0xe5/0x2f0 
 [5.899077]  [8131d1fc] acpi_idle_enter_bm+0x8a/0x28e 
 [5.899079]  [81579a58] ? _raw_spin_unlock_irqrestore+0x38/0x90 
 [5.899081]  [8107e5da] ? this_cpu_load+0x1a/0x30 
 [5.899083]  [81578bc6] rt_spin_lock+0x16/0x40 
 [5.899087]  [8144c759] cpuidle_enter+0x19/0x20 
 [5.899088]  [8157d3f0] ? notifier_call_chain+0x80/0x80 
 [5.899090]  [8144c777] cpuidle_enter_state+0x17/0x50 
 [5.899092]  [812f2034] acpi_os_acquire_lock+0x1f/0x23 
 [5.899094]  [8144d1a1] cpuidle899101]  [8130be13] ? 
 
 As the acpi code disables interrupts in acpi_idle_enter_bm, and calls
 code that grabs the acpi lock, it causes issues as the lock is currently
 in RT a sleeping lock.
 
 The lock was converted from a raw to a sleeping lock due to some
 previous issues, and tests that showed it didn't seem to matter.
 Unfortunately, it did matter for one of our boxes.
 
 This patch converts the lock back to a raw lock. I've run this code on a
 few of my own machines, one being my laptop that uses the acpi quite
 extensively. I've been able to suspend and resume without issues.
 
 But as it may have issues still with other hardware, I'm posting this as
 an RFC.
 
 Signed-off-by: Steven Rostedt rost...@goodmis.org
 
 diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
 index 9eaf708..83d38ed 100644
 --- a/drivers/acpi/osl.c
 +++ b/drivers/acpi/osl.c
 @@ -1432,7 +1432,7 @@ void acpi_os_delete_lock(acpi_spinlock handle)
  acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
  {
   acpi_cpu_flags flags;
 - spin_lock_irqsave(lockp, flags);
 + raw_spin_lock_irqsave(lockp, flags);
   return flags;
  }
  
 @@ -1442,7 +1442,7 @@ acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
  
  void acpi_os_release_lock(acpi_spinlock lockp, acpi_cpu_flags flags)
  {
 - spin_unlock_irqrestore(lockp, flags);
 + raw_spin_unlock_irqrestore(lockp, flags);
  }
  
  #ifndef ACPI_USE_LOCAL_CACHE
 diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
 index 7509be3..484cf8c 100644
 --- a/include/acpi/platform/aclinux.h
 +++ b/include/acpi/platform/aclinux.h
 @@ -71,7 +71,7 @@
  #define strtoul simple_strtoul
  
  #define acpi_cache_tstruct kmem_cache
 -#define acpi_spinlock   spinlock_t *
 +#define acpi_spinlock   raw_spinlock_t *
  #define acpi_cpu_flags  unsigned long
  
  #else /* !__KERNEL__ */
 @@ -170,7 +170,7 @@ static inline void *acpi_os_acquire_object(acpi_cache_t * 
 cache)
   \
   if (lock) { \
   *(__handle) = lock; \
 - spin_lock_init(*(__handle));\
 + raw_spin_lock_init(*(__handle));\
   }   \
   lock ? AE_OK : AE_NO_MEMORY;\
  })
 
 

Thanks Steven. That looks way better than the previous revert.
Applying to the latest RH testing queue, will let you know.

John
--
To unsubscribe from this 

Re: [RFC][PATCH RT 4/4 v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

[John Kacur]

On Thu, 13 Dec 2012, Steven Rostedt wrote:

 I didn't get a chance to test the latest IPI patch series on the 40 core
 box, and only had my 4 way box to test on. But I was able to test it
 last night and found some issues.
 
 The RT_PUSH_IPI doesn't get automatically set because just doing the
 sched_feat_enable() wasn't enough. Below is the corrected patch.
 
 Also, for some reason patch 3 caused the box to hang. Perhaps it
 required the RT_PUSH_IPI set, because it worked with the original patch
 series. But that series only did the push ipi. I removed it on the 40
 core before noticing that the RT_PUSH_IPI wasn't being automatically
 enabled.
 
 Here's an update of patch 4:
 
 sched/rt: Use IPI to trigger RT task push migration instead of pulling
 
 When debugging the latencies on a 40 core box, where we hit 300 to
 500 microsecond latencies, I found there was a huge contention on the
 runqueue locks.
 
 Investigating it further, running ftrace, I found that it was due to
 the pulling of RT tasks.
 
 The test that was run was the following:
 
  cyclictest --numa -p95 -m -d0 -i100
 
 This created a thread on each CPU, that would set its wakeup in interations
 of 100 microseconds. The -d0 means that all the threads had the same
 interval (100us). Each thread sleeps for 100us and wakes up and measures
 its latencies.
 
 What happened was another RT task would be scheduled on one of the CPUs
 that was running our test, when the other CPUS test went to sleep and
 scheduled idle. This cause the pull operation to execute on all
 these CPUs. Each one of these saw the RT task that was overloaded on
 the CPU of the test that was still running, and each one tried
 to grab that task in a thundering herd way.
 
 To grab the task, each thread would do a double rq lock grab, grabbing
 its own lock as well as the rq of the overloaded CPU. As the sched
 domains on this box was rather flat for its size, I saw up to 12 CPUs
 block on this lock at once. This caused a ripple affect with the
 rq locks. As these locks were blocked, any wakeups or load balanceing
 on these CPUs would also block on these locks, and the wait time escalated.
 
 I've tried various methods to lesson the load, but things like an
 atomic counter to only let one CPU grab the task wont work, because
 the task may have a limited affinity, and we may pick the wrong
 CPU to take that lock and do the pull, to only find out that the
 CPU we picked isn't in the task's affinity.
 
 Instead of doing the PULL, I now have the CPUs that want the pull to
 send over an IPI to the overloaded CPU, and let that CPU pick what
 CPU to push the task to. No more need to grab the rq lock, and the
 push/pull algorithm still works fine.
 
 With this patch, the latency dropped to just 150us over a 20 hour run.
 Without the patch, the huge latencies would trigger in seconds.
 
 Now, this issue only seems to apply to boxes with greater than 16 CPUs.
 We noticed this on a 24 CPU box, and things got much worse on 40 (and
 presumably more CPUs would get even worse yet). But running with 16
 CPUs and below, the lock contention caused by the pulling of RT tasks
 is not noticable.
 
 I've created a new sched feature called RT_PUSH_IPI, which by default
 on 16 and less core CPUs is disabled, and on 17 or more CPUs it is
 enabled. That seems to be heuristic limit where the pulling logic
 causes higher latencies than IPIs. Of course with all heuristics, things
 could be different with different architectures.
 
 When RT_PUSH_IPI is not enabled, the old method of grabbing the rq locks
 and having the pulling CPU do the work is implemented. When RT_PUSH_IPI
 is enabled, the IPI is sent to the overloaded CPU to do a push.
 
 To enabled or disable this at run time:
 
  # mount -t debugfs nodev /sys/kernel/debug
  # echo RT_PUSH_IPI  /sys/kernel/debug/sched_features
 or
  # echo NO_RT_PUSH_IPI  /sys/kernel/debug/sched_features
 
 Signed-off-by: Steven Rostedt rost...@goodmis.org
 
 Index: rt-linux.git/kernel/sched/core.c
 ===
 --- rt-linux.git.orig/kernel/sched/core.c
 +++ rt-linux.git/kernel/sched/core.c
 @@ -1538,6 +1538,9 @@ static void sched_ttwu_pending(void)
  
  void scheduler_ipi(void)
  {
 + if (sched_feat(RT_PUSH_IPI))
 + sched_rt_push_check();
 +
   if (llist_empty(this_rq()-wake_list)  !got_nohz_idle_kick())
   return;
  
 @@ -7541,6 +7544,21 @@ void __init sched_init_smp(void)
   free_cpumask_var(non_isolated_cpus);
  
   init_sched_rt_class();
 +
 + /*
 +  * To avoid heavy contention on large CPU boxes,
 +  * when there is an RT overloaded CPU (two or more RT tasks
 +  * queued to run on a CPU and one of the waiting RT tasks
 +  * can migrate) and another CPU lowers its priority, instead
 +  * of grabbing both rq locks of the CPUS (as many CPUs lowering
 +  * their priority at the same time may create large latencies)
 +  * send an IPI to the 

Re: [RFC][PATCH RT] acpi/rt: Convert acpi lock back to a raw_spinlock_t

[John Kacur]

On Wed, 13 Feb 2013, Thomas Gleixner wrote:

 On Wed, 13 Feb 2013, John Kacur wrote:
  
  Thanks Steven. That looks way better than the previous revert.
 
 I can't tell as I haven't seen the previous revert. And looks good is
 not really a good review criteria.

Absolutely true, and I wasn't claiming to have reviewed it, just wanted to 
let everyone know that testing on it was to begin.
 
 The patch is converting _all_ the spin_locks in acpi to raw spinlocks,
 which will give you a nice bunch of BUG: sleeping function called
 from invalid context splats depending on the ACPI functionality of
 your machine.
 
 The lock which is related to this splat is: acpi_gbl_hardware_lock and
 that's the only lock which can be safely converted to a raw spinlock.
 
 Untested patch below.
 
 Thanks,
 
   tglx


Thank you Thomas, adding this version instead to our test queue.

John

-SNIP
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: Use enum instead of literals for trap values

[John Kacur]

From: Kees Cook 

commit c94082656dac74257f63e91f78d5d458ac781fa5 upstream

The traps are referred to by their numbers and it can be difficult to
understand them while reading the code without context. This patch adds
enumeration of the trap numbers and replaces the numbers with the correct
enum for x86.

Signed-off-by: Kees Cook 
Link: http://lkml.kernel.org/r/2012031710.ga32...@www.outflux.net
Signed-off-by: H. Peter Anvin 
Cherry-picked-for: v2.3.37

This fixes the following build error
make O=/bld/v3.2.37
make[2]: Nothing to be done for `relocs'.
  Using /home/jkacur/linux-rt as source for kernel
  GEN /bld/v3.2.37/Makefile
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALL/home/jkacur/linux-rt/scripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/misc/sgi-xp/xpc_main.o
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c: In function 
‘xpc_system_die’:
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: ‘X86_TRAP_DF’ 
undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: (Each 
undeclared identifier is reported only once
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: for each 
function it appears in.)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1211: error: ‘X86_TRAP_MF’ 
undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1212: error: ‘X86_TRAP_XF’ 
undeclared (first use in this function)
make[4]: *** [drivers/misc/sgi-xp/xpc_main.o] Error 1
make[3]: *** [drivers/misc/sgi-xp] Error 2
make[2]: *** [drivers/misc] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

Conflicts:
arch/x86/kernel/traps.c
Signed-off-by: John Kacur 
---
 arch/x86/include/asm/traps.h |   25 +
 arch/x86/kernel/irqinit.c|2 +-
 arch/x86/kernel/traps.c  |  120 ++---
 3 files changed, 90 insertions(+), 57 deletions(-)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 0012d09..88eae2a 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -89,4 +89,29 @@ asmlinkage void smp_thermal_interrupt(void);
 asmlinkage void mce_threshold_interrupt(void);
 #endif
 
+/* Interrupts/Exceptions */
+enum {
+   X86_TRAP_DE = 0,/*  0, Divide-by-zero */
+   X86_TRAP_DB,/*  1, Debug */
+   X86_TRAP_NMI,   /*  2, Non-maskable Interrupt */
+   X86_TRAP_BP,/*  3, Breakpoint */
+   X86_TRAP_OF,/*  4, Overflow */
+   X86_TRAP_BR,/*  5, Bound Range Exceeded */
+   X86_TRAP_UD,/*  6, Invalid Opcode */
+   X86_TRAP_NM,/*  7, Device Not Available */
+   X86_TRAP_DF,/*  8, Double Fault */
+   X86_TRAP_OLD_MF,/*  9, Coprocessor Segment Overrun */
+   X86_TRAP_TS,/* 10, Invalid TSS */
+   X86_TRAP_NP,/* 11, Segment Not Present */
+   X86_TRAP_SS,/* 12, Stack Segment Fault */
+   X86_TRAP_GP,/* 13, General Protection Fault */
+   X86_TRAP_PF,/* 14, Page Fault */
+   X86_TRAP_SPURIOUS,  /* 15, Spurious Interrupt */
+   X86_TRAP_MF,/* 16, x87 Floating-Point Exception */
+   X86_TRAP_AC,/* 17, Alignment Check */
+   X86_TRAP_MC,/* 18, Machine Check */
+   X86_TRAP_XF,/* 19, SIMD Floating-Point Exception */
+   X86_TRAP_IRET = 32, /* 32, IRET Exception */
+};
+
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index b3300e6..e328f69 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -61,7 +61,7 @@ static irqreturn_t math_error_irq(int cpl, void *dev_id)
outb(0, 0xF0);
if (ignore_fpu_irq || !boot_cpu_data.hard_math)
return IRQ_NONE;
-   math_error(get_irq_regs(), 0, 16);
+   math_error(get_irq_regs(), 0, X86_TRAP_MF);
return IRQ_HANDLED;
 }
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 31d9d0f..e6fbb94 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -119,7 +119,7 @@ do_trap(int trapnr, int signr, char *str, struct pt_regs 
*regs,
 * traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
 * On nmi (interrupt 2), do_trap should not be called.
 */
-   if (trapnr < 6)
+   if (trapnr < X86_TRAP_UD)
goto vm86_trap;
goto trap_signal;
}
@@ -203,27 +203,31 @@ dotraplinkage void do_##name(struct pt_regs *regs, long 
error_code)   \
do_trap(trapnr, signr, str, regs, error_code, );   \
 }
 
-DO_ERROR_INFO(0, SIGFPE, "divide error", divide_error, FPE_INTDIV, regs->ip)
-DO_ERROR(4, SIGSEGV, &

[PATCH RT] Fix v3.2.37-rt55 build break

[John Kacur]

make O=/bld/v3.2.37-rt55/
make[2]: Nothing to be done for `relocs'.
  Using /home/jkacur/linux-rt as source for kernel
  GEN /bld/v3.2.37-rt55/Makefile
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALL/home/jkacur/linux-rt/scripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/misc/sgi-xp/xpc_main.o
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c: In function 
‘xpc_system_die’:
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: 
‘X86_TRAP_DF’ undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: (Each 
undeclared identifier is reported only once
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: for each 
function it appears in.)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1211: error: 
‘X86_TRAP_MF’ undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1212: error: 
‘X86_TRAP_XF’ undeclared (first use in this function)
make[4]: *** [drivers/misc/sgi-xp/xpc_main.o] Error 1
make[3]: *** [drivers/misc/sgi-xp] Error 2
make[2]: *** [drivers/misc] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

Clark Williams pointed out that this can be fixed by cherry-picking
c94082656dac74257f63e91f78d5d458ac781fa5
However, there are build conflicts with the rt-patch

The following is my fix applied to the rt-kernel, but it's fine with
me if you want to do the cherry-pick against the stable kernel,
and then respin fix-rt-int3-x86_32-3.2-rt.patch

Note, I believe this is correct but we're still doing our
internal testing.

commit 8c71778132f732bb45ec00c2bda1e39114098479
Author: Kees Cook 
Date:   Fri Mar 9 16:07:10 2012 -0800

x86: Use enum instead of literals for trap values

commit c94082656dac74257f63e91f78d5d458ac781fa5 upstream

The traps are referred to by their numbers and it can be difficult to
understand them while reading the code without context. This patch adds
enumeration of the trap numbers and replaces the numbers with the correct
enum for x86.

Signed-off-by: Kees Cook 
Link: http://lkml.kernel.org/r/2012031710.ga32...@www.outflux.net
Signed-off-by: H. Peter Anvin 
Cherry-picked-for: v3.2-rt
Conflicts:
arch/x86/kernel/traps.c
Signed-off-by: John Kacur 

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 0012d09..88eae2a 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -89,4 +89,29 @@ asmlinkage void smp_thermal_interrupt(void);
 asmlinkage void mce_threshold_interrupt(void);
 #endif
 
+/* Interrupts/Exceptions */
+enum {
+   X86_TRAP_DE = 0,/*  0, Divide-by-zero */
+   X86_TRAP_DB,/*  1, Debug */
+   X86_TRAP_NMI,   /*  2, Non-maskable Interrupt */
+   X86_TRAP_BP,/*  3, Breakpoint */
+   X86_TRAP_OF,/*  4, Overflow */
+   X86_TRAP_BR,/*  5, Bound Range Exceeded */
+   X86_TRAP_UD,/*  6, Invalid Opcode */
+   X86_TRAP_NM,/*  7, Device Not Available */
+   X86_TRAP_DF,/*  8, Double Fault */
+   X86_TRAP_OLD_MF,/*  9, Coprocessor Segment Overrun */
+   X86_TRAP_TS,/* 10, Invalid TSS */
+   X86_TRAP_NP,/* 11, Segment Not Present */
+   X86_TRAP_SS,/* 12, Stack Segment Fault */
+   X86_TRAP_GP,/* 13, General Protection Fault */
+   X86_TRAP_PF,/* 14, Page Fault */
+   X86_TRAP_SPURIOUS,  /* 15, Spurious Interrupt */
+   X86_TRAP_MF,/* 16, x87 Floating-Point Exception */
+   X86_TRAP_AC,/* 17, Alignment Check */
+   X86_TRAP_MC,/* 18, Machine Check */
+   X86_TRAP_XF,/* 19, SIMD Floating-Point Exception */
+   X86_TRAP_IRET = 32, /* 32, IRET Exception */
+};
+
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index b3300e6..e328f69 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -61,7 +61,7 @@ static irqreturn_t math_error_irq(int cpl, void *dev_id)
outb(0, 0xF0);
if (ignore_fpu_irq || !boot_cpu_data.hard_math)
return IRQ_NONE;
-   math_error(get_irq_regs(), 0, 16);
+   math_error(get_irq_regs(), 0, X86_TRAP_MF);
return IRQ_HANDLED;
 }
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index cc88aec..ed4c00c 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -133,7 +133,7 @@ do_trap(int trapnr, int signr, char *str, struct pt_regs 
*regs,
 * traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
 * On nmi (interrupt 2), do_trap should not be called.
 */
-   if (trapnr < 6)
+   if (trapnr < X86_T

[PATCH RT] Fix v3.2.37-rt55 build break

[John Kacur]

make O=/bld/v3.2.37-rt55/
make[2]: Nothing to be done for `relocs'.
  Using /home/jkacur/linux-rt as source for kernel
  GEN /bld/v3.2.37-rt55/Makefile
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALL/home/jkacur/linux-rt/scripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/misc/sgi-xp/xpc_main.o
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c: In function 
‘xpc_system_die’:
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: 
‘X86_TRAP_DF’ undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: (Each 
undeclared identifier is reported only once
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: for each 
function it appears in.)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1211: error: 
‘X86_TRAP_MF’ undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1212: error: 
‘X86_TRAP_XF’ undeclared (first use in this function)
make[4]: *** [drivers/misc/sgi-xp/xpc_main.o] Error 1
make[3]: *** [drivers/misc/sgi-xp] Error 2
make[2]: *** [drivers/misc] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

Clark Williams pointed out that this can be fixed by cherry-picking
c94082656dac74257f63e91f78d5d458ac781fa5
However, there are build conflicts with the rt-patch

The following is my fix applied to the rt-kernel, but it's fine with
me if you want to do the cherry-pick against the stable kernel,
and then respin fix-rt-int3-x86_32-3.2-rt.patch

Note, I believe this is correct but we're still doing our
internal testing.

commit 8c71778132f732bb45ec00c2bda1e39114098479
Author: Kees Cook keesc...@chromium.org
Date:   Fri Mar 9 16:07:10 2012 -0800

x86: Use enum instead of literals for trap values

commit c94082656dac74257f63e91f78d5d458ac781fa5 upstream

The traps are referred to by their numbers and it can be difficult to
understand them while reading the code without context. This patch adds
enumeration of the trap numbers and replaces the numbers with the correct
enum for x86.

Signed-off-by: Kees Cook keesc...@chromium.org
Link: http://lkml.kernel.org/r/2012031710.ga32...@www.outflux.net
Signed-off-by: H. Peter Anvin h...@zytor.com
Cherry-picked-for: v3.2-rt
Conflicts:
arch/x86/kernel/traps.c
Signed-off-by: John Kacur jka...@redhat.com

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 0012d09..88eae2a 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -89,4 +89,29 @@ asmlinkage void smp_thermal_interrupt(void);
 asmlinkage void mce_threshold_interrupt(void);
 #endif
 
+/* Interrupts/Exceptions */
+enum {
+   X86_TRAP_DE = 0,/*  0, Divide-by-zero */
+   X86_TRAP_DB,/*  1, Debug */
+   X86_TRAP_NMI,   /*  2, Non-maskable Interrupt */
+   X86_TRAP_BP,/*  3, Breakpoint */
+   X86_TRAP_OF,/*  4, Overflow */
+   X86_TRAP_BR,/*  5, Bound Range Exceeded */
+   X86_TRAP_UD,/*  6, Invalid Opcode */
+   X86_TRAP_NM,/*  7, Device Not Available */
+   X86_TRAP_DF,/*  8, Double Fault */
+   X86_TRAP_OLD_MF,/*  9, Coprocessor Segment Overrun */
+   X86_TRAP_TS,/* 10, Invalid TSS */
+   X86_TRAP_NP,/* 11, Segment Not Present */
+   X86_TRAP_SS,/* 12, Stack Segment Fault */
+   X86_TRAP_GP,/* 13, General Protection Fault */
+   X86_TRAP_PF,/* 14, Page Fault */
+   X86_TRAP_SPURIOUS,  /* 15, Spurious Interrupt */
+   X86_TRAP_MF,/* 16, x87 Floating-Point Exception */
+   X86_TRAP_AC,/* 17, Alignment Check */
+   X86_TRAP_MC,/* 18, Machine Check */
+   X86_TRAP_XF,/* 19, SIMD Floating-Point Exception */
+   X86_TRAP_IRET = 32, /* 32, IRET Exception */
+};
+
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index b3300e6..e328f69 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -61,7 +61,7 @@ static irqreturn_t math_error_irq(int cpl, void *dev_id)
outb(0, 0xF0);
if (ignore_fpu_irq || !boot_cpu_data.hard_math)
return IRQ_NONE;
-   math_error(get_irq_regs(), 0, 16);
+   math_error(get_irq_regs(), 0, X86_TRAP_MF);
return IRQ_HANDLED;
 }
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index cc88aec..ed4c00c 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -133,7 +133,7 @@ do_trap(int trapnr, int signr, char *str, struct pt_regs 
*regs,
 * traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
 * On nmi (interrupt 2), do_trap should not be called

[PATCH] x86: Use enum instead of literals for trap values

[John Kacur]

From: Kees Cook keesc...@chromium.org

commit c94082656dac74257f63e91f78d5d458ac781fa5 upstream

The traps are referred to by their numbers and it can be difficult to
understand them while reading the code without context. This patch adds
enumeration of the trap numbers and replaces the numbers with the correct
enum for x86.

Signed-off-by: Kees Cook keesc...@chromium.org
Link: http://lkml.kernel.org/r/2012031710.ga32...@www.outflux.net
Signed-off-by: H. Peter Anvin h...@zytor.com
Cherry-picked-for: v2.3.37

This fixes the following build error
make O=/bld/v3.2.37
make[2]: Nothing to be done for `relocs'.
  Using /home/jkacur/linux-rt as source for kernel
  GEN /bld/v3.2.37/Makefile
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALL/home/jkacur/linux-rt/scripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/misc/sgi-xp/xpc_main.o
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c: In function 
‘xpc_system_die’:
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: ‘X86_TRAP_DF’ 
undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: (Each 
undeclared identifier is reported only once
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1208: error: for each 
function it appears in.)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1211: error: ‘X86_TRAP_MF’ 
undeclared (first use in this function)
/home/jkacur/linux-rt/drivers/misc/sgi-xp/xpc_main.c:1212: error: ‘X86_TRAP_XF’ 
undeclared (first use in this function)
make[4]: *** [drivers/misc/sgi-xp/xpc_main.o] Error 1
make[3]: *** [drivers/misc/sgi-xp] Error 2
make[2]: *** [drivers/misc] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

Conflicts:
arch/x86/kernel/traps.c
Signed-off-by: John Kacur jka...@redhat.com
---
 arch/x86/include/asm/traps.h |   25 +
 arch/x86/kernel/irqinit.c|2 +-
 arch/x86/kernel/traps.c  |  120 ++---
 3 files changed, 90 insertions(+), 57 deletions(-)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 0012d09..88eae2a 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -89,4 +89,29 @@ asmlinkage void smp_thermal_interrupt(void);
 asmlinkage void mce_threshold_interrupt(void);
 #endif
 
+/* Interrupts/Exceptions */
+enum {
+   X86_TRAP_DE = 0,/*  0, Divide-by-zero */
+   X86_TRAP_DB,/*  1, Debug */
+   X86_TRAP_NMI,   /*  2, Non-maskable Interrupt */
+   X86_TRAP_BP,/*  3, Breakpoint */
+   X86_TRAP_OF,/*  4, Overflow */
+   X86_TRAP_BR,/*  5, Bound Range Exceeded */
+   X86_TRAP_UD,/*  6, Invalid Opcode */
+   X86_TRAP_NM,/*  7, Device Not Available */
+   X86_TRAP_DF,/*  8, Double Fault */
+   X86_TRAP_OLD_MF,/*  9, Coprocessor Segment Overrun */
+   X86_TRAP_TS,/* 10, Invalid TSS */
+   X86_TRAP_NP,/* 11, Segment Not Present */
+   X86_TRAP_SS,/* 12, Stack Segment Fault */
+   X86_TRAP_GP,/* 13, General Protection Fault */
+   X86_TRAP_PF,/* 14, Page Fault */
+   X86_TRAP_SPURIOUS,  /* 15, Spurious Interrupt */
+   X86_TRAP_MF,/* 16, x87 Floating-Point Exception */
+   X86_TRAP_AC,/* 17, Alignment Check */
+   X86_TRAP_MC,/* 18, Machine Check */
+   X86_TRAP_XF,/* 19, SIMD Floating-Point Exception */
+   X86_TRAP_IRET = 32, /* 32, IRET Exception */
+};
+
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index b3300e6..e328f69 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -61,7 +61,7 @@ static irqreturn_t math_error_irq(int cpl, void *dev_id)
outb(0, 0xF0);
if (ignore_fpu_irq || !boot_cpu_data.hard_math)
return IRQ_NONE;
-   math_error(get_irq_regs(), 0, 16);
+   math_error(get_irq_regs(), 0, X86_TRAP_MF);
return IRQ_HANDLED;
 }
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 31d9d0f..e6fbb94 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -119,7 +119,7 @@ do_trap(int trapnr, int signr, char *str, struct pt_regs 
*regs,
 * traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
 * On nmi (interrupt 2), do_trap should not be called.
 */
-   if (trapnr  6)
+   if (trapnr  X86_TRAP_UD)
goto vm86_trap;
goto trap_signal;
}
@@ -203,27 +203,31 @@ dotraplinkage void do_##name(struct pt_regs *regs, long 
error_code)   \
do_trap(trapnr, signr, str, regs, error_code, info);   \
 }
 
-DO_ERROR_INFO(0, SIGFPE, divide error, divide_error

[BUG RT] v3.6.11-rt25: BUG unable to handle kernel NULL pointer dereference

[John Kacur]

Hello

Our test systems are getting the following type of BUGs on v3.6.11-rt25 kernels

Test 1:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] kmem_cache_alloc_node+0x51/0x180
PGD a2d39067 PUD b1641067 PMD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: sunrpc cpufreq_ondemand ipv6 tg3 joydev sg
serio_raw pcspkr k8temp amd64_edac_mod edac_core i2c_piix4 e100 mii
shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom sata_svw
ata_generic pata_acpi pata_serverworks radeon ttm drm_kms_helper drm
hwmon i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
CPU 3
Pid: 20878, comm: hackbench Not tainted 3.6.11-rt25.14.el6rt.x86_64 #1
empty empty/Tyan Transport GT24-B3992
RIP: 0010:[]  []
kmem_cache_alloc_node+0x51/0x180
RSP: 0018:8800a9b17d70  EFLAGS: 00010213
RAX:  RBX: 01200011 RCX: 8800a06d8000
RDX: 04d92a03 RSI: 00d0 RDI: 88013b805500
RBP: 8800a9b17dc0 R08: 88023fd14d10 R09: 81041cbd
R10: 7f4e3f06e9d0 R11: 0246 R12: 88013b805500
R13: 8801ff46af40 R14: 0001 R15: 
FS:  7f4e3f06e700() GS:88023fd0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2:  CR3: a2d3a000 CR4: 07e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process hackbench (pid: 20878, threadinfo 8800a9b16000, task
8800a06d8000)
Stack:
 8800a9b17da0 81202e08 8800a9b17de0 00d001200011
 01200011 01200011  
 7f4e3f06e9d0  8800a9b17e60 81041cbd
Call Trace:
 [] ? current_has_perm+0x68/0x80
 [] copy_process+0xdd/0x15b0
 [] ? rt_up_read+0x25/0x30
 [] do_fork+0x5a/0x360
 [] ? migrate_enable+0xeb/0x220
 [] sys_clone+0x28/0x30
 [] stub_clone+0x13/0x20
 [] ? system_call_fastpath+0x16/0x1b
Code: 89 fc 89 75 cc 41 89 d6 4d 8b 04 24 65 4c 03 04 25 48 ae 00 00
49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 74 12 41 83 fe ff 74 27 <48>
8b 00 48 c1 e8 3a 41 39 c6 74 1b 8b 75 cc 4c 89 c9 44 89 f2
RIP  [] kmem_cache_alloc_node+0x51/0x180
 RSP 
CR2: 
---[ end trace 0002 ]---



Test 2:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] kmem_cache_alloc_node+0x51/0x180
PGD 1d9a31067 PUD 223b24067 PMD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: sunrpc cpufreq_ondemand ipv6 tg3 serio_raw pcspkr
k8temp amd64_edac_mod edac_core joydev sg e100 mii i2c_piix4 shpchp
ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom sata_svw ata_generic
pata_acpi pata_serverworks radeon ttm drm_kms_helper drm hwmon
i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
CPU 1
Pid: 26603, comm: hackbench Not tainted 3.6.11-rt25.14.el6rt.x86_64 #1
empty empty/Tyan Transport GT24-B3992
RIP: 0010:[]  []
kmem_cache_alloc_node+0x51/0x180
RSP: 0018:880093bdbd70  EFLAGS: 00010213
RAX:  RBX: 01200011 RCX: 8800a1edde80
RDX: 1a29dd01 RSI: 00d0 RDI: 88013b805500
RBP: 880093bdbdc0 R08: 88013bd14d10 R09: 81041cbd
R10: 7fcaec20e9d0 R11: 0246 R12: 88013b805500
R13: 8800abe95e80 R14:  R15: 
FS:  7fcaec20e700() GS:88013bd0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2:  CR3: 000223c2d000 CR4: 07e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process hackbench (pid: 26603, threadinfo 880093bda000, task
8800a1edde80)
Stack:
 880093bdbda0 81202e08 880081568690 00d001200011
 01200011 01200011  
 7fcaec20e9d0  880093bdbe60 81041cbd
Call Trace:
 [] ? current_has_perm+0x68/0x80
 [] copy_process+0xdd/0x15b0
 [] ? selinux_file_alloc_security+0x4b/0x80
 [] do_fork+0x5a/0x360
 [] ? migrate_enable+0xeb/0x220
 [] sys_clone+0x28/0x30
 [] stub_clone+0x13/0x20
 [] ? system_call_fastpath+0x16/0x1b
Code: 89 fc 89 75 cc 41 89 d6 4d 8b 04 24 65 4c 03 04 25 48 ae 00 00
49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 74 12 41 83 fe ff 74 27 <48>
8b 00 48 c1 e8 3a 41 39 c6 74 1b 8b 75 cc 4c 89 c9 44 89 f2
RIP  [] kmem_cache_alloc_node+0x51/0x180
 RSP 
CR2: 
---[ end trace 0002 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG RT] v3.6.11-rt25: BUG unable to handle kernel NULL pointer dereference

[John Kacur]

Hello

Our test systems are getting the following type of BUGs on v3.6.11-rt25 kernels

Test 1:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [811573f1] kmem_cache_alloc_node+0x51/0x180
PGD a2d39067 PUD b1641067 PMD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: sunrpc cpufreq_ondemand ipv6 tg3 joydev sg
serio_raw pcspkr k8temp amd64_edac_mod edac_core i2c_piix4 e100 mii
shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom sata_svw
ata_generic pata_acpi pata_serverworks radeon ttm drm_kms_helper drm
hwmon i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
CPU 3
Pid: 20878, comm: hackbench Not tainted 3.6.11-rt25.14.el6rt.x86_64 #1
empty empty/Tyan Transport GT24-B3992
RIP: 0010:[811573f1]  [811573f1]
kmem_cache_alloc_node+0x51/0x180
RSP: 0018:8800a9b17d70  EFLAGS: 00010213
RAX:  RBX: 01200011 RCX: 8800a06d8000
RDX: 04d92a03 RSI: 00d0 RDI: 88013b805500
RBP: 8800a9b17dc0 R08: 88023fd14d10 R09: 81041cbd
R10: 7f4e3f06e9d0 R11: 0246 R12: 88013b805500
R13: 8801ff46af40 R14: 0001 R15: 
FS:  7f4e3f06e700() GS:88023fd0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2:  CR3: a2d3a000 CR4: 07e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process hackbench (pid: 20878, threadinfo 8800a9b16000, task
8800a06d8000)
Stack:
 8800a9b17da0 81202e08 8800a9b17de0 00d001200011
 01200011 01200011  
 7f4e3f06e9d0  8800a9b17e60 81041cbd
Call Trace:
 [81202e08] ? current_has_perm+0x68/0x80
 [81041cbd] copy_process+0xdd/0x15b0
 [810a2125] ? rt_up_read+0x25/0x30
 [8104369a] do_fork+0x5a/0x360
 [8107c66b] ? migrate_enable+0xeb/0x220
 [8100b068] sys_clone+0x28/0x30
 [81527423] stub_clone+0x13/0x20
 [81527152] ? system_call_fastpath+0x16/0x1b
Code: 89 fc 89 75 cc 41 89 d6 4d 8b 04 24 65 4c 03 04 25 48 ae 00 00
49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 74 12 41 83 fe ff 74 27 48
8b 00 48 c1 e8 3a 41 39 c6 74 1b 8b 75 cc 4c 89 c9 44 89 f2
RIP  [811573f1] kmem_cache_alloc_node+0x51/0x180
 RSP 8800a9b17d70
CR2: 
---[ end trace 0002 ]---



Test 2:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [811573f1] kmem_cache_alloc_node+0x51/0x180
PGD 1d9a31067 PUD 223b24067 PMD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: sunrpc cpufreq_ondemand ipv6 tg3 serio_raw pcspkr
k8temp amd64_edac_mod edac_core joydev sg e100 mii i2c_piix4 shpchp
ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom sata_svw ata_generic
pata_acpi pata_serverworks radeon ttm drm_kms_helper drm hwmon
i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
CPU 1
Pid: 26603, comm: hackbench Not tainted 3.6.11-rt25.14.el6rt.x86_64 #1
empty empty/Tyan Transport GT24-B3992
RIP: 0010:[811573f1]  [811573f1]
kmem_cache_alloc_node+0x51/0x180
RSP: 0018:880093bdbd70  EFLAGS: 00010213
RAX:  RBX: 01200011 RCX: 8800a1edde80
RDX: 1a29dd01 RSI: 00d0 RDI: 88013b805500
RBP: 880093bdbdc0 R08: 88013bd14d10 R09: 81041cbd
R10: 7fcaec20e9d0 R11: 0246 R12: 88013b805500
R13: 8800abe95e80 R14:  R15: 
FS:  7fcaec20e700() GS:88013bd0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2:  CR3: 000223c2d000 CR4: 07e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process hackbench (pid: 26603, threadinfo 880093bda000, task
8800a1edde80)
Stack:
 880093bdbda0 81202e08 880081568690 00d001200011
 01200011 01200011  
 7fcaec20e9d0  880093bdbe60 81041cbd
Call Trace:
 [81202e08] ? current_has_perm+0x68/0x80
 [81041cbd] copy_process+0xdd/0x15b0
 [812069bb] ? selinux_file_alloc_security+0x4b/0x80
 [8104369a] do_fork+0x5a/0x360
 [8107c66b] ? migrate_enable+0xeb/0x220
 [8100b068] sys_clone+0x28/0x30
 [81527423] stub_clone+0x13/0x20
 [81527152] ? system_call_fastpath+0x16/0x1b
Code: 89 fc 89 75 cc 41 89 d6 4d 8b 04 24 65 4c 03 04 25 48 ae 00 00
49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 74 12 41 83 fe ff 74 27 48
8b 00 48 c1 e8 3a 41 39 c6 74 1b 8b 75 cc 4c 89 c9 44 89 f2
RIP  [811573f1] kmem_cache_alloc_node+0x51/0x180
 RSP 880093bdbd70
CR2: 
---[ end trace 0002 ]---
--
To unsubscribe from this 

Re: [PATCH 01/13] HW-latency: hardware latency test 0.10

[John Kacur]

On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu  wrote:
>
> This patch is the first step to test some basic hardware functions like
> TSC to help people understand if there is any hardware latency as well
> as throughput problem exposed on bare metal or left behind by BIOS or
> interfered by SMI. Currently the patch tests TSC, CPU Frequency and
> RDRAND which is a new CPU instruction to get random number introduced in
> new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
> make sure testers fully control their system under test to rule out some
> level of unwanted noise.
>
> Signed-off-by: Luming Yu 
> ---
>  drivers/misc/Kconfig   |   7 +
>  drivers/misc/Makefile  |   1 +
>  drivers/misc/hw_latency_test.c | 833 
> +
>  3 files changed, 841 insertions(+)
>  create mode 100644 drivers/misc/hw_latency_test.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index b151b7c..5ed440b 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -114,6 +114,13 @@ config IBM_ASM
>   for information on the specific driver level and support statement
>   for your IBM server.
>
> +config HW_LATENCY_TEST
> +   tristate "Testing module to detect hardware lattency and throughput"
> +   depends on DEBUG_FS
> +   depends on RING_BUFFER
> +   depends on X86
> +   default m
> +
>  config PHANTOM
> tristate "Sensable PHANToM (PCI)"
> depends on PCI
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 2129377..c195cce 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -49,3 +49,4 @@ obj-y += carma/
>  obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
>  obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
>  obj-$(CONFIG_INTEL_MEI)+= mei/
> +obj-$(CONFIG_HW_LATENCY_TEST)  += hw_latency_test.o
> diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
> new file mode 100644
> index 000..2aa3a74
> --- /dev/null
> +++ b/drivers/misc/hw_latency_test.c
> @@ -0,0 +1,833 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BUF_SIZE_DEFAULT   262144UL
> +#define BUF_FLAGS  (RB_FL_OVERWRITE)
> +#defineU64STR_SIZE 22
> +#define DEBUGFS_BUF_SIZE   1024
> +#define DEBUGFS_NAME_SIZE  32
> +
> +#defineVERSION "0.1.0"
> +#define BANNER "hardware latency test"
> +#define DRVNAME"hw_latency_test"
> +
> +#define DEFAULT_SAMPLE_WINDOW  100
> +#defineDEFAULT_SAMPLE_WIDTH50
> +#defineDEFAULT_LAT_THRESHOLD   10
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Luming Yu ");
> +MODULE_DESCRIPTION("A simple hardware latency test");
> +MODULE_VERSION(VERSION);


>o SNIP

Ok, hopefully this is just an unintentional oversight - but I don't
see where you are acknowledging that the original author of most of
this code is Jon Masters. It's fine for you to work on it, but you
have to somewhere acknowledge where it comes from.

Thanks

John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/