* Operation not permitted / pthread_setschedparam
@ 2014-09-30 10:40 Armin Steinhoff
2014-09-30 11:44 ` Harry van Haaren
2014-09-30 23:09 ` Thomas Gleixner
0 siblings, 2 replies; 27+ messages in thread
From: Armin Steinhoff @ 2014-09-30 10:40 UTC (permalink / raw)
To: rt-users
Hi,
a "pthread_setschedparam" call of the code below terminates with an
errno == 1 ... means "Operation not permitted"
instance_l.fStopThread = FALSE;
if (pthread_create(&instance_l.threadId, NULL, eventThread,
(void*)&instance_l) != 0)
goto Exit;
schedParam.__sched_priority = KERNEL_EVENT_THREAD_PRIORITY;
if (pthread_setschedparam(instance_l.threadId, SCHED_FIFO,
&schedParam) != 0)
{
DEBUG_LVL_ERROR_TRACE("%s(): couldn't set thread scheduling
parameters! %d\n", __func__, errno);
}
I'm using a PREEMPT_RT kernel 3.4.0-rc7-rt7-2.16 for SuSE 12.2
Milestone 2 (3.4.11-2.16).
KERNEL_EVENT_THREAD_PRIORITY is 55!
How to solve that problem ?
Best Regards
--Armin
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: Operation not permitted / pthread_setschedparam 2014-09-30 10:40 Operation not permitted / pthread_setschedparam Armin Steinhoff @ 2014-09-30 11:44 ` Harry van Haaren 2014-09-30 12:32 ` Armin Steinhoff 2014-09-30 23:09 ` Thomas Gleixner 1 sibling, 1 reply; 27+ messages in thread From: Harry van Haaren @ 2014-09-30 11:44 UTC (permalink / raw) To: Armin Steinhoff; +Cc: rt-users On Tue, Sep 30, 2014 at 11:40 AM, Armin Steinhoff <armin@steinhoff.de> wrote: > a "pthread_setschedparam" call of the code below terminates with an > errno == 1 ... means "Operation not permitted" At risk of asking the obvious: are you running as root, or does the user running this code have RT priorities? User priorities controlled by /etc/security/limits.conf : you can set a groups max-rtprio like so: @audio - rtprio 65 > KERNEL_EVENT_THREAD_PRIORITY is 55! > How to solve that problem ? Anything above 50 requrires changing limits.conf or root IIRC. HTH, -Harry -- www.openavproductions.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-09-30 11:44 ` Harry van Haaren @ 2014-09-30 12:32 ` Armin Steinhoff 2014-09-30 17:22 ` Armin Steinhoff 0 siblings, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-09-30 12:32 UTC (permalink / raw) To: Harry van Haaren; +Cc: rt-users Harry, I'm running as root. The same code works w/o problem with the normal (non RT) kernel. "chrt -m" shows 1/99 for SCHED_FIFO. I did also add @root - rtprio 99 to limits.conf ... no success, as expected. --Armin Harry van Haaren schrieb: > On Tue, Sep 30, 2014 at 11:40 AM, Armin Steinhoff <armin@steinhoff.de> wrote: >> a "pthread_setschedparam" call of the code below terminates with an >> errno == 1 ... means "Operation not permitted" > At risk of asking the obvious: are you running as root, or does the > user running this code have RT priorities? > > User priorities controlled by /etc/security/limits.conf : you can set > a groups max-rtprio like so: > @audio - rtprio 65 > >> KERNEL_EVENT_THREAD_PRIORITY is 55! >> How to solve that problem ? > Anything above 50 requrires changing limits.conf or root IIRC. > > HTH, -Harry > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-09-30 12:32 ` Armin Steinhoff @ 2014-09-30 17:22 ` Armin Steinhoff 0 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-09-30 17:22 UTC (permalink / raw) To: rt-users Hi, pthread_setschedparam seems to be broken in my PREEMPT_RT version !! The pthread_attr_ interface is working ... Any comments ?? cheers --Armin Armin Steinhoff schrieb: > Harry, > > I'm running as root. The same code works w/o problem with the normal > (non RT) kernel. > "chrt -m" shows 1/99 for SCHED_FIFO. I did also add @root - rtprio 99 > to limits.conf ... no success, as expected. > > --Armin > > Harry van Haaren schrieb: >> On Tue, Sep 30, 2014 at 11:40 AM, Armin Steinhoff <armin@steinhoff.de> wrote: >>> a "pthread_setschedparam" call of the code below terminates with an >>> errno == 1 ... means "Operation not permitted" >> At risk of asking the obvious: are you running as root, or does the >> user running this code have RT priorities? >> >> User priorities controlled by /etc/security/limits.conf : you can set >> a groups max-rtprio like so: >> @audio - rtprio 65 >> >>> KERNEL_EVENT_THREAD_PRIORITY is 55! >>> How to solve that problem ? >> Anything above 50 requrires changing limits.conf or root IIRC. >> >> HTH, -Harry >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-09-30 10:40 Operation not permitted / pthread_setschedparam Armin Steinhoff 2014-09-30 11:44 ` Harry van Haaren @ 2014-09-30 23:09 ` Thomas Gleixner 2014-10-01 7:27 ` Armin Steinhoff 1 sibling, 1 reply; 27+ messages in thread From: Thomas Gleixner @ 2014-09-30 23:09 UTC (permalink / raw) To: Armin Steinhoff; +Cc: rt-users On Tue, 30 Sep 2014, Armin Steinhoff wrote: > a "pthread_setschedparam" call of the code below terminates with an > errno == 1 ... means "Operation not permitted" ... > I'm using a PREEMPT_RT kernel 3.4.0-rc7-rt7-2.16 for SuSE 12.2 > Milestone 2 (3.4.11-2.16). > > How to solve that problem ? Hint #1: 3.4.0-rc7-rt7-2.16 Hint #2: linux/REPORTING-BUGS Hint #3: Start over at Hint #1 Thanks, tglx ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-09-30 23:09 ` Thomas Gleixner @ 2014-10-01 7:27 ` Armin Steinhoff 2014-10-01 7:49 ` Patrik Lundquist 0 siblings, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-10-01 7:27 UTC (permalink / raw) To: Thomas Gleixner; +Cc: rt-users Thomas Gleixner schrieb: > On Tue, 30 Sep 2014, Armin Steinhoff wrote: >> a "pthread_setschedparam" call of the code below terminates with an >> errno == 1 ... means "Operation not permitted" > ... >> I'm using a PREEMPT_RT kernel 3.4.0-rc7-rt7-2.16 for SuSE 12.2 >> Milestone 2 (3.4.11-2.16). >> >> How to solve that problem ? > Hint #1: 3.4.0-rc7-rt7-2.16 I'm using the vanilla kernel "linux-3.4-rc7.tar.gz" and the related(?) RT patch "patch-3.4-rt7.patch.xz" from "kernel.org" The suffix -2.16 seems to be a naming convention from SuSE ? The patch, recompilation and installation was working perfectly. ( Only the compilation of a 3COM adapter was broken) > > Hint #2: linux/REPORTING-BUGS OK ... still TODO Regards --Armin > > Hint #3: Start over at Hint #1 > > Thanks, > > tglx > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-01 7:27 ` Armin Steinhoff @ 2014-10-01 7:49 ` Patrik Lundquist 2014-10-02 8:02 ` Armin Steinhoff 0 siblings, 1 reply; 27+ messages in thread From: Patrik Lundquist @ 2014-10-01 7:49 UTC (permalink / raw) To: Armin Steinhoff; +Cc: rt-users On 1 October 2014 09:27, Armin Steinhoff <armin@steinhoff.de> wrote: > Thomas Gleixner schrieb: >> On Tue, 30 Sep 2014, Armin Steinhoff wrote: >>> How to solve that problem ? >> Hint #1: 3.4.0-rc7-rt7-2.16 > I'm using the vanilla kernel "linux-3.4-rc7.tar.gz" and the related(?) > RT patch "patch-3.4-rt7.patch.xz" from "kernel.org" Try linux-3.4.97.tar.xz with patch-3.4.97-rt121.patch.xz ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-01 7:49 ` Patrik Lundquist @ 2014-10-02 8:02 ` Armin Steinhoff 2014-10-04 10:49 ` Carsten Emde 0 siblings, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-10-02 8:02 UTC (permalink / raw) To: Patrik Lundquist; +Cc: rt-users [-- Attachment #1: Type: text/plain, Size: 1302 bytes --] Patrik Lundquist schrieb: > On 1 October 2014 09:27, Armin Steinhoff <armin@steinhoff.de> wrote: >> Thomas Gleixner schrieb: >>> On Tue, 30 Sep 2014, Armin Steinhoff wrote: >>>> How to solve that problem ? >>> Hint #1: 3.4.0-rc7-rt7-2.16 >> I'm using the vanilla kernel "linux-3.4-rc7.tar.gz" and the related(?) >> RT patch "patch-3.4-rt7.patch.xz" from "kernel.org" > Try linux-3.4.97.tar.xz with patch-3.4.97-rt121.patch.xz Yes, the version 3.4.97 + patch doesn't have any problems with the call "pthread_setschedparam"! Thanks a lot! I'm running the PCAP version of a MN node of openPOWERLINK. This app is a plain userspace app ... it starts on core 0 and core 2 several threads which are using different RT priorities. ( core 1 "not used" in that case) But there are some sideeffects to other running processes/threads related to their assigned priorities. Here is the priority assignment after a fresh boot: ps -elf -> Prio-After-OS-Restart.txt attached If the app "demo_mn_console" has started its first RT thread, a lot of other processes/threads are jumping to the highest RT priority 99!! Please have a look to: ps -elf -> Prio-after-app-start.txt Do we have a problem with the RT kernel ? Or is simply the ps utility broken ? Best Regards --Armin [-- Attachment #2: Prio-After-OS-boot.txt --] [-- Type: text/plain, Size: 20677 bytes --] LINUX4C:/home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux # ps -elf F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S root 1 0 0 80 0 - 10919 ep_pol 23:40 ? 00:00:01 /sbin/init showopts x11failsafe 1 S root 2 0 0 80 0 - 0 kthrea 23:40 ? 00:00:00 [kthreadd] 5 S root 3 2 0 58 - - 0 run_ks 23:40 ? 00:00:01 [ksoftirqd/0] 1 S root 4 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/0:0] 1 S root 5 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:0] 1 S root 6 2 0 -40 - - 0 posix_ 23:40 ? 00:00:00 [posixcputmr/0] 1 S root 7 2 0 80 0 - 0 run_cm 23:40 ? 00:00:00 [kcmosdelayd] 1 S root 8 2 0 -40 - - 0 cpu_st 23:40 ? 00:00:00 [migration/0] 1 S root 9 2 0 58 - - 0 rcu_cp 23:40 ? 00:00:00 [rcuc/0] 1 S root 10 2 0 -40 - - 0 rcu_no 23:40 ? 00:00:00 [rcun/0] 1 S root 11 2 0 58 - - 0 rcu_bo 23:40 ? 00:00:00 [rcub/0] 1 S root 12 2 0 -40 - - 0 rcu_no 23:40 ? 00:00:00 [rcun/1] 1 S root 13 2 0 58 - - 0 rcu_bo 23:40 ? 00:00:00 [rcub/1] 1 S root 14 2 0 -40 - - 0 watchd 23:40 ? 00:00:00 [watchdog/0] 1 S root 15 2 0 -40 - - 0 posix_ 23:40 ? 00:00:00 [posixcputmr/1] 1 S root 16 2 0 -40 - - 0 cpu_st 23:40 ? 00:00:00 [migration/1] 1 S root 17 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/1:0] 1 S root 18 2 0 58 - - 0 rcu_cp 23:40 ? 00:00:00 [rcuc/1] 5 S root 19 2 0 58 - - 0 run_ks 23:40 ? 00:00:01 [ksoftirqd/1] 1 S root 20 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/0:1] 1 S root 21 2 0 -40 - - 0 watchd 23:40 ? 00:00:00 [watchdog/1] 1 S root 22 2 0 -40 - - 0 posix_ 23:40 ? 00:00:00 [posixcputmr/2] 1 S root 23 2 0 -40 - - 0 cpu_st 23:40 ? 00:00:00 [migration/2] 1 S root 24 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/2:0] 1 S root 25 2 0 58 - - 0 rcu_cp 23:40 ? 00:00:00 [rcuc/2] 5 S root 26 2 0 58 - - 0 run_ks 23:40 ? 00:00:01 [ksoftirqd/2] 1 S root 27 2 0 -40 - - 0 watchd 23:40 ? 00:00:00 [watchdog/2] 1 S root 28 2 0 -40 - - 0 posix_ 23:40 ? 00:00:00 [posixcputmr/3] 1 S root 29 2 0 -40 - - 0 cpu_st 23:40 ? 00:00:00 [migration/3] 1 S root 30 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/3:0] 1 S root 31 2 0 58 - - 0 rcu_cp 23:40 ? 00:00:00 [rcuc/3] 5 S root 32 2 0 58 - - 0 run_ks 23:40 ? 00:00:01 [ksoftirqd/3] 1 S root 33 2 0 -40 - - 0 watchd 23:40 ? 00:00:00 [watchdog/3] 1 S root 34 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [cpuset] 1 S root 35 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [khelper] 5 S root 36 2 0 80 0 - 0 devtmp 23:40 ? 00:00:00 [kdevtmpfs] 1 S root 37 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [netns] 1 S root 38 2 0 80 0 - 0 bdi_sy 23:40 ? 00:00:00 [sync_supers] 1 S root 39 2 0 80 0 - 0 bdi_fo 23:40 ? 00:00:00 [bdi-default] 1 S root 40 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [kintegrityd] 1 S root 41 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [crypto] 1 S root 42 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [kblockd] 1 S root 43 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/9-acpi] 1 S root 44 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [ata_sff] 1 S root 45 2 0 80 0 - 0 hub_th 23:40 ? 00:00:00 [khubd] 1 S root 46 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [md] 1 S root 47 2 0 80 0 - 0 mce_no 23:40 ? 00:00:00 [mce-notify] 1 S root 48 2 0 80 0 - 0 watchd 23:40 ? 00:00:00 [khungtaskd] 1 S root 49 2 0 80 0 - 0 kswapd 23:40 ? 00:00:00 [kswapd0] 1 S root 50 2 0 85 5 - 0 ksm_sc 23:40 ? 00:00:00 [ksmd] 1 S root 51 2 0 80 0 - 0 fsnoti 23:40 ? 00:00:00 [fsnotify_mark] 1 S root 55 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [kthrotld] 1 S root 56 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/40-PCIe PME] 1 S root 57 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/41-PCIe PME] 1 S root 58 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/42-ahci] 1 S root 59 2 0 80 0 - 0 scsi_e 23:40 ? 00:00:00 [scsi_eh_0] 1 S root 60 2 0 80 0 - 0 scsi_e 23:40 ? 00:00:00 [scsi_eh_1] 1 S root 61 2 0 80 0 - 0 scsi_e 23:40 ? 00:00:00 [scsi_eh_2] 1 S root 62 2 0 80 0 - 0 scsi_e 23:40 ? 00:00:00 [scsi_eh_3] 1 S root 63 2 0 80 0 - 0 scsi_e 23:40 ? 00:00:00 [scsi_eh_4] 1 S root 64 2 0 80 0 - 0 scsi_e 23:40 ? 00:00:00 [scsi_eh_5] 1 S root 65 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:1] 1 S root 66 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:2] 1 S root 67 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:3] 1 S root 68 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:4] 1 S root 69 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:5] 1 S root 70 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:6] 1 S root 71 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/16-ehci_hcd] 1 S root 72 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/23-ehci_hcd] 1 S root 73 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/1-i8042] 1 S root 74 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [kpsmoused] 1 S root 75 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/0:2] 1 S root 76 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/8-rtc0] 1 S root 77 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/u:7] 1 S root 78 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/2:1] 1 S root 79 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/1:1] 1 S root 80 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [deferwq] 1 S root 81 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/3:1] 1 S root 137 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [kmpath_rdacd] 1 S root 174 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/43-i915] 1 S root 175 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/3:2] 1 S root 176 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/1:2] 1 S root 238 2 0 80 0 - 0 kjourn 23:40 ? 00:00:00 [jbd2/sda6-8] 1 S root 239 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [ext4-dio-unwrit] 1 S root 246 2 0 80 0 - 0 bdi_wr 23:40 ? 00:00:00 [flush-8:0] 4 S root 292 1 0 80 0 - 9019 ep_pol 23:40 ? 00:00:00 /lib/systemd/systemd-journald 1 S root 294 2 0 80 0 - 0 kaudit 23:40 ? 00:00:00 [kauditd] 4 S root 314 1 0 80 0 - 8480 ep_pol 23:40 ? 00:00:00 /lib/udev/udevd 1 S root 325 2 0 80 0 - 0 worker 23:40 ? 00:00:00 [kworker/2:2] 5 S root 384 314 0 80 0 - 8486 ep_pol 23:40 ? 00:00:00 /lib/udev/udevd 5 S root 385 314 0 80 0 - 8457 ep_pol 23:40 ? 00:00:00 /lib/udev/udevd 1 S root 429 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/44-mei] 1 S root 432 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/5-parport0] 1 S root 450 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/46-snd_hda_] 1 S root 453 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [hd-audio0] 1 S root 502 2 0 80 0 - 0 kjourn 23:40 ? 00:00:00 [jbd2/sda7-8] 1 S root 503 2 0 60 -20 - 0 rescue 23:40 ? 00:00:00 [ext4-dio-unwrit] 4 S root 537 1 0 80 0 - 2130 poll_s 23:40 ? 00:00:00 /usr/sbin/haveged -F 1 -w 1024 -v 0 4 S root 545 1 0 80 0 - 15663 ep_pol 23:40 ? 00:00:00 /usr/sbin/cupsd -f 4 S avahi 548 1 0 80 0 - 7531 poll_s 23:40 ? 00:00:00 avahi-daemon: running [LINUX4C.local] 4 S root 551 1 0 80 0 - 4199 poll_s 23:40 ? 00:00:00 /usr/sbin/nscd -d 5 S root 556 1 0 80 0 - 5297 hrtime 23:40 ? 00:00:00 /usr/sbin/irqbalance 4 S root 558 1 0 80 0 - 5272 poll_s 23:40 ? 00:00:00 /sbin/rpcbind -w -f 4 S root 561 1 0 80 0 - 6520 ep_pol 23:40 ? 00:00:00 /lib/systemd/systemd-logind 5 S root 601 1 0 80 0 - 62804 poll_s 23:40 ? 00:00:00 /sbin/rsyslogd -c 5 -f /etc/rsyslog.conf 1 S root 607 1 0 80 0 - 5490 poll_s 23:40 ? 00:00:00 /usr/bin/vmware-usbarbitrator 1 S root 608 1 0 80 0 - 1054 poll_s 23:40 ? 00:00:00 /usr/sbin/acpid 4 S root 611 1 0 80 0 - 4891 hrtime 23:40 ? 00:00:00 /usr/sbin/smartd -n 4 S 100 612 1 0 80 0 - 5107 ep_pol 23:40 ? 00:00:00 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 5 S root 635 1 0 76 -4 - 4956 ep_pol 23:40 ? 00:00:00 /sbin/auditd -s disable 1 S root 1128 2 0 9 - - 0 irq_th 23:40 ? 00:00:00 [irq/45-eth0] 5 S root 1259 1 0 80 0 - 2133 poll_s 23:40 ? 00:00:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.init.pid 1 S root 1407 1 0 80 0 - 29324 futex_ 23:40 ? 00:00:00 /usr/lib/vmware/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse 5 S root 1442 1 0 80 0 - 5402 poll_s 23:40 ? 00:00:00 /usr/sbin/vmware-authdlauncher 5 S root 1581 1 0 80 0 - 53082 poll_s 23:40 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 4 S wwwrun 1608 1 0 80 0 - 81042 futex_ 23:40 ? 00:00:00 /usr/bin/mono /usr/lib/mono/2.0/mod-mono-server2.exe --filename /tmp/mod_mono_server_global --nonstop --master 5 S wwwrun 1614 1581 0 80 0 - 53090 inet_c 23:40 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1615 1581 0 80 0 - 53090 inet_c 23:40 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1617 1581 0 80 0 - 53090 inet_c 23:40 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1618 1581 0 80 0 - 53090 inet_c 23:40 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1619 1581 0 80 0 - 53090 inet_c 23:40 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 4 S root 1666 1 0 80 0 - 1051 n_tty_ 23:40 tty1 00:00:00 /sbin/agetty tty1 38400 5 S ntp 1939 1 0 80 0 - 6199 poll_s 23:40 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf 5 S root 2001 1 0 80 0 - 7232 poll_s 23:40 ? 00:00:00 /usr/bin/kdm 4 S root 2019 2001 1 80 0 - 65270 poll_s 23:40 tty7 00:00:04 /usr/bin/Xorg -br :0 vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-5Zyuub 4 S root 2066 1 0 80 0 - 5199 ep_pol 23:40 ? 00:00:00 /usr/lib/postfix/master 4 S postfix 2082 2066 0 80 0 - 5191 ep_pol 23:40 ? 00:00:00 pickup -l -t fifo -u 4 S postfix 2083 2066 0 80 0 - 5253 ep_pol 23:40 ? 00:00:00 qmgr -l -t fifo -u 5 S root 2099 2001 0 80 0 - 18786 rt_sig 23:40 ? 00:00:00 -:0 4 S root 2115 1 0 80 0 - 522895 poll_s 23:40 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon 4 S root 2180 1 0 80 0 - 50026 poll_s 23:40 ? 00:00:00 /usr/lib/polkit-1/polkitd --no-debug 4 S root 2194 2099 0 80 0 - 2939 wait 23:40 ? 00:00:00 /bin/sh /usr/bin/startkde 1 S root 2263 2194 0 80 0 - 3417 poll_s 23:40 ? 00:00:00 /usr/bin/gpg-agent --sh --daemon --write-env-file /root/.gnupg/agent.info /usr/bin/ssh-agent /etc/X11/xinit/xinitrc 1 S root 2264 2194 0 80 0 - 3071 poll_s 23:40 ? 00:00:00 /usr/bin/ssh-agent /etc/X11/xinit/xinitrc 1 S root 2305 1 0 80 0 - 3972 poll_s 23:40 ? 00:00:00 dbus-launch --sh-syntax --exit-with-session 5 S root 2306 1 0 80 0 - 5206 ep_pol 23:40 ? 00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 1 S root 2313 1 0 80 0 - 1011 pipe_w 23:40 ? 00:00:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup 1 S root 2314 1 0 80 0 - 77118 poll_s 23:40 ? 00:00:00 kdeinit4: kdeinit4 Running... 1 S root 2315 2314 0 80 0 - 78180 poll_s 23:41 ? 00:00:00 kdeinit4: klauncher [kdeinit] --fd=9 5 S root 2317 1 0 80 0 - 184593 poll_s 23:41 ? 00:00:00 kdeinit4: kded4 [kdeinit] 1 S root 2321 1 0 80 0 - 97803 poll_s 23:41 ? 00:00:00 kdeinit4: kglobalaccel [kdeinit] 1 S root 2325 1 0 80 0 - 62127 poll_s 23:41 ? 00:00:00 /usr/bin/kactivitymanagerd 4 S root 2327 1 0 80 0 - 59344 poll_s 23:41 ? 00:00:00 /usr/lib/upower/upowerd 0 S root 2328 2194 0 80 0 - 1045 unix_s 23:41 ? 00:00:00 kwrapper4 ksmserver 1 S root 2332 2314 0 80 0 - 116590 poll_s 23:41 ? 00:00:00 kdeinit4: ksmserver [kdeinit] 0 S root 2367 2332 0 80 0 - 126414 poll_s 23:41 ? 00:00:00 kwin -session 10a47d9155000137310114000000024450000_1412199561_893484 4 S root 2391 1 0 80 0 - 48371 poll_s 23:41 ? 00:00:01 /usr/lib/udisks/udisks-daemon 1 S root 2393 2391 0 80 0 - 11383 poll_s 23:41 ? 00:00:00 udisks-daemon: not polling any devices 5 S root 2411 1 0 80 0 - 235303 poll_s 23:41 ? 00:00:00 /usr/bin/knotify4 5 S root 2426 1 1 80 0 - 227151 poll_s 23:41 ? 00:00:02 kdeinit4: plasma-desktop [kdeinit] 1 S root 2431 1 0 80 0 - 61738 poll_s 23:41 ? 00:00:00 /usr/bin/kuiserver 1 S root 2463 1 0 80 0 - 97573 poll_s 23:41 ? 00:00:00 kdeinit4: kaccess [kdeinit] 1 S root 2471 1 0 80 0 - 172873 poll_s 23:41 ? 00:00:00 kdeinit4: krunner [kdeinit] 1 S root 2472 2314 0 80 0 - 99539 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 1011dc9d2e6000134588144200000030560010_1412199561_885901 1 S root 2473 2314 0 80 0 - 99539 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000136075139200000021620012_1412199561_886003 1 S root 2474 2314 0 80 0 - 99539 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000136075139200000021620013_1412199561_886006 1 S root 2475 2314 0 80 0 - 99539 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000136075139200000021620014_1412199561_886012 0 S root 2476 2314 0 80 0 - 89209 poll_s 23:41 ? 00:00:00 kres-migrator -session 10a47d9155000139300665600000025640068_1412199561_886056 1 S root 2483 1 0 80 0 - 111217 poll_s 23:41 ? 00:00:00 /usr/bin/kopete -session 10a47d9155000139308385800000035730047_1412199561_886064 5 S root 2494 1 0 80 0 - 107494 poll_s 23:41 ? 00:00:00 /usr/bin/kget -session 10a47d9155000139809448100000050170028_1412199561_886115 5 S root 2510 1 0 80 0 - 103705 poll_s 23:41 ? 00:00:00 /usr/bin/ktorrent -session 10a47d9155000139962581600000025140021_1412199561_886125 1 S root 2512 1 0 80 0 - 118387 poll_s 23:41 ? 00:00:00 kdeinit4: kmix [kdeinit] -session 10a47d9155000140188735700000025220006_1412199561_886181 0 S root 2514 2314 0 80 0 - 59233 poll_s 23:41 ? 00:00:00 /usr/bin/qasmixer -session 10a47d9155000140188752900000025220009_1412199561_886232 1 S root 2515 2314 0 80 0 - 99539 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140713760500000024000021_1412199561_886235 1 S root 2516 2314 0 80 0 - 99539 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140758851800000024100039_1412199561_886274 1 S root 2517 2314 0 80 0 - 99537 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140758876100000024100045_1412199561_886276 1 S root 2518 2314 0 80 0 - 99538 poll_s 23:41 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140951128800000024580009_1412199561_886283 5 S root 2525 1 0 80 0 - 341238 poll_s 23:41 ? 00:00:01 /usr/bin/amarok -session 10a47d9155000141199627500000025150040_1412199561_886536 1 S root 2538 1 0 80 0 - 83443 poll_s 23:41 ? 00:00:00 /usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1 1 S root 2584 2314 0 80 0 - 98842 poll_s 23:41 ? 00:00:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/amarokPE2525.slave-socket 1 S root 2585 2314 0 80 0 - 77686 poll_s 23:41 ? 00:00:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/amarokbZ2525.slave-socket 1 S root 2588 2314 0 80 0 - 98842 poll_s 23:41 ? 00:00:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/amarokEa2525.slave-socket 1 S root 2589 2314 0 80 0 - 77686 poll_s 23:41 ? 00:00:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/amarokqV2525.slave-socket 1 S root 2590 2314 0 80 0 - 98843 poll_s 23:41 ? 00:00:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/amarokSa2525.slave-socket 1 S root 2597 2314 1 80 0 - 131647 poll_s 23:41 ? 00:00:02 kdeinit4: konqueror [kdeinit] --silent 1 S root 2598 2314 0 80 0 - 77686 poll_s 23:41 ? 00:00:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/konquerorhZ2597.slave-socket 1 S root 2604 2314 0 80 0 - 98434 poll_s 23:41 ? 00:00:00 kdeinit4: kio_thumbnail [kdeinit] thumbnail local:/tmp/ksocket-root/klauncherMT2315.slave-socket local:/tmp/ksocket-root/konqueroruI2597.slave-socket 0 S root 2623 1 0 80 0 - 9846 poll_s 23:41 ? 00:00:00 /usr/lib/gvfs/gvfsd 4 S root 2625 1 0 80 0 - 50426 futex_ 23:41 ? 00:00:00 /usr/lib/gvfs//gvfs-fuse-daemon -f /root/.cache/gvfs 5 R root 4986 1 1 80 0 - 123513 poll_s 23:43 ? 00:00:00 kdeinit4: konsole [kdeinit] --workdir /home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux 0 S root 4988 4986 0 80 0 - 3330 wait 23:43 pts/1 00:00:00 /bin/bash 0 R root 5088 4988 0 80 0 - 1230 - 23:44 pts/1 00:00:00 ps -elf LINUX4C:/home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux # uname -a Linux LINUX4C 3.4.97-rt121-2.16-desktop #1 SMP PREEMPT RT Wed Oct 1 16:31:42 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux LINUX4C:/home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux # [-- Attachment #3: Prio-after-app-start.txt --] [-- Type: text/plain, Size: 19357 bytes --] LINUX4C:/home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux # ps -elf F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S root 1 0 0 99 19 - 10920 ep_pol 08:58 ? 00:00:01 /sbin/init showopts x11failsafe 1 S root 2 0 0 99 19 - 0 kthrea 08:58 ? 00:00:00 [kthreadd] 5 S root 3 2 0 58 - - 0 run_ks 08:58 ? 00:00:20 [ksoftirqd/0] 1 S root 6 2 0 -40 - - 0 posix_ 08:58 ? 00:00:00 [posixcputmr/0] 1 S root 7 2 0 99 19 - 0 run_cm 08:58 ? 00:00:00 [kcmosdelayd] 1 S root 8 2 0 -40 - - 0 cpu_st 08:58 ? 00:00:00 [migration/0] 1 S root 9 2 0 58 - - 0 rcu_cp 08:58 ? 00:00:00 [rcuc/0] 1 S root 10 2 0 -40 - - 0 rcu_no 08:58 ? 00:00:00 [rcun/0] 1 S root 11 2 0 58 - - 0 rcu_bo 08:58 ? 00:00:00 [rcub/0] 1 S root 12 2 0 -40 - - 0 rcu_no 08:58 ? 00:00:00 [rcun/1] 1 S root 13 2 0 58 - - 0 rcu_bo 08:58 ? 00:00:00 [rcub/1] 1 S root 14 2 0 -40 - - 0 watchd 08:58 ? 00:00:00 [watchdog/0] 1 S root 15 2 0 -40 - - 0 posix_ 08:58 ? 00:00:00 [posixcputmr/1] 1 S root 16 2 0 -40 - - 0 cpu_st 08:58 ? 00:00:00 [migration/1] 1 S root 18 2 0 58 - - 0 rcu_cp 08:58 ? 00:00:01 [rcuc/1] 5 S root 19 2 0 58 - - 0 run_ks 08:58 ? 00:00:19 [ksoftirqd/1] 1 S root 21 2 0 -40 - - 0 watchd 08:58 ? 00:00:00 [watchdog/1] 1 S root 22 2 0 -40 - - 0 posix_ 08:58 ? 00:00:00 [posixcputmr/2] 1 S root 23 2 0 -40 - - 0 cpu_st 08:58 ? 00:00:00 [migration/2] 1 S root 25 2 0 58 - - 0 rcu_cp 08:58 ? 00:00:00 [rcuc/2] 5 S root 26 2 0 58 - - 0 run_ks 08:58 ? 00:00:20 [ksoftirqd/2] 1 S root 27 2 0 -40 - - 0 watchd 08:58 ? 00:00:00 [watchdog/2] 1 S root 28 2 0 -40 - - 0 posix_ 08:58 ? 00:00:00 [posixcputmr/3] 1 S root 29 2 0 -40 - - 0 cpu_st 08:58 ? 00:00:00 [migration/3] 1 S root 31 2 0 58 - - 0 rcu_cp 08:58 ? 00:00:00 [rcuc/3] 5 S root 32 2 0 58 - - 0 run_ks 08:58 ? 00:00:18 [ksoftirqd/3] 1 S root 33 2 0 -40 - - 0 watchd 08:58 ? 00:00:00 [watchdog/3] 1 S root 34 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [cpuset] 1 S root 35 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [khelper] 5 S root 36 2 0 99 19 - 0 devtmp 08:58 ? 00:00:00 [kdevtmpfs] 1 S root 37 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [netns] 1 S root 38 2 0 99 19 - 0 bdi_sy 08:58 ? 00:00:00 [sync_supers] 1 S root 39 2 0 99 19 - 0 bdi_fo 08:58 ? 00:00:00 [bdi-default] 1 S root 40 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [kintegrityd] 1 S root 41 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [crypto] 1 S root 42 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [kblockd] 1 S root 43 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/9-acpi] 1 S root 44 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [ata_sff] 1 S root 45 2 0 99 19 - 0 hub_th 08:58 ? 00:00:00 [khubd] 1 S root 46 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [md] 1 S root 47 2 0 99 19 - 0 mce_no 08:58 ? 00:00:00 [mce-notify] 1 S root 48 2 0 99 19 - 0 watchd 08:58 ? 00:00:00 [khungtaskd] 1 S root 49 2 0 99 19 - 0 kswapd 08:58 ? 00:00:06 [kswapd0] 1 S root 50 2 0 99 19 - 0 ksm_sc 08:58 ? 00:00:00 [ksmd] 1 S root 51 2 0 99 19 - 0 fsnoti 08:58 ? 00:00:00 [fsnotify_mark] 1 S root 55 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [kthrotld] 1 S root 56 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/40-PCIe PME] 1 S root 57 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/41-PCIe PME] 1 S root 58 2 0 9 - - 0 irq_th 08:58 ? 00:00:14 [irq/42-ahci] 1 S root 59 2 0 99 19 - 0 scsi_e 08:58 ? 00:00:00 [scsi_eh_0] 1 S root 60 2 0 99 19 - 0 scsi_e 08:58 ? 00:00:00 [scsi_eh_1] 1 S root 61 2 0 99 19 - 0 scsi_e 08:58 ? 00:00:00 [scsi_eh_2] 1 S root 62 2 0 99 19 - 0 scsi_e 08:58 ? 00:00:00 [scsi_eh_3] 1 S root 63 2 0 99 19 - 0 scsi_e 08:58 ? 00:00:00 [scsi_eh_4] 1 S root 64 2 0 99 19 - 0 scsi_e 08:58 ? 00:00:00 [scsi_eh_5] 1 S root 67 2 0 99 19 - 0 worker 08:58 ? 00:00:00 [kworker/u:3] 1 S root 69 2 0 99 19 - 0 worker 08:58 ? 00:00:00 [kworker/u:5] 1 S root 71 2 0 9 - - 0 irq_th 08:58 ? 00:00:02 [irq/16-ehci_hcd] 1 S root 72 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/23-ehci_hcd] 1 S root 73 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/1-i8042] 1 S root 75 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [kpsmoused] 1 S root 76 2 0 99 19 - 0 worker 08:58 ? 00:00:00 [kworker/1:2] 1 S root 77 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/8-rtc0] 1 S root 80 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [deferwq] 1 S root 81 2 0 99 19 - 0 worker 08:58 ? 00:00:00 [kworker/3:1] 1 S root 137 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [kmpath_rdacd] 1 S root 187 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/43-i915] 1 S root 249 2 0 99 19 - 0 kjourn 08:58 ? 00:00:00 [jbd2/sda6-8] 1 S root 250 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [ext4-dio-unwrit] 1 S root 257 2 0 99 19 - 0 bdi_wr 08:58 ? 00:00:00 [flush-8:0] 4 S root 303 1 0 99 19 - 9043 ep_pol 08:58 ? 00:00:00 /lib/systemd/systemd-journald 1 S root 305 2 0 99 19 - 0 kaudit 08:58 ? 00:00:00 [kauditd] 4 S root 325 1 0 99 19 - 8622 ep_pol 08:58 ? 00:00:00 /lib/udev/udevd 5 S root 448 325 0 99 19 - 8589 ep_pol 08:58 ? 00:00:00 /lib/udev/udevd 1 S root 492 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/44-mei] 1 S root 501 2 0 99 19 - 0 worker 08:58 ? 00:00:00 [kworker/3:2] 1 S root 516 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/5-parport0] 1 S root 529 2 0 9 - - 0 irq_th 08:58 ? 00:00:03 [irq/46-snd_hda_] 1 S root 530 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [hd-audio0] 1 S root 566 2 0 99 19 - 0 kjourn 08:58 ? 00:00:00 [jbd2/sda7-8] 1 S root 567 2 0 99 19 - 0 rescue 08:58 ? 00:00:00 [ext4-dio-unwrit] 4 S root 602 1 0 99 19 - 2130 poll_s 08:58 ? 00:00:00 /usr/sbin/haveged -F 1 -w 1024 -v 0 4 S root 610 1 0 99 19 - 17769 ep_pol 08:58 ? 00:00:00 /usr/sbin/cupsd -f 4 S avahi 612 1 0 80 0 - 5427 poll_s 08:58 ? 00:00:00 avahi-daemon: running [LINUX4C.local] 4 S root 614 1 0 99 19 - 4199 poll_s 08:58 ? 00:00:00 /usr/sbin/nscd -d 4 S root 618 1 0 99 19 - 5272 poll_s 08:58 ? 00:00:00 /sbin/rpcbind -w -f 4 S root 622 1 0 99 19 - 6520 ep_pol 08:58 ? 00:00:00 /lib/systemd/systemd-logind 5 S root 652 1 0 99 19 - 5363 hrtime 08:58 ? 00:00:00 /usr/sbin/irqbalance 5 S root 666 1 0 99 19 - 62805 poll_s 08:58 ? 00:00:00 /sbin/rsyslogd -c 5 -f /etc/rsyslog.conf 1 S root 672 1 0 99 19 - 1054 poll_s 08:58 ? 00:00:00 /usr/sbin/acpid 1 S root 677 1 0 99 19 - 5490 poll_s 08:58 ? 00:00:00 /usr/bin/vmware-usbarbitrator 4 S root 678 1 0 99 19 - 4891 hrtime 08:58 ? 00:00:00 /usr/sbin/smartd -n 4 S 100 679 1 0 80 0 - 5042 ep_pol 08:58 ? 00:00:05 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 5 S root 690 1 0 99 19 - 4956 ep_pol 08:58 ? 00:00:00 /sbin/auditd -s disable 1 S root 1191 2 0 9 - - 0 irq_th 08:58 ? 00:00:00 [irq/45-eth0] 5 S root 1323 1 0 99 19 - 2133 poll_s 08:58 ? 00:00:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.init.pid 1 S root 1419 1 0 99 19 - 45708 futex_ 08:58 ? 00:00:00 /usr/lib/vmware/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse 5 S root 1440 1 0 99 19 - 5402 poll_s 08:58 ? 00:00:00 /usr/sbin/vmware-authdlauncher 5 S root 1594 1 0 99 19 - 53082 poll_s 08:58 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 4 S wwwrun 1655 1 0 80 0 - 81037 futex_ 08:58 ? 00:00:00 /usr/bin/mono /usr/lib/mono/2.0/mod-mono-server2.exe --filename /tmp/mod_mono_server_global --nonstop --master 5 S wwwrun 1658 1594 0 80 0 - 53090 inet_c 08:58 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1659 1594 0 80 0 - 53090 inet_c 08:58 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1663 1594 0 80 0 - 53090 inet_c 08:58 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1665 1594 0 80 0 - 53090 inet_c 08:58 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 5 S wwwrun 1666 1594 0 80 0 - 53090 inet_c 08:58 ? 00:00:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 4 S root 1714 1 0 99 19 - 1051 n_tty_ 08:58 tty1 00:00:00 /sbin/agetty tty1 38400 5 S ntp 2003 1 0 80 0 - 6199 poll_s 08:58 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf 5 S root 2062 1 0 99 19 - 7232 poll_s 08:58 ? 00:00:00 /usr/bin/kdm 4 S root 2081 2062 1 99 19 - 76883 poll_s 08:58 tty7 00:00:27 /usr/bin/Xorg -br :0 vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-Ltzhta 4 S root 2130 1 0 99 19 - 5199 ep_pol 08:58 ? 00:00:00 /usr/lib/postfix/master 4 S postfix 2148 2130 0 80 0 - 5191 ep_pol 08:58 ? 00:00:00 pickup -l -t fifo -u 4 S postfix 2149 2130 0 80 0 - 5253 ep_pol 08:58 ? 00:00:00 qmgr -l -t fifo -u 5 S root 2165 2062 0 99 19 - 18785 rt_sig 08:58 ? 00:00:00 -:0 4 S root 2184 1 0 99 19 - 522896 poll_s 08:58 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon 4 S root 2249 1 0 99 19 - 50026 poll_s 08:58 ? 00:00:00 /usr/lib/polkit-1/polkitd --no-debug 4 S root 2260 2165 0 99 19 - 2939 wait 08:58 ? 00:00:00 /bin/sh /usr/bin/startkde 1 S root 2329 2260 0 99 19 - 3417 poll_s 08:58 ? 00:00:00 /usr/bin/gpg-agent --sh --daemon --write-env-file /root/.gnupg/agent.info /usr/bin/ssh-agent /etc/X11/xinit/xinitrc 1 S root 2330 2260 0 99 19 - 3071 poll_s 08:58 ? 00:00:00 /usr/bin/ssh-agent /etc/X11/xinit/xinitrc 1 S root 2371 1 0 99 19 - 3972 poll_s 08:58 ? 00:00:00 dbus-launch --sh-syntax --exit-with-session 5 S root 2372 1 0 99 19 - 5206 ep_pol 08:58 ? 00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 1 S root 2379 1 0 99 19 - 1011 pipe_w 08:58 ? 00:00:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup 1 S root 2380 1 0 99 19 - 77118 poll_s 08:58 ? 00:00:00 kdeinit4: kdeinit4 Running... 1 S root 2381 2380 0 99 19 - 78178 poll_s 08:58 ? 00:00:00 kdeinit4: klauncher [kdeinit] --fd=9 5 S root 2383 1 0 99 19 - 186042 poll_s 08:58 ? 00:00:00 kdeinit4: kded4 [kdeinit] 1 S root 2387 1 0 99 19 - 97818 poll_s 08:58 ? 00:00:00 kdeinit4: kglobalaccel [kdeinit] 1 S root 2391 1 0 99 19 - 62127 poll_s 08:58 ? 00:00:00 /usr/bin/kactivitymanagerd 4 S root 2393 1 0 99 19 - 59343 poll_s 08:58 ? 00:00:00 /usr/lib/upower/upowerd 0 S root 2430 2260 0 99 19 - 1045 unix_s 08:58 ? 00:00:00 kwrapper4 ksmserver 1 S root 2431 2380 0 99 19 - 116589 poll_s 08:58 ? 00:00:00 kdeinit4: ksmserver [kdeinit] 4 S root 2459 1 0 99 19 - 48369 poll_s 08:58 ? 00:00:18 /usr/lib/udisks/udisks-daemon 1 S root 2460 2459 0 99 19 - 11383 poll_s 08:58 ? 00:00:00 udisks-daemon: not polling any devices 0 S root 2466 2431 0 99 19 - 126523 poll_s 08:58 ? 00:00:01 kwin -session 10a47d9155000137310114000000024450000_1412200732_238637 5 S root 2489 1 0 99 19 - 235317 poll_s 08:58 ? 00:00:00 /usr/bin/knotify4 5 S root 2492 1 0 99 19 - 229184 poll_s 08:58 ? 00:00:06 kdeinit4: plasma-desktop [kdeinit] 1 S root 2497 1 0 99 19 - 61737 poll_s 08:59 ? 00:00:00 /usr/bin/kuiserver 1 S root 2529 1 0 99 19 - 97573 poll_s 08:59 ? 00:00:00 kdeinit4: kaccess [kdeinit] 1 S root 2538 2380 0 99 19 - 99539 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 1011dc9d2e6000134588144200000030560010_1412200732_232885 1 S root 2539 2380 0 99 19 - 99539 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000136075139200000021620012_1412200732_233139 1 S root 2540 2380 0 99 19 - 99539 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000136075139200000021620013_1412200732_232893 1 S root 2541 2380 0 99 19 - 99539 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000136075139200000021620014_1412200732_233176 0 S root 2542 2380 0 99 19 - 89218 poll_s 08:59 ? 00:00:00 kres-migrator -session 10a47d9155000139300665600000025640068_1412200732_233216 1 S root 2543 1 0 99 19 - 191304 poll_s 08:59 ? 00:00:01 kdeinit4: krunner [kdeinit] 1 S root 2548 1 0 99 19 - 111223 poll_s 08:59 ? 00:00:00 /usr/bin/kopete -session 10a47d9155000139308385800000035730047_1412200732_233261 5 S root 2565 1 0 99 19 - 107494 poll_s 08:59 ? 00:00:00 /usr/bin/kget -session 10a47d9155000139809448100000050170028_1412200732_233305 5 S root 2576 1 0 99 19 - 103705 poll_s 08:59 ? 00:00:01 /usr/bin/ktorrent -session 10a47d9155000139962581600000025140021_1412200732_233350 1 S root 2588 1 0 99 19 - 118422 poll_s 08:59 ? 00:00:00 kdeinit4: kmix [kdeinit] -session 10a47d9155000140188735700000025220006_1412200732_233397 0 S root 2589 2380 0 99 19 - 59232 poll_s 08:59 ? 00:00:00 /usr/bin/qasmixer -session 10a47d9155000140188752900000025220009_1412200732_233441 1 S root 2596 2380 0 99 19 - 99538 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140713760500000024000021_1412200732_233488 1 S root 2597 2380 0 99 19 - 99532 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140758851800000024100039_1412200732_233528 1 S root 2598 2380 0 99 19 - 99539 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140758876100000024100045_1412200732_233568 1 S root 2599 2380 0 99 19 - 99539 poll_s 08:59 ? 00:00:00 kdeinit4: konqueror [kdeinit] -session 10a47d9155000140951128800000024580009_1412200732_233598 5 S root 2618 1 0 99 19 - 341218 poll_s 08:59 ? 00:00:15 /usr/bin/amarok -session 10a47d9155000141199627500000025150040_1412200732_233645 1 S root 2624 1 0 99 19 - 83443 poll_s 08:59 ? 00:00:00 /usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1 1 S root 2672 2380 0 99 19 - 130346 poll_s 09:03 ? 00:00:00 kdeinit4: konqueror [kdeinit] --silent 5 S root 2674 2380 1 99 19 - 136641 poll_s 09:03 ? 00:00:26 kdeinit4: konqueror [kdeinit] --silent 0 S root 2794 2380 0 99 19 - 196131 poll_s 09:05 ? 00:00:06 /usr/lib64/firefox/firefox 0 S root 2806 1 0 99 19 - 10471 poll_s 09:05 ? 00:00:00 /usr/lib/GConf/2/gconfd-2 0 S root 2822 1 0 99 19 - 9846 poll_s 09:05 ? 00:00:00 /usr/lib/gvfs/gvfsd 4 S root 2824 1 0 99 19 - 66810 futex_ 09:05 ? 00:00:00 /usr/lib/gvfs//gvfs-fuse-daemon -f /root/.cache/gvfs 0 S root 2831 2794 0 99 19 - 61063 poll_s 09:05 ? 00:00:00 /usr/lib/mozilla/kmozillahelper 5 R root 2873 1 0 99 19 - 129708 poll_s 09:07 ? 00:00:03 kdeinit4: konsole [kdeinit] 0 S root 2875 2873 0 99 19 - 3330 n_tty_ 09:07 pts/1 00:00:00 /bin/bash 1 S root 2902 2 0 99 19 - 0 worker 09:09 ? 00:00:00 [kworker/2:0] 1 S root 3068 2 0 99 19 - 0 worker 09:13 ? 00:00:00 [kworker/1:0] 0 S root 3076 2873 0 99 19 - 3330 n_tty_ 09:13 pts/2 00:00:00 /bin/bash 1 S root 3228 2 0 99 19 - 0 worker 09:26 ? 00:00:00 [kworker/0:1] 1 S root 3237 2 0 99 19 - 0 worker 09:31 ? 00:00:00 [kworker/0:0] 1 S root 3240 2 0 99 19 - 0 worker 09:33 ? 00:00:00 [kworker/2:2] 1 S root 3247 2 0 99 19 - 0 worker 09:39 ? 00:00:00 [kworker/0:2] 1 S root 3248 2380 0 99 19 - 77686 poll_s 09:40 ? 00:00:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-root/klauncherNT2381.slave-socket local:/tmp/ksocket-root/konqueroryX2674.slave-socket 1 S root 3251 2380 0 99 19 - 98485 poll_s 09:40 ? 00:00:00 kdeinit4: kio_thumbnail [kdeinit] thumbnail local:/tmp/ksocket-root/klauncherNT2381.slave-socket local:/tmp/ksocket-root/konquerorNL2674.slave-socket 0 S root 3262 2873 0 99 19 - 3330 wait 09:40 pts/3 00:00:00 /bin/bash 5 S root 3291 325 0 99 19 - 8457 ep_pol 09:40 ? 00:00:00 /lib/udev/udevd 0 R root 3373 3262 0 99 19 - 1230 - 09:41 pts/3 00:00:00 ps -elf LINUX4C:/home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux # uname -a Linux LINUX4C 3.4.97-rt121-2.16-desktop #1 SMP PREEMPT RT Wed Oct 1 16:31:42 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux LINUX4C:/home/opt/openPOWERLINK-V2.0.1/apps/demo_mn_console/build/linux # ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-02 8:02 ` Armin Steinhoff @ 2014-10-04 10:49 ` Carsten Emde 2014-10-04 12:36 ` Armin Steinhoff 0 siblings, 1 reply; 27+ messages in thread From: Carsten Emde @ 2014-10-04 10:49 UTC (permalink / raw) To: Armin Steinhoff, Patrik Lundquist; +Cc: rt-users Armin, > [..] But there are some sideeffects to other running > processes/threads related to their assigned priorities. Here is the > priority assignment after a fresh boot: ps -elf -> > Prio-After-OS-Restart.txt attached > > If the app "demo_mn_console" has started its first RT thread, a lot > of other processes/threads are jumping to the highest RT priority > 99!! Please have a look to: ps -elf -> Prio-after-app-start.txt > > Do we have a problem with the RT kernel ? Or is simply the ps > utility broken ? Let me try to summarize your observations and suspicions: 1. After booting your RT kernel, everything works as expected. 2. The ps utility works as expected. 3. There are no bug reports that the RT kernel autonomously and at random fiddles around with task priorities. 4. There are no bug reports that the ps utility - one of the most frequently used utilities - suddenly may start to display erroneous priority numbers. 5. At a given time, you start your application that apparently modifies task priorities *in some way*. 6. Shortly afterwards you are observing that other not intended tasks changed their priority as well. 7. Your first suspicion is that we may have a problem with the RT kernel. 8. And your second suspicion is that the ps utility is broken. Doesn't come another suspicion to mind? -Carsten. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 10:49 ` Carsten Emde @ 2014-10-04 12:36 ` Armin Steinhoff 2014-10-04 12:50 ` Armin Steinhoff ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-04 12:36 UTC (permalink / raw) To: Carsten Emde, Patrik Lundquist; +Cc: rt-users Carsten Emde schrieb: > Armin, > >> [..] But there are some sideeffects to other running >> processes/threads related to their assigned priorities. Here is the >> priority assignment after a fresh boot: ps -elf -> >> Prio-After-OS-Restart.txt attached >> >> If the app "demo_mn_console" has started its first RT thread, a lot >> of other processes/threads are jumping to the highest RT priority >> 99!! Please have a look to: ps -elf -> Prio-after-app-start.txt >> >> Do we have a problem with the RT kernel ? Or is simply the ps >> utility broken ? > Let me try to summarize your observations and suspicions: > 1. After booting your RT kernel, everything works as expected. Yes, all seems to be OK. > 2. The ps utility works as expected. Yes > 3. There are no bug reports that the RT kernel autonomously and at > random fiddles around with task priorities. I have submited a bug report in the meantime. > 4. There are no bug reports that the ps utility - one of the most > frequently used utilities - suddenly may start to display erroneous > priority numbers. A bug in the good old "ps" would be very unlikely. > > 5. At a given time, you start your application that apparently modifies > task priorities *in some way*. Not in some way ... the developers of the openPOWERLINK stack are using plain POSIX calls. > 6. Shortly afterwards you are observing that other not intended tasks > changed their priority as well. Yes ... most processes running previously at 80 are jumping to 99! > > 7. Your first suspicion is that we may have a problem with the RT kernel. > 8. And your second suspicion is that the ps utility is broken. The question about the operation of "ps" was just a formal one .. sorry. > > Doesn't come another suspicion to mind? Why should I have one? The same code works correctly under then non-RT version of the kernel ... at least from the Linux point of view. --Armin > -Carsten. > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 12:36 ` Armin Steinhoff @ 2014-10-04 12:50 ` Armin Steinhoff 2014-10-04 23:56 ` Thomas Gleixner 2014-10-05 10:13 ` Operation not permitted / pthread_setschedparam Armin Steinhoff 2 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-04 12:50 UTC (permalink / raw) To: Carsten Emde, Patrik Lundquist; +Cc: rt-users Hi, some RT threads of the openPOWERLINK threads (2.0.1) are running CPU affine on selected cores. Is this important ? --Armin Armin Steinhoff schrieb: > Carsten Emde schrieb: > [ clip] > Doesn't come another suspicion to mind? > Why should I have one? The same code works correctly under then non-RT > version of the kernel ... at least from the Linux point of view. > > --Armin > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 12:36 ` Armin Steinhoff 2014-10-04 12:50 ` Armin Steinhoff @ 2014-10-04 23:56 ` Thomas Gleixner 2014-10-05 11:07 ` Armin Steinhoff ` (3 more replies) 2014-10-05 10:13 ` Operation not permitted / pthread_setschedparam Armin Steinhoff 2 siblings, 4 replies; 27+ messages in thread From: Thomas Gleixner @ 2014-10-04 23:56 UTC (permalink / raw) To: Armin Steinhoff; +Cc: Carsten Emde, Patrik Lundquist, rt-users On Sat, 4 Oct 2014, Armin Steinhoff wrote: > 8. And your second suspicion is that the ps utility is broken. > The question about the operation of "ps" was just a formal one .. sorry. Well, I'd say it's not formal. Let me cite from your previous mail: > > > If the app "demo_mn_console" has started its first RT thread, a > > > lot of other processes/threads are jumping to the highest RT > > > priority 99!! Did you ever try to invoke: # man ps and try to figure out what the PRI field actually means? Definitely not. My version of "man ps" tells me: pri PRI priority of the process. Higher number means lower priority. Can you figure out why your problem analysis > > > If the app "demo_mn_console" has started its first RT thread, a > > > lot of other processes/threads are jumping to the highest RT > > > priority 99!! causes people on this list to assume that you either are - a student seeking advise for his first homework assignement or - someone completely incompetent trying to make a business by abusing a community? or - a person with a severe drug abuse problem which causes reality distortion? but definitely not a business who claims itself to be "the Real-Time, Fieldbus, and GUI Experts" [1] Thanks, tglx [1] http://steinhoff.de/index.htm ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 23:56 ` Thomas Gleixner @ 2014-10-05 11:07 ` Armin Steinhoff 2014-10-05 11:47 ` Armin Steinhoff ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-05 11:07 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Carsten Emde, Patrik Lundquist, rt-users Thomas Gleixner schrieb: > On Sat, 4 Oct 2014, Armin Steinhoff wrote: >> 8. And your second suspicion is that the ps utility is broken. >> The question about the operation of "ps" was just a formal one .. sorry. > Well, I'd say it's not formal. Let me cite from your previous mail: > >>>> If the app "demo_mn_console" has started its first RT thread, a >>>> lot of other processes/threads are jumping to the highest RT >>>> priority 99!! > Did you ever try to invoke: Did you try to switch on your brain before you wrote such insulting nonsense ?? --Armin > > # man ps > > and try to figure out what the PRI field actually means? Definitely > not. > > My version of "man ps" tells me: > > pri PRI priority of the process. Higher number means > lower priority. > > Can you figure out why your problem analysis > >>>> If the app "demo_mn_console" has started its first RT thread, a >>>> lot of other processes/threads are jumping to the highest RT >>>> priority 99!! > causes people on this list to assume that you either are > > - a student seeking advise for his first homework assignement > > or > > - someone completely incompetent trying to make a business by > abusing a community? > > or > > - a person with a severe drug abuse problem which causes reality > distortion? > > but definitely not a business who claims itself to be > > "the Real-Time, Fieldbus, and GUI Experts" [1] > > > Thanks, > > tglx > > [1] http://steinhoff.de/index.htm > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 23:56 ` Thomas Gleixner 2014-10-05 11:07 ` Armin Steinhoff @ 2014-10-05 11:47 ` Armin Steinhoff 2014-10-05 14:34 ` Armin Steinhoff [not found] ` <54312C88.8060609@steinhoff.de> 3 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-05 11:47 UTC (permalink / raw) To: Thomas Gleixner; +Cc: rt-users Thomas Gleixner schrieb: > On Sat, 4 Oct 2014, Armin Steinhoff wrote: >> 8. And your second suspicion is that the ps utility is broken. >> The question about the operation of "ps" was just a formal one .. sorry. >> >> Well, I'd say it's not formal. Let me cite from your previous mail:f the app "demo_mn_console" has started its first RT thread, a >> lot of other processes/threads are jumping to the highest RT >> priority 99!! > Did you ever try to invoke: > > # man ps > > and try to figure out what the PRI field actually means? Definitely > not. I'm working since a long time with _different_ REAL-TIME operating systems and yes, I interpreted for a moment the PRI output of "ps" wrong! But this doesn't explain why pthread_schedparam had problems with an earlier PREEMPT_RT kernel! And pointing out such a problem and problems of "ps" is for you: - a student seeking advise for his first homework assignement - someone completely incompetent trying to make a business by abusing a community? - a person with a severe drug abuse problem which causes reality distortion? ???? OK ... you are expert for the PREEMPT_RT kernel for a long time. Hope you are still OK ... --Armin *PS: I never had such a silly discussion ...* > My version of "man ps" tells me: > > pri PRI priority of the process. Higher number means > lower priority. > > Can you figure out why your problem analysis > >>>> If the app "demo_mn_console" has started its first RT thread, a >>>> lot of other processes/threads are jumping to the highest RT >>>> priority 99!! > causes people on this list to assume that you either are > > - a student seeking advise for his first homework assignement > > or > > - someone completely incompetent trying to make a business by > abusing a community? > > or > > - a person with a severe drug abuse problem which causes reality > distortion? > > but definitely not a business who claims itself to be > > "the Real-Time, Fieldbus, and GUI Experts" [1] > > > Thanks, > > tglx > > [1] http://steinhoff.de/index.htm > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 23:56 ` Thomas Gleixner 2014-10-05 11:07 ` Armin Steinhoff 2014-10-05 11:47 ` Armin Steinhoff @ 2014-10-05 14:34 ` Armin Steinhoff [not found] ` <54312C88.8060609@steinhoff.de> 3 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-05 14:34 UTC (permalink / raw) To: rt-users Thomas Gleixner schrieb: > On Sat, 4 Oct 2014, Armin Steinhoff wrote: >> 8. And your second suspicion is that the ps utility is broken. >> The question about the operation of "ps" was just a formal one .. sorry. > Well, I'd say it's not formal. Let me cite from your previous mail: > >>>> If the app "demo_mn_console" has started its first RT thread, a >>>> lot of other processes/threads are jumping to the highest RT >>>> priority 99!! > Did you ever try to invoke: > > # man ps > > and try to figure out what the PRI field actually means? Definitely > not. > > My version of "man ps" tells me: > > pri PRI priority of the process. Higher number means > lower priority. I have two version of the "man ps" ... the statement of man page 1p isn't applicable for SCHED_FIFO/SCHED_RR because 99 is right here the highest prio for the scheduling. Sorry for not bothering about the confusing handling of priorities within LINUX ... --Armin ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <54312C88.8060609@steinhoff.de>]
* Re: Operation not permitted / pthread_setschedparam [not found] ` <54312C88.8060609@steinhoff.de> @ 2014-10-05 20:54 ` Thomas Gleixner 2014-10-06 8:03 ` Armin Steinhoff 2014-10-06 13:34 ` Armin Steinhoff 0 siblings, 2 replies; 27+ messages in thread From: Thomas Gleixner @ 2014-10-05 20:54 UTC (permalink / raw) To: Armin Steinhoff; +Cc: rt-users On Sun, 5 Oct 2014, Armin Steinhoff wrote: > But this doesn't explain why pthread_schedparam had problems with an > earlier PREEMPT_RT kernel! > And pointing out such a problem and problems of "ps" is for you: Lets look at the problems. I built the random kernel version which you used for testing and against which you reported a bug. # uname -a # Linux fuzz 3.4.0-rc7-rt7+ #42 SMP PREEMPT RT Sun Oct 5 15:52:24 CEST 2014 x86_64 GNU/Linux Using the following test program: #include <unistd.h> #include <stdlib.h> #include <string.h> #include <stdio.h> #include <pthread.h> static void *fn(void *p) { while (1) sleep(1); return NULL; } int main(void) { struct sched_param sp; pthread_t t; if (pthread_create(&t, NULL, fn, NULL) != 0) exit(1); memset(&sp, 0, sizeof(sp)); sp.__sched_priority = 80; if (pthread_setschedparam(t, SCHED_FIFO, &sp) != 0) exit(1); printf("OK\n"); sleep(60); exit(0); } Which is exactly what you claim to be broken. # ./sp OK # strace ./sp 2>&1 | grep sched sched_setscheduler(2197, SCHED_FIFO, { 80 }) = 0 # Strange. It works. Now lets verify the latest 3.4 version. # uname -a # Linux fuzz 3.4.97-rt121+ #43 SMP PREEMPT RT Sun Oct 5 15:57:30 CEST 2014 x86_64 GNU/Linux Your claim now is that the priorities of random other programs are modified after the first thread is started and its priority is set. So the issue should be observable with the above test program as well. # ps -elLf >a.txt # cat a.txt | awk '{ print $7; }' | grep 99 # cat a.txt | awk '{ print $8; }' | grep 19 # ./sp & OK # ps -elLf >b.txt # cat b.txt | awk '{ print $7; }' | grep 99 # cat b.txt | awk '{ print $8; }' | grep 19 # diff -u a.txt b.txt --- a.txt 2014-10-05 16:02:08.994360001 +0200 +++ b.txt 2014-10-05 16:02:17.518360000 +0200 @@ -102,4 +102,6 @@ 0 S tglx 1892 1891 1892 0 1 80 0 - 5250 wait 15:59 pts/0 00:00:00 -bash 4 S root 1973 1892 1973 0 1 80 0 - 10497 wait 15:59 pts/0 00:00:00 su 4 S root 1974 1973 1974 0 1 80 0 - 4928 wait 15:59 pts/0 00:00:00 bash -4 R root 2005 1974 2005 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf +4 S root 2006 1974 2006 0 2 80 0 - 3638 hrtime 16:02 pts/0 00:00:00 ./sp +1 S root 2006 1974 2007 0 2 -21 - - 3638 hrtime 16:02 pts/0 00:00:00 ./sp +4 R root 2008 1974 2008 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf Even more strange. Works as well. And the output of 'ps -elLf' for 'sp' is exactly matching the above program. Now I really had to switch my brain off for this excercise because with brain on, I already knew that neither sys_setschedparam() is or was broken, nor the kernel randomly modifies priorities nor ps gives randomized output. I asked you at the beginning of this very thread to read linux/Documentation/REPORTING-BUGS. You ignored that and came back with more theories about kernel bugs and ps being broken. Then despite the fact, that you failed to provide a proper bug report, Carsten gave you enough hints to decode the issue. But you insist on reporting bugs and problems and come up with more theories about broken kernels and tools. So you really expect the people who are willing to help you for free and who gave you perfectly fine hints how to decode your problem, should accept that you ignore their hints and advice? That's blatant abuse. Abuse of those who try to guide you and those who provided you with the technology on which you build products in the first place. This is not how community support works. Do you really expect, that we waste our time with someone who seeks help and responds to hints and advise with: > I have two version of the "man ps" ... the statement of man page 1p > isn't applicable for SCHED_FIFO/SCHED_RR because 99 is right here the > highest prio for the scheduling. So after carefully studying man ps, you came to that conclusion and certainly have fully understood how all that works. > Sorry for not bothering about the confusing handling of priorities > within LINUX ..." Or perhaps not? So you make claims about priorities and cannot be bothered to figure out how the priority handling of Linux works? Why should we be bothered to solve your business problems, if you are outright refusing to do your homework before stealing everyones time? While I surely could have responded more politely, you might understand that there are limits of patience and limits on tolerating abusive behaviour. Now back to your original question. > And pointing out such a problem and problems of "ps" is for you: A very good reason to ignore any further posts from you. Thanks, tglx ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-05 20:54 ` Thomas Gleixner @ 2014-10-06 8:03 ` Armin Steinhoff 2014-10-06 13:34 ` Armin Steinhoff 1 sibling, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-06 8:03 UTC (permalink / raw) To: Thomas Gleixner; +Cc: rt-users Thomas Gleixner schrieb: > On Sun, 5 Oct 2014, Armin Steinhoff wrote: >> But this doesn't explain why pthread_schedparam had problems with an >> earlier PREEMPT_RT kernel! >> And pointing out such a problem and problems of "ps" is for you: > Lets look at the problems. *What problem ? * *I wrote already before:* -------------------------------------------------------------------------------------- >A bug in the good old "ps" would be very unlikely. This statement is'nt correct ! The "ps -elf" command shows a lot of nonsense ... when I can trust the command "ps -e -L -o class,rtprio,pri,nice,cmd" there are no priority changes of other processes! But after start of the demo the command "ps -e -L -o class,rtprio,pri,nice,cmd" is swapping the values of "pri" of "nice" ... without changing theire values! What's going on here ?? However ,,, *it's good to see that the problem seems not to be in the kernel ...* --Armin ----------------------------------------------------------------------- *And this is already part of a submitted bug report !!* So what your problem?? You should better read ... Your statements are simply pointless, arrogant and insulting! The real problem is the crazy output of "ps -elf" ... --Armin > I built the random kernel version which you used for testing and > against which you reported a bug. > > # uname -a > # Linux fuzz 3.4.0-rc7-rt7+ #42 SMP PREEMPT RT Sun Oct 5 15:52:24 CEST 2014 x86_64 GNU/Linux > > Using the following test program: > > #include <unistd.h> > #include <stdlib.h> > #include <string.h> > #include <stdio.h> > #include <pthread.h> > > static void *fn(void *p) > { > while (1) sleep(1); > return NULL; > } > > int main(void) > { > struct sched_param sp; > pthread_t t; > > if (pthread_create(&t, NULL, fn, NULL) != 0) > exit(1); > > memset(&sp, 0, sizeof(sp)); > sp.__sched_priority = 80; > if (pthread_setschedparam(t, SCHED_FIFO, &sp) != 0) > exit(1); > > printf("OK\n"); > sleep(60); > exit(0); > } > > Which is exactly what you claim to be broken. > > # ./sp > OK > # strace ./sp 2>&1 | grep sched > sched_setscheduler(2197, SCHED_FIFO, { 80 }) = 0 > # > > Strange. It works. > > Now lets verify the latest 3.4 version. > > # uname -a > # Linux fuzz 3.4.97-rt121+ #43 SMP PREEMPT RT Sun Oct 5 15:57:30 CEST 2014 x86_64 GNU/Linux > > Your claim now is that the priorities of random other programs are > modified after the first thread is started and its priority is set. So > the issue should be observable with the above test program as well. > > # ps -elLf >a.txt > # cat a.txt | awk '{ print $7; }' | grep 99 > # cat a.txt | awk '{ print $8; }' | grep 19 > # ./sp & > OK > # ps -elLf >b.txt > # cat b.txt | awk '{ print $7; }' | grep 99 > # cat b.txt | awk '{ print $8; }' | grep 19 > # diff -u a.txt b.txt > --- a.txt 2014-10-05 16:02:08.994360001 +0200 > +++ b.txt 2014-10-05 16:02:17.518360000 +0200 > @@ -102,4 +102,6 @@ > 0 S tglx 1892 1891 1892 0 1 80 0 - 5250 wait 15:59 pts/0 00:00:00 -bash > 4 S root 1973 1892 1973 0 1 80 0 - 10497 wait 15:59 pts/0 00:00:00 su > 4 S root 1974 1973 1974 0 1 80 0 - 4928 wait 15:59 pts/0 00:00:00 bash > -4 R root 2005 1974 2005 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf > +4 S root 2006 1974 2006 0 2 80 0 - 3638 hrtime 16:02 pts/0 00:00:00 ./sp > +1 S root 2006 1974 2007 0 2 -21 - - 3638 hrtime 16:02 pts/0 00:00:00 ./sp > +4 R root 2008 1974 2008 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf > > Even more strange. Works as well. And the output of 'ps -elLf' for > 'sp' is exactly matching the above program. > > Now I really had to switch my brain off for this excercise because > with brain on, I already knew that neither sys_setschedparam() is or > was broken, nor the kernel randomly modifies priorities nor ps gives > randomized output. > > I asked you at the beginning of this very thread to read > linux/Documentation/REPORTING-BUGS. You ignored that and came back > with more theories about kernel bugs and ps being broken. > > Then despite the fact, that you failed to provide a proper bug report, > Carsten gave you enough hints to decode the issue. > > But you insist on reporting bugs and problems and come up with more > theories about broken kernels and tools. > > So you really expect the people who are willing to help you for free > and who gave you perfectly fine hints how to decode your problem, > should accept that you ignore their hints and advice? > > That's blatant abuse. Abuse of those who try to guide you and those > who provided you with the technology on which you build products in > the first place. This is not how community support works. > > Do you really expect, that we waste our time with someone who seeks > help and responds to hints and advise with: > >> I have two version of the "man ps" ... the statement of man page 1p >> isn't applicable for SCHED_FIFO/SCHED_RR because 99 is right here the >> highest prio for the scheduling. > So after carefully studying man ps, you came to that conclusion and > certainly have fully understood how all that works. > >> Sorry for not bothering about the confusing handling of priorities >> within LINUX ..." > Or perhaps not? > > So you make claims about priorities and cannot be bothered to figure > out how the priority handling of Linux works? > > Why should we be bothered to solve your business problems, if you are > outright refusing to do your homework before stealing everyones time? > > While I surely could have responded more politely, you might > understand that there are limits of patience and limits on tolerating > abusive behaviour. > > Now back to your original question. > >> And pointing out such a problem and problems of "ps" is for you: > A very good reason to ignore any further posts from you. > > Thanks, > > tglx > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-05 20:54 ` Thomas Gleixner 2014-10-06 8:03 ` Armin Steinhoff @ 2014-10-06 13:34 ` Armin Steinhoff 2014-10-07 1:33 ` Thomas Gleixner 1 sibling, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-10-06 13:34 UTC (permalink / raw) To: Thomas Gleixner; +Cc: rt-users Sorry ... I got now time to read your test code and results in detail. Your test shows only the absence of failures in your "test" scenario. My bug report provided in Bugzilla shows all informations about the facts. I could upload my test app to the bug report ... so you get a chance to replicate these problems and get out of your "realty distortion". Asking question for a confusing failure situation has nothing to with "abusing the community! Yes, I got 3 good hints ... no statement about the arrogant "hint" from you. It's quite normal to "have theories about a failures" as long as I verify these in order to find the real problem. Are you trying to kidding me with this statement: "Why should we be bothered to solve your business problems," Do you really believe I have a business problem ? There is simpy absolute no business with PREEMPT_RT! I do only some strategic work for a potential usage of PREEMP_RT ... hope this solves your problem. I'm working since 25 years wit QNX and other classical real-time operation systems. I did also operating system development for many years ... but before the first LINUX version was released. So be careful to tell me something about "incompetence" ... --Armin Thomas Gleixner schrieb: > On Sun, 5 Oct 2014, Armin Steinhoff wrote: >> But this doesn't explain why pthread_schedparam had problems with an >> earlier PREEMPT_RT kernel! >> And pointing out such a problem and problems of "ps" is for you: > Lets look at the problems. > > I built the random kernel version which you used for testing and > against which you reported a bug. > > # uname -a > # Linux fuzz 3.4.0-rc7-rt7+ #42 SMP PREEMPT RT Sun Oct 5 15:52:24 CEST 2014 x86_64 GNU/Linux > > Using the following test program: > > #include <unistd.h> > #include <stdlib.h> > #include <string.h> > #include <stdio.h> > #include <pthread.h> > > static void *fn(void *p) > { > while (1) sleep(1); > return NULL; > } > > int main(void) > { > struct sched_param sp; > pthread_t t; > > if (pthread_create(&t, NULL, fn, NULL) != 0) > exit(1); > > memset(&sp, 0, sizeof(sp)); > sp.__sched_priority = 80; > if (pthread_setschedparam(t, SCHED_FIFO, &sp) != 0) > exit(1); > > printf("OK\n"); > sleep(60); > exit(0); > } > > Which is exactly what you claim to be broken. > > # ./sp > OK > # strace ./sp 2>&1 | grep sched > sched_setscheduler(2197, SCHED_FIFO, { 80 }) = 0 > # > > Strange. It works. > > Now lets verify the latest 3.4 version. > > # uname -a > # Linux fuzz 3.4.97-rt121+ #43 SMP PREEMPT RT Sun Oct 5 15:57:30 CEST 2014 x86_64 GNU/Linux > > Your claim now is that the priorities of random other programs are > modified after the first thread is started and its priority is set. So > the issue should be observable with the above test program as well. > > # ps -elLf >a.txt > # cat a.txt | awk '{ print $7; }' | grep 99 > # cat a.txt | awk '{ print $8; }' | grep 19 > # ./sp & > OK > # ps -elLf >b.txt > # cat b.txt | awk '{ print $7; }' | grep 99 > # cat b.txt | awk '{ print $8; }' | grep 19 > # diff -u a.txt b.txt > --- a.txt 2014-10-05 16:02:08.994360001 +0200 > +++ b.txt 2014-10-05 16:02:17.518360000 +0200 > @@ -102,4 +102,6 @@ > 0 S tglx 1892 1891 1892 0 1 80 0 - 5250 wait 15:59 pts/0 00:00:00 -bash > 4 S root 1973 1892 1973 0 1 80 0 - 10497 wait 15:59 pts/0 00:00:00 su > 4 S root 1974 1973 1974 0 1 80 0 - 4928 wait 15:59 pts/0 00:00:00 bash > -4 R root 2005 1974 2005 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf > +4 S root 2006 1974 2006 0 2 80 0 - 3638 hrtime 16:02 pts/0 00:00:00 ./sp > +1 S root 2006 1974 2007 0 2 -21 - - 3638 hrtime 16:02 pts/0 00:00:00 ./sp > +4 R root 2008 1974 2008 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf > > Even more strange. Works as well. And the output of 'ps -elLf' for > 'sp' is exactly matching the above program. > > Now I really had to switch my brain off for this excercise because > with brain on, I already knew that neither sys_setschedparam() is or > was broken, nor the kernel randomly modifies priorities nor ps gives > randomized output. > > I asked you at the beginning of this very thread to read > linux/Documentation/REPORTING-BUGS. You ignored that and came back > with more theories about kernel bugs and ps being broken. > > Then despite the fact, that you failed to provide a proper bug report, > Carsten gave you enough hints to decode the issue. > > But you insist on reporting bugs and problems and come up with more > theories about broken kernels and tools. > > So you really expect the people who are willing to help you for free > and who gave you perfectly fine hints how to decode your problem, > should accept that you ignore their hints and advice? > > That's blatant abuse. Abuse of those who try to guide you and those > who provided you with the technology on which you build products in > the first place. This is not how community support works. > > Do you really expect, that we waste our time with someone who seeks > help and responds to hints and advise with: > >> I have two version of the "man ps" ... the statement of man page 1p >> isn't applicable for SCHED_FIFO/SCHED_RR because 99 is right here the >> highest prio for the scheduling. > So after carefully studying man ps, you came to that conclusion and > certainly have fully understood how all that works. > >> Sorry for not bothering about the confusing handling of priorities >> within LINUX ..." > Or perhaps not? > > So you make claims about priorities and cannot be bothered to figure > out how the priority handling of Linux works? > > Why should we be bothered to solve your business problems, if you are > outright refusing to do your homework before stealing everyones time? > > While I surely could have responded more politely, you might > understand that there are limits of patience and limits on tolerating > abusive behaviour. > > Now back to your original question. > >> And pointing out such a problem and problems of "ps" is for you: > A very good reason to ignore any further posts from you. > > Thanks, > > tglx > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-06 13:34 ` Armin Steinhoff @ 2014-10-07 1:33 ` Thomas Gleixner 2014-10-07 7:57 ` Armin Steinhoff 2014-10-09 8:35 ` Operation not permitted / pthread_setschedparam / EOD Armin Steinhoff 0 siblings, 2 replies; 27+ messages in thread From: Thomas Gleixner @ 2014-10-07 1:33 UTC (permalink / raw) To: Armin Steinhoff; +Cc: rt-users On Mon, 6 Oct 2014, Armin Steinhoff wrote: > Sorry ... I got now time to read your test code and results in detail. > Your test shows only the absence of failures in your "test" scenario. Correct. So that proves that the kernel behaviour is correct, right? Did you try to verify that test case on your system? Maybe you have, but you did not report back, right? Did you draw any conclusions from that experiment aside of "absence of failures in my test scenario"? Maybe you have, but you did not report back. > My bug report provided in Bugzilla shows all informations about the facts. Lemme look at the facts of https://bugzilla.kernel.org/show_bug.cgi?id=85501 Fact #1: "A multithreaded user space application starts some threads with different RT priorities. After the first start of one of these RT threads, a bunch a other running processes jumping to the highest prio of 99!" This is simply wrong. These processes are reniced to 99, which is the lowest priority in the system. As I told you before: "man ps" Fact #4 part 1: https://bugzilla.kernel.org/show_bug.cgi?id=85501#c3 The output of the command "ps -elf" is incorrect or simply nonsense. Lets do an experiment # ps -elf | grep -m 1 acpid 1 S root 1438 1 0 80 0 - 1058 poll_s 18:44 ? 00:00:00 /usr/sbin/acpid Now we renice all processes which belong to root by 20, i.e. we tell the scheduler that these are the least favourable processes in the system. # renice -n 19 -u root # ps -elf | grep -m 1 acpid 1 S root 1438 1 0 99 19 - 1058 poll_s 18:44 ? 00:00:00 /usr/sbin/acpid And 'ps' tells us correctly, that priority changed from 80 to 99 and nice value changed from 0 to 19. 80 + 19 = 99, right? Lets switch it back to normal # renice -n 0 -u root # ps -elf | grep -m 1 acpid 1 S root 1438 1 0 80 0 - 1058 poll_s 18:44 ? 00:00:00 /usr/sbin/acpid Surely 'ps' output is nonsense, right? Fact #4 part 2: https://bugzilla.kernel.org/show_bug.cgi?id=85501#c3 "ps -e -L -o class,rtprio,pri,nice,cmd" does'nt show priority changes of other unrelated processes ... but the values of pri and nice are swapped! # ps -eo tid,comm,cls,pri,nice | grep -m 1 acpid 1438 acpid TS 19 0 So the scheduling class is TS, prio is 19 and nice is 0 Now we renice all processes which belong to root by 20, i.e. we tell the scheduler that these are the least favourable processes in the system. # renice -n 19 -u root # ps -eo tid,comm,cls,pri,nice | grep -m 1 acpid 1438 acpid TS 0 19 And that's what we expected. The scheduling class is still TS, prio is 0 and nice is 19. Nonsensical as well according to your 'bug report'. So while I agree that this is not intuitive, it is definitely not a bug of ps. It's well documented behaviour and for the different ps modes it is consistent behaviour. If you feel confused by it, it's not a problem of the RT kernel at all. If you think this is wrong, feel free to report a bug against 'ps', but don't continue to pester people who are not responsible for this. > I could upload my test app to the bug report ... so you get a chance to Don't bother. I got it from source and you already spammed all list members with a 400k+ tarball of it. Now compiling the thing from source and running it, does not show any of this behaviour. So to put this to an end I could be bothered to run your version of it. And funny enough it shows the problem. The obvious conclusion is, that if the problem only happens with the particular executable you compiled, it's neither a problem of the kernel nor a problem of ps, right? Surprising, isn't it? Now if you look at your ps outputs you will notice, that only processes which belong to user root are reniced to 99. If you can be bothered to redo the above experiments you probably will notice the same thing. So the next obvious conclusion is, that this executable which you provided issues a syscall which does the same thing as 'renice 19 -u root', right? So lets first look what renice does. # strace renice -n 19 - u root And looking at the output of syscalls there is the relevant one: setpriority(PRIO_USER, 0, 19) = 0 So if my not so reality distorted theory holds, we should see something similar with your executable, right? # strace ./demo_mn_console And searching for setprority in the strace output shows: setpriority(PRIO_USER, 0, 20) = 0 Not exactly the same, but the nice value is clamped to 19, so the kernel treats it the same way. Now what issues that call? Obviously not ps. As you did not provide any pointer to the source, I have no idea what kind of bug is there. Just for completeness sake, I looked at the public available source and put a breakpoint on initSystem(). At the point where the breakpoint was reached, no problem. Single stepping over the next function showed the problem with your executable, but not with the one compiled from the pulic source tree. The public available source calls nice(-20) at this point, which is definitely not going to call setpriority(PRIO_USER, 0, 20) = 0 simply because nice(-20) is issuing the syscall with setpriority(PRIO_PROCESS, 0, -20) = 0 according to the strace output of the version I compiled. Now looking at the disassembly of your executable tells me: 000000000040b954 <initSystem>: 40b954: 55 push %rbp 40b955: 48 89 e5 mov %rsp,%rbp 40b958: 53 push %rbx 40b959: 48 81 ec a8 02 00 00 sub $0x2a8,%rsp 40b960: ba 14 00 00 00 mov $0x14,%edx 40b965: be 00 00 00 00 mov $0x0,%esi 40b96a: bf 02 00 00 00 mov $0x2,%edi 40b96f: e8 2c e2 ff ff callq 409ba0 <setpriority@plt> that it is calling setpriority() with the arguments which = 2 (PRIO_USER) who = 0 (root) prio = 0x14 (20) And that's exactly what is causing your problem. While the executable I compiled from the public available source gives me the following disassembly: 0000000000409f70 <initSystem>: 409f70: 48 81 ec 38 01 00 00 sub $0x138,%rsp 409f77: bf ec ff ff ff mov $0xffffffec,%edi 409f7c: e8 8f ea ff ff callq 408a10 <nice@plt> So that calls nice() with the argument prio = 0xffffffec (-20) Which is what you expect. So the "facts" of your bug report are correct in the observation that: Starting your application is causing unexpected behaviour and the output of 'ps -elf' proves that issue. And that's where the facts end. > replicate these problems and get out of your "realty distortion". Sure, my reality distortion is: - That I knew as everybody else on this thread that the problem is inside your application. It was obvious from your own observation: >> If the app "demo_mn_console" has started its first RT thread, a lot >> of other processes/threads are jumping to the highest RT priority >> 99!! - That I did not follow your reasoning that: >> we have a problem with the RT kernel ? Or is simply the ps >> utility broken ? - That I asked you politely to follow the bug reporting procedures, which you refused. If you look at the above disassembly sections, you should be aware why I can prove that. - That Carsten gave you a detailed argument chain, which pointed obviously to the application itself. But you completely ignored it: "> 7. Your first suspicion is that we may have a problem with the RT kernel. > 8. And your second suspicion is that the ps utility is broken. > Doesn't come another suspicion to mind? Why should I have one? The same code works correctly under then non-RT version of the kernel ... at least from the Linux point of view." - That I told you how to interpret the PRI field of the ps -elf output and you simply refused to even think about it. Instead of that you file bug reports against 'ps' on the kernel bugzilla. Can you see why the kernel bugzilla is the wrong place to file bug reports against 'ps' ? And then you told me clearly: "Sorry for not bothering about the confusing handling of priorities within LINUX ..." So despite the fact, that I asked you to make your self familiar with 'ps', you insist on 'ps' being broken and file a bug report against the RT kernel component? - That I know how 'ps' works I told you to study 'man ps'. That should have been enough hint to decode the issue. - That I knew that neither the v3.4.0-rc7-rt7 nor the v3.4.121-rt97 kernel version was responsible for your problems? Sure. That must be a heavy reality distortion field which caused me to believe that I can figure that out w/o looking at your claims. - That I figured out without having access to the source code of your executable, that you are either running a modified version of the open powerlink code or your build setup has a massive failure. I don't care either way, but you might understand that neither of these problems are relevant for this particular mailinglist. > Asking question for a confusing failure situation has nothing to with > "abusing the community! Asking about it definitely not, but refusing to follow any advise and refusing to follow the hints people give you defintely counts for it. > Yes, I got 3 good hints ... no statement about the arrogant "hint" from you. > It's quite normal to "have theories about a failures" as long as I > verify these in order to find the real problem. Sure, you can have your own view of "having theories about failures", but a community mailing list does not necessarily have to share that view. We care about facts and not about random theories caused by whatever failure modes. > Are you trying to kidding me with this statement: "Why should we be > bothered to solve your business problems," > > Do you really believe I have a business problem ? There is simpy > absolute no business with PREEMPT_RT! I do only some strategic work > for a potential usage of PREEMP_RT ... hope this solves your > problem. I have no problem with that. Just your website offerings tell a different story. http://bit.ly/1pIsqca The topmost link says: Steinhoff Automations & Feldbus-Systeme www.steinhoff.de/ FIELDBUS PAGE for OPEN CONTROL system DACHS from STEINHOFF, ... all DACHS products are offered for QNX, and Standard & PREEMPT_RT Linux ! If I'm not completely mistaken, that's your website. So you are offering commercial solutions based on PREEMPT_RT. Whether that offerings generate a business for you or not is completely irrelevant. Whether you are doing only strategic work for your already existing offerings or not is equally irrelevant. Thats merily your problem. I really do not care about your business at all. What I care about is your abusive behaviour that a community mailing list has to bear with. > I'm working since 25 years wit QNX and other classical real-time > operation systems. I did also operating system development for many > years ... but before the first LINUX version was released. So be > careful to tell me something about "incompetence" ... I'm really not in a position to judge your competence. I merely care about facts. - Fact is that you ignored any advise and any hints given to you and insist that the community has to bear your 'quite normal theories'. - Fact is that you seek community advise, but then you state: "Sorry for not bothering about the confusing handling of priorities within LINUX ..." So we are supposed to help you while you refuse to understand how it works? - Fact is that you said: >> Hint #2: linux/REPORTING-BUGS > OK ... still TODO AFAICT this is still on your todo list, right? - Fact is that you said in response to Carsten: Carsten: "5. At a given time, you start your application that apparently modifies task priorities *in some way*." You: "Not in some way ... the developers of the openPOWERLINK stack are using plain POSIX calls." Nothing wrong with that, just I cannot figure out why the usage of plain posix calls has anything to do with the wrong usage of posix calls? And as I showed above this is a case of plain wrong usage of posix calls. - Fact is that the executable you provided issues a syscall which causes a siutation which you claimed to be either a problem of the kernel or a problem of the ps utility. - Fact is that I decoded the issue without having access to the source code within a few minutes. - Fact is that you failed to decode the issue despite of having access to the source code of the application. - Fact is that the community provided source code does not have this issue. - Fact is that is was obvious that "problem starts after doing X" has to be related with X. You have have been told so, but you deliberately decided to to ignore that advise. - Fact is that you claim publically that I'm suffering of reality distortion. See above and then make further claims at your leisure. Thanks, tglx ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-07 1:33 ` Thomas Gleixner @ 2014-10-07 7:57 ` Armin Steinhoff 2014-10-09 8:35 ` Operation not permitted / pthread_setschedparam / EOD Armin Steinhoff 1 sibling, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-07 7:57 UTC (permalink / raw) To: Thomas Gleixner; +Cc: rt-users Thomas Gleixner schrieb: > On Mon, 6 Oct 2014, Armin Steinhoff wrote: > >> Sorry ... I got now time to read your test code and results in detail. >> Your test shows only the absence of failures in your "test" scenario. > Correct. So that proves that the kernel behaviour is correct, right? There is a complete bug report now in the alternet tree -> rt: 85681 --Armin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam / EOD 2014-10-07 1:33 ` Thomas Gleixner 2014-10-07 7:57 ` Armin Steinhoff @ 2014-10-09 8:35 ` Armin Steinhoff 2014-10-09 9:41 ` Pavel Vasilyev 1 sibling, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-10-09 8:35 UTC (permalink / raw) To: Thomas Gleixner; +Cc: rt-users Thomas Gleixner schrieb: [ clip] >that it is calling setpriority() with the arguments > which = 2 (PRIO_USER) > who = 0 (root) > prio = 0x14 (20) >And that's exactly what is causing your problem. OK, thanks a lot!! I jumped back to PREEMPT_RT after several years and wonder: - why isn't on kernel.org a direct link to this project? There is only a reference to an outdated page of RTwiki - why is in the "latest News" of RTwiki (from 2012 / Reporting Bugs)) mentioned: "As always, please search the existing bug list and consider posting the issue to the linux-rt-users <https://rt.wiki.kernel.org/index.php/Mailinglists> mailing list before opening a new defect." ? Do we have to add: "If you do so, you must be prepared to get personal attacks from kernel developers ?? - why is it neccessary to scroll down 4 screens of a 27" monitor to find the released "vanilla" kernels in 3.x? I gave up after the second screen and used then a "testing" kernel -> and that's at the end the root of the chaos! Are you sure that the current representation of the PREEMPT_RT project will convince customers or developers to use it? Next station in my test work is Minix 3.0: true mikrokernel system, drivers in user space ... --Armin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam / EOD 2014-10-09 8:35 ` Operation not permitted / pthread_setschedparam / EOD Armin Steinhoff @ 2014-10-09 9:41 ` Pavel Vasilyev 2014-10-09 12:22 ` Crowd Funding ? Armin Steinhoff 0 siblings, 1 reply; 27+ messages in thread From: Pavel Vasilyev @ 2014-10-09 9:41 UTC (permalink / raw) To: Armin Steinhoff, Thomas Gleixner; +Cc: rt-users 09.10.2014 12:35, Armin Steinhoff пишет: > - why isn't ... > - why ... > - why is it > Are you sure http://article.gmane.org/gmane.linux.rt.user/12370 :D -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Crowd Funding ? 2014-10-09 9:41 ` Pavel Vasilyev @ 2014-10-09 12:22 ` Armin Steinhoff 2014-10-09 21:59 ` Richard Weinberger 0 siblings, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-10-09 12:22 UTC (permalink / raw) To: pavel, Thomas Gleixner; +Cc: rt-users Thanks Pavel, > http://article.gmane.org/gmane.linux.rt.user/12370 If the supporter of the mainline are not really interested, why not create a "crowd fundig" for a RT distribution and a neccessary development team ?? Well, it would be a fundig which makes really sense ... --Armin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Crowd Funding ? 2014-10-09 12:22 ` Crowd Funding ? Armin Steinhoff @ 2014-10-09 21:59 ` Richard Weinberger 2014-10-10 12:14 ` Armin Steinhoff 0 siblings, 1 reply; 27+ messages in thread From: Richard Weinberger @ 2014-10-09 21:59 UTC (permalink / raw) To: Armin Steinhoff; +Cc: Pavel Vasilyev, Thomas Gleixner, rt-users On Thu, Oct 9, 2014 at 2:22 PM, Armin Steinhoff <armin@steinhoff.de> wrote: > Thanks Pavel, > >> http://article.gmane.org/gmane.linux.rt.user/12370 > > If the supporter of the mainline are not really interested, why not > create a "crowd fundig" for a RT distribution and a neccessary > development team ?? > > Well, it would be a fundig which makes really sense ... Did you ran out of potato salad? ;-) -- Thanks, //richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Crowd Funding ? 2014-10-09 21:59 ` Richard Weinberger @ 2014-10-10 12:14 ` Armin Steinhoff 2014-10-11 10:04 ` Armin Steinhoff 0 siblings, 1 reply; 27+ messages in thread From: Armin Steinhoff @ 2014-10-10 12:14 UTC (permalink / raw) To: Richard Weinberger; +Cc: Pavel Vasilyev, Thomas Gleixner, rt-users Richard Weinberger schrieb: > On Thu, Oct 9, 2014 at 2:22 PM, Armin Steinhoff <armin@steinhoff.de> wrote: >> Thanks Pavel, >> >>> http://article.gmane.org/gmane.linux.rt.user/12370 >> If the supporter of the mainline are not really interested, why not >> create a "crowd fundig" for a RT distribution and a neccessary >> development team ?? >> >> Well, it would be a fundig which makes really sense ... > Did you ran out of potato salad? ;-) Good point :-) If you get funding for hacking potatos to salad -> then it must be posible to get fundig for "hacking" Linux to RT Linux ( w/o having salad in mind :) ) It would be a shame if the german kernel professionals wouldn't be able to bring PREEMPT_RT to the commercial market ... for paying theire bills e.g.! ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Crowd Funding ? 2014-10-10 12:14 ` Armin Steinhoff @ 2014-10-11 10:04 ` Armin Steinhoff 0 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-11 10:04 UTC (permalink / raw) To: Richard Weinberger; +Cc: Pavel Vasilyev, rt-users, Thomas Gleixner Hi Crowd, crowd fundig against crowd working ? http://zuendfunk-netzkongress.de/programm/crowd-working/ --Armin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Operation not permitted / pthread_setschedparam 2014-10-04 12:36 ` Armin Steinhoff 2014-10-04 12:50 ` Armin Steinhoff 2014-10-04 23:56 ` Thomas Gleixner @ 2014-10-05 10:13 ` Armin Steinhoff 2 siblings, 0 replies; 27+ messages in thread From: Armin Steinhoff @ 2014-10-05 10:13 UTC (permalink / raw) To: Carsten Emde, Patrik Lundquist; +Cc: rt-users Armin Steinhoff schrieb: > Carsten Emde schrieb: >> Armin, >> >>> [..] But there are some sideeffects to other running >>> processes/threads related to their assigned priorities. Here is the >>> priority assignment after a fresh boot: ps -elf -> >>> Prio-After-OS-Restart.txt attached >>> >>> If the app "demo_mn_console" has started its first RT thread, a lot >>> of other processes/threads are jumping to the highest RT priority >>> 99!! Please have a look to: ps -elf -> Prio-after-app-start.txt >>> >>> Do we have a problem with the RT kernel ? Or is simply the ps >>> utility broken ? >> Let me try to summarize your observations and suspicions: >> 1. After booting your RT kernel, everything works as expected. > Yes, all seems to be OK. > >> 2. The ps utility works as expected. > Yes >> 3. There are no bug reports that the RT kernel autonomously and at >> random fiddles around with task priorities. > I have submited a bug report in the meantime. > >> 4. There are no bug reports that the ps utility - one of the most >> frequently used utilities - suddenly may start to display erroneous >> priority numbers. > A bug in the good old "ps" would be very unlikely. This statement is'nt correct ! The "ps -elf" command shows a lot of nonsense ... when I can trust the command "ps -e -L -o class,rtprio,pri,nice,cmd" there are no priority changes of other processes! But after start of the demo the command "ps -e -L -o class,rtprio,pri,nice,cmd" is swapping the values of "pri" of "nice" ... without changing theire values! What's going on here ?? However ,,, it's good to see that the problem seems not to be in the kernel ... --Armin ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-10-11 10:05 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-30 10:40 Operation not permitted / pthread_setschedparam Armin Steinhoff
2014-09-30 11:44 ` Harry van Haaren
2014-09-30 12:32 ` Armin Steinhoff
2014-09-30 17:22 ` Armin Steinhoff
2014-09-30 23:09 ` Thomas Gleixner
2014-10-01 7:27 ` Armin Steinhoff
2014-10-01 7:49 ` Patrik Lundquist
2014-10-02 8:02 ` Armin Steinhoff
2014-10-04 10:49 ` Carsten Emde
2014-10-04 12:36 ` Armin Steinhoff
2014-10-04 12:50 ` Armin Steinhoff
2014-10-04 23:56 ` Thomas Gleixner
2014-10-05 11:07 ` Armin Steinhoff
2014-10-05 11:47 ` Armin Steinhoff
2014-10-05 14:34 ` Armin Steinhoff
[not found] ` <54312C88.8060609@steinhoff.de>
2014-10-05 20:54 ` Thomas Gleixner
2014-10-06 8:03 ` Armin Steinhoff
2014-10-06 13:34 ` Armin Steinhoff
2014-10-07 1:33 ` Thomas Gleixner
2014-10-07 7:57 ` Armin Steinhoff
2014-10-09 8:35 ` Operation not permitted / pthread_setschedparam / EOD Armin Steinhoff
2014-10-09 9:41 ` Pavel Vasilyev
2014-10-09 12:22 ` Crowd Funding ? Armin Steinhoff
2014-10-09 21:59 ` Richard Weinberger
2014-10-10 12:14 ` Armin Steinhoff
2014-10-11 10:04 ` Armin Steinhoff
2014-10-05 10:13 ` Operation not permitted / pthread_setschedparam Armin Steinhoff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).