Re: Transport problem

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
>>> [email protected] - use the link below to 
>>> unsubscribe
>>> https://lists.sourceforge.net/lists/listinfo/rosegarden-user
>>
>>
>> _______________________________________________
>> Rosegarden-user mailing list
>> [email protected] - use the link below to 
>> unsubscribe
>> https://lists.sourceforge.net/lists/listinfo/rosegarden-user
>
>
> _______________________________________________
> Rosegarden-user mailing list
> [email protected] - use the link below to unsubscribe
> https://lists.sourceforge.net/lists/listinfo/rosegarden-user


_______________________________________________
Rosegarden-user mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user