Same here, rollback to .35 and have a hold on that version until a fix
released. Behaviour aligns with comments on related thread - only when
passing through a PCIe GPU to a (linux in my case) guest. Drop the VM
back to QEMU graphics, serial terminal or other and this logspam does
not materialise.
Same symptoms here - on a [past history] stable system.
Experienced a system lockup with linux-image-5.4.0-40-generic yesterday,
while working at an x terminal ssh'ing into a remote host. Have rolled
back to linux-image-5.4.0-39-generic now.
Completely different hardware to your spec - AMD A10
Yes. It would appear that the fix/config change was not rolled into
5.4.0-33-generic. RT_GROUP_SCHED is still enabled in generic build but
not lowlatency kernel build.
twiggy@twiggy:/ $ zgrep CONFIG_RT_GROUP_SCHED /boot/config-5.4.0-33-generic
CONFIG_RT_GROUP_SCHED=y
twiggy@twiggy:/ $
Agreed - proposed fix in 5.4.0-32-generic also works for me.
twiggy2@twiggy2:~$ journalctl -b -u rtkit-daemon
-- Logs begin at Wed 2020-05-06 22:30:38 BST, end at Tue 2020-05-19 19:32:24
BST. --
May 19 19:32:11 twiggy2 systemd[1]: Starting RealtimeKit Scheduling Policy
Service...
May 19
Should this be fixed with a change to the kernel build config, or, is
this actually indicative of rtkit being not cgroup aware ?
I haven't considered the implications for configuring rtkit cgroup
aware, or even if it makes sense to. I.e. should each application that
requires RT scheduling be made
Attached is the output from journalctl -b 0, where the error occurs.
Apologies - no vagrant skills here, but I can confirm Kai's replication
method - kvm qemu clean 20.04 server install, then add pulseaudio,
docker.io, reboot and the issue occurs.
** Attachment added: "20.04 boot log showing
I have the same issue, 18.04 -> 20.04 via upgrade. RTKit now failing to
give pulseaudio RT priority.
Issue resulting is some choppy audio - under heavy load. Pulseaudio not
RT priority
20.04 clean install:
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
