Just out of interest: why are you trying to run jack as root?
Gerald

On 06.06.2015 23:08, Tito Latini wrote:
> On Sat, Jun 06, 2015 at 03:35:16PM +0100, Harry van Haaren wrote:
>> On Sat, Apr 4, 2015 at 8:13 PM, Adrian Knoth <a...@drcomp.erfurt.thur.de>
>> wrote:
>>
>>> Not enough information. I recommend starting jackd with strace
>>>
>> Done - apologies for the delay. Strace output available[1], but the most
>> interesting part copied here:
>>
>> sched_get_priority_min(SCHED_FIFO)      = 1
>> sched_setscheduler(0, SCHED_FIFO, { 1 }) = -1 EPERM (Operation not
>> permitted)
>> write(2, "\nJACK is running in realtime mod"..., 87
>> JACK is running in realtime mode, but you are not allowed to use realtime
>> scheduling.
>> ) = 87
>>
>>
>>
>>> This code tries to call sched_setscheduler() with SCHED_FIFO. My bet is
>>> that your "almost vanilla kernel" fails to fulfil this request, but
>>> strace will tell you for sure.
>>>
>> By "almost vanilla" I meant the Arch linux packaged version - I didn't
>> change the config myself (and Arch aims to be true to vanilla). A very
>> accurace prediction though - indeed sched_setscheduler() is causing a
>> return of -1. This is running as root though - so something is wrong here.
>>
>>
>>> The question is why said call should fail. The only thing that comes to
>>> my mind are CGROUPS. Maybe your old kernel comes without, the new kernel
>>> supports them and the configuration is set in a way that disables
>>> SCHED_FIFO by default.
>>>
>> Perhaps - I'm not experienced with cgroups or such, if anybody has any test
>> ideas for me I'll try them out?
> No tested but perhaps the follow lines in __sched_setscheduler
> (linux-3.19.8/kernel/sched/core.c) are relevant:
>
> #ifdef CONFIG_RT_GROUP_SCHED
>               /*
>                * Do not allow realtime tasks into groups that have no runtime
>                * assigned.
>                */
>               if (rt_bandwidth_enabled() && rt_policy(policy) &&
>                               task_group(p)->rt_bandwidth.rt_runtime == 0 &&
>                               !task_group_is_autogroup(task_group(p))) {
>                       task_rq_unlock(rq, p, &flags);
>                       return -EPERM;
>               }
> #endif
> #ifdef CONFIG_SMP
>               if (dl_bandwidth_enabled() && dl_policy(policy)) {
>                       cpumask_t *span = rq->rd->span;
>
>                       /*
>                        * Don't allow tasks with an affinity mask smaller than
>                        * the entire root_domain to become SCHED_DEADLINE. We
>                        * will also fail if there's no bandwidth available.
>                        */
>                       if (!cpumask_subset(span, &p->cpus_allowed) ||
>                           rq->rd->dl_bw.bw == 0) {
>                               task_rq_unlock(rq, p, &flags);
>                               return -EPERM;
>                       }
>               }
> #endif
>
>
> However I'm using 3.10 compiled without CONFIG_RT_GROUP_SCHED and the
> second `#ifdef' (CONFIG_SMP) is not present in the source code.
>
> Hypothesis: the second condition fails
>
>   => disable the bandwidth management logic (the default is 950000):
>
>      echo -1 > /proc/sys/kernel/sched_rt_runtime_us
>
>      More info about sched_rt_runtime_us:
>
>        scheduler/sched-rt-group.txt: "2.1 System wide settings"
>        scheduler/sched-deadline.txt: "4.1 System wide settings"
>
> If it continues to fail and your kernel is compiled with
> CONFIG_RT_GROUP_SCHED, you could recompile it without this
> configuration option (if you don't use realtime group scheduling).
>
> Oh, if it continues to fail, see the other branches with `return -EPERM'
> in __sched_setscheduler.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Reply via email to