Bug#944589: gsequencer: stalls system
Hi,
I was just able to reproduce "gsequencer stalls system" while
using realtime priorities.
If you want to use GSequencer might be you have to revert
the modifications in:
/etc/security/limits.d
thank you for reporting the bug.
regards,
Joël
On Wed, Nov 27, 2019 at 6:11 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
>
> Hi,
>
> Since your CPU has enough power, I think you did some insane modifications to
> /etc/security/limits.conf and related. Could you provide a tarball
> with the contents
> of:
>
> /etc/security
>
> Please, share your processes attach a file with the output of:
>
> `ps aux`
>
> It would be nice if you could provide a stack-trace of the running
> GSequencer process:
>
> `gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p
> $(pidof gsequencer)`
>
> regards,
> Joël
>
> On Wed, Nov 27, 2019 at 5:53 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
> >
> > Hi,
> >
> > Just installed linux-image-rt from bpo, and I am not able to reproduce
> > the behavior ...
> >
> > I am using an Intel 4 Core CPU, too.
> >
> > Please, tell me about your modifications to:
> >
> > /etc/security/limits.conf
> >
> > best regards,
> > Joël
> >
> > On Wed, Nov 27, 2019 at 5:28 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Please stay on topic.
> > >
> > > On Wed, Nov 27, 2019 at 1:42 AM westlake <westlake2012@videotron.ca> wrote:
> > > >
> > > > the system here sets RT for the applications without issue,
> > > >
> > >
> > > Might be but its not related as told you prior.
> > >
> > > > "$ pgrep -fa jack
> > > > 1717 /usr/bin/jackdbus auto
> > > > $ chrt -a -p 1717
> > > > pid 1717's current scheduling policy: SCHED_OTHER
> > > > pid 1717's current scheduling priority: 0
> > > > pid 1959's current scheduling policy: SCHED_OTHER
> > > > pid 1959's current scheduling priority: 0
> > > > pid 1960's current scheduling policy: SCHED_FIFO
> > > > pid 1960's current scheduling priority: 25
> > > > pid 1961's current scheduling policy: SCHED_OTHER
> > > > pid 1961's current scheduling priority: 0
> > > > "
> > > >
> > > > "
> > > > $ pgrep -fa ardour-5.12
> > > > 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> > > > $ chrt -a -p 7358
> > > > pid 7358's current scheduling policy: SCHED_OTHER
> > > > ..
> > > > pid 7415's current scheduling policy: SCHED_FIFO
> > > > pid 7415's current scheduling priority: 20
> > > > pid 7424's current scheduling policy: SCHED_FIFO
> > > > pid 7424's current scheduling priority: 71
> > > > "
> > > >
> > >
> > > And? Probably due to settings in /etc/security/limits.conf
> > >
> > > >
> > > > the system does not show anything pulseaudio here,
> > > > "$ pgrep -fa pulseaudio
> > > > $
> > > > "
> > >
> > > If you don't tell GSequencer to use ALSA explicit DBUS may start pulseaudio.
> > >
> > > >
> > > > I do have alsarawjack set for applications that want to connect to jack,
> > > > so here alsa is already being used in this configuration. (~/.asoundrc)
> > > >
> > > > The ags.conf file you provided was tested with and it still causes
> > > > failure even without jack and not configuring alsarawjack..
> > > >
> > > > The rtkit-daemon.service is running, and limits.conf is set as it is
> > > > supposed to for @audio group..
> > > >
> > > > The stall occurs with both a custom kernel as well as a bpo-stocked one
> > > > from debian.. both 5.2.x kernels..
> > > >
> > > > Other applications can get their requested process/threads elevated to RT...
> > > >
> > > > spotted on the ags website,
> > > >
> > > > "systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p
> > > > TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false
> > > > --scope gsequencer"
> > > >
> > > > would not make a difference because these would need be set specifically
> > > > for Debian(cgroups), and I suppose it is for the other mainstream
> > > > distributions as well.
> > > >
> > > > ags was tried with various audio settings, different kernels- same error
> > > > message. the bug must be in ags because all other RT applications here
> > > > can be set with rt priority.
> > >
> > > It is NOT AN ERROR.
> > >
> > > >
> > > > recap:: The stall occurs with both a custom kernel as well as a
> > > > bpo-stocked one from debian.. both 5.2.x kernels. The CPU is plenty
> > > > resourceful with 4-core "Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz" with
> > > > 8 gigs ram. The ags software has caused more than 12 stalls. --
> > > > filesystem checks and other extra things were tried to see if it can
> > > > load past the plugin-loading stage.
> > > >
> > >
> > > Well I am going to look at the BPO kernel.
> > >
> > > Do you have linuxsampler installed? If so try to blacklist its LV2 plugin.
> > >
> > > Try to start GSequencer like following and make sure the
> > > the file $HOME/.gsequencer/ags.conf is provided as prior told:
> > >
> > > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" pasuspender -- gsequencer
> > >
> > > And tell me if it stalls?
> > >
> > > > If someone knows how to fix this, feel free to give it a look.
> > > >
> > >
> > > cheers, Joël
Reply to: