/etc/default/grub either needs to *not* mention preempt (default is
full) or have preempt=full. If you aren't experiencing any timing
glitches then you should be ok.
Ted.
On 2/19/23 8:53 PM, chuck elliot wrote:
I haven't noticed any problems but the current standard kernel in
Fedora 36 has:
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_VOLUNTARY=y
in /boot/config-$(uname -r)
does this need to be overridden in /etc/default/grub or in a kernel
rebuild ?
On 19/02/2023 5:19 pm, Ted Felix wrote:
Will, can you go through this first draft series of steps on the
problematic box and let me know if it finds the issue? Thanks.
Boot into the problematic kernel.
Confirm that it is a preemptible kernel.
$ grep -i config_preempt= /boot/config-$(uname -r)
CONFIG_PREEMPT=y
If you don't see "CONFIG_PREEMPT=y" then you need to install a
preemptible kernel.
Check the grub configuration to make sure nothing is specified on the
kernel command line related to preemption.
$ grep -i preempt /etc/default/grub
You should either see nothing or "preempt=full" along with possibly
other options. Anything else might mean trouble and requires a change
to your grub config.
Check for voluntary preemption. (Not sure how this fits into
everything, but it might cause problems and need some further
investigation.)
$ grep -i preempt_voluntary /boot/config-$(uname -r)
# CONFIG_PREEMPT_VOLUNTARY is not set
Ted.
On 2/19/23 11:48 AM, Ted Felix wrote:
On second thought... We've been here before. From my Linux MIDI
Guide:
--------
Note: There are variations on PREEMPT that are less than ideal.
"DYNAMIC_PREEMPT" allows PREEMPT to be turned on and off in the
kernel command line options (preempt=full). You'll need to check your
GRUB configuration to make sure this is either set to "preempt=full"
or not set at all (the default is "full") in
"GRUB_CMDLINE_LINUX_DEFAULT=". You can check the setting after boot
with "sudo dmesg | grep preempt". There is also PREEMPT_VOLUNTARY
which is somewhere between "NONE" and "PREEMPT". You'll want to avoid
this as audio requires the best possible real-time performance.
--------
I should probably make that a bit more prominent now that we are
running into it for real. Like move it up to the "things you'll
need" section at the very top.
Ted.
On 2/19/23 8:52 AM, Ted Felix wrote:
We rely completely on ALSA for timer stuff. The key routine for
setting the timer in RG is:
AlsaDriver::setCurrentTimer()
Unless there is a bug in there (which there may very well be, the
ALSA documentation is incomplete and in many cases incorrect), the
problems tend to be due to bugs in ALSA or the kernel. They usually
get sorted over time by the ALSA folks. If they notice them. This
one seems like an interesting combination of requirements to
reproduce and thus might fly under their radar.
I recommend building the latest kernel and seeing if that fixes
the issue. My three-year-old Debian/Ubuntu oriented notes are here
if you need:
http://www.tedfelix.com/linux/kernel-build.html
In general, it's really easy to do.
If it's still there, a bug report for the ALSA folks seems like
the way to go. They can help find the issue in ALSA, or even in
Rosegarden if that's where the problem is.
Ted.
On 2/11/23 4:42 AM, Will Godfrey wrote:
Recently I found Rosegarden was losing the timer source, and the
transport was
freezing - sometimes for nearly a second after which it would send
a bunch of
notes, then carry on as normal.
It was some time before I realised it only happened on my Ryzen 5
machine (the
one I use for music) and not on my office Intel one. I hadn't made
any changes
to the system and got sidetracked into thinking maybe I'd somehow
managed to
get infected with some malware. However I eventually remembered I'd
done a
normal devuan update. The only significant change was the Linux
kernel V5.10 to
V 6.1. Rolling that back cured the problem.
Asking some questions on-line identified the problem.
First off, I use the RT-Preemt kernel - the 'normal' one doesn't
have the issue
at all.
Secondly, the Ryzen has the AMD equivalent of hyper-threading, my
older Intel
doesn't.
Finally, since Linux V5.12 the scheduler has been modified to allow
dynamic
preemption. Disabling this in the BIOS cures the problem, albeit
with a very
small loss of performance.
I wonder if there should be another look at how Rosegarden does
it's timing. I
did try to set the timing source to the audio hardware. It seemed
to recognise
it, but actually totally ignored it. Saving and reloading showed no
time source
at all, yet still ran as if it was on System Timer.
_______________________________________________
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to
unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
_______________________________________________
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to
unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
_______________________________________________
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
_______________________________________________
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
_______________________________________________
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user