Re: Operation not permitted / pthread_setschedparam

[Armin Steinhoff <armin@steinhoff.de>]

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