[02:33] Eickmeyer: in the controls package there seem to be some links do not get installed. [02:34] Eickmeyer: ln -s $(DESTDIR)$(LIBDIR)/systemd/system/studio-system.service \ [02:34] $(DESTDIR)$(LIBDIR)/systemd/system/multi-user.target.wants/studio-system.service [02:34] this link does not seem to be there [02:36] And so cpu governor and boost setting does not work over a boot [02:38] Eickmeyer: /lib/systemd/system/studio-system.service seems to get installed but not linked into multi-user.target.wants [03:41] OvenWerks: That's weird. I know there's one item in not-installed that was Fedora-specific. [03:43] OvenWerks: That systemd service file is for Fedora, not for Ubuntu. [03:45] OvenWerks: autojack is run by the user for Ubuntu. This is because On-Demand isn't a thing in non-Ubuntu systems. [03:46] OvenWerks: Basically, /usr/lib/systemd/system/studio-system.service is inconsequential to Ubuntu systems. [03:52] OvenWerks: You'll see from this commit that it was a file I created for non-Ubuntu systems: https://github.com/ovenwerks/studio-controls/commit/307cc3198644ea4bcea1281ff330a898eaab30e2 [03:52] Commit 307cc31 in ovenwerks/studio-controls "Add systemd service for non-Ubuntu systems" [03:53] The CPU governor boost setting should be getting set by the reading of the autojack.conf file when studio.service is activated by systemd. [03:53] Under the user profile. [03:53] There's a polkit file that keeps it from asking for a password. [03:54] If it's not working on your system, something else is interfering. I know on my system there are Kubuntu Focus-specific scripts that keep it from interfering because we make that for the hardware specifically. [03:55] Rather, the Kfocus scripts interfere because they're for the hardware specifically. [03:56] I know I had to put studio-system.service in not-installed on the AA's request. [04:02] Eickmeyer: ubuntu seems to have followed fedora... [04:02] is ondemand no longer a thing? [04:02] nope [04:02] that part is for older systems [04:04] I see it's not even there in Focal? [04:05] Got removed from under our noses. [04:05] I have been using 20.04 for my daily drive till a few months ago [04:06] I have a Focal system, stand by... [04:06] in other news it seems I was missusing .which so I will be uploading a fix [04:06] Ohhh yeah, good idea. [04:09] OvenWerks: ondemand.service was still a thing on Focal, apparently. With this, we would have to stop supporting studio-controls on Focal. [04:09] Or rather, not upload new versions to Backports. [04:10] (I was planning on freezing the Backports for Focal once Jammy releases anyhow, so probably no big deal). [04:27] OvenWerks: I've got a fix in the packaging ready to go. It removes the ondemand stuff, installs studio-system.service, and enables it. It disables it upon uninstall too. [04:40] ok, i will have the other fix soonish [04:41] OvenWerks: Ok, in that case are we looking at 2.2.10 or are we full-seinding to 2.3.0? [04:42] we can 2.3 it [04:42] Ok, bet. [14:56] Eickmeyer: ok 2.3.0 is out [14:57] Eickmeyer: in other news... try /etc/init.d/rtirq start and then /etc/init.d/rtirq status [14:58] something doesn't work. I am guessing that may be the reason I have less stability at 16/2 than in 20/04 [15:14] using sudo htop does not allow higher priority either [17:24] OvenWerks: My guess is because it's still using /etc/init.d instead of being a proper systemd service. For me it seems to be working fine after running those commands as sudo. [17:28] In other news, 2.3 is uploaded. [17:29] Thank you... can't dl it yet but soon I guess [17:39] Usually takes a couple hours to pass autopkgtests and what-not. [18:01] Eickmeyer: back to rtirq... all my audio devices used to show up in ps ax as [irq/*] they do not any more. [18:02] they don't show up at all [18:03] OvenWerks: Yeah, that's very odd. I'm seeing no issue on my system (two snd_hda devices, rest are USB) [18:04] Bear in mind, rtirq is ancient and hasn't been updated since 2015. [18:05] that is ok. I am just wondering about the change in irq drivers in the newer kernel. [18:08] And that could be a thing too. I know there's a lot of work around PREEMPT_RT. [18:08] The details about which I'm very fuzzy. [18:10] normally for me jackd would show up as priority higher than 50 as well. [18:11] maybe ALSA has changed to fit PW [18:20] 21.10 with 5.13 is still ok. So either 5.14 or 5.15 something has changed [18:23] Likely. [19:33] kernels are already up to 5.15.11 so maybe it has been fixed post 5.15.0 [20:31] Eickmeyer: I had to add threadirqs to the kernel command line. I thought that was set by default in lowlatency [20:51] OvenWerks: It is. I inserted it into your code that you made for grub.d [20:52] huh, I had to add it in /etc/default/grub [20:53] Weird. I see it in my /boot/grub/grub.cfg. [20:53] OvenWerks: Ohhhhhh yeah, it's hardcoded. You don't need to add it there. [20:53] That'll have the effect of adding it twice. [20:54] may not be hard coded any more [20:54] But, when you boot, go to any lowlatency kernel and edit the command, you'll see it's there. [20:57] Ah, I am not running this as the main parition. [20:57] That is probably why [20:58] That would 100% be why. :D [21:00] I don't know if I can... I will try though I don't install a separate /boot partition for efi [21:03] Well, you don't have to, but at the same time the EFI has to be mounted to /boot/efi as a FAT32 partition. [21:04] it isn't now [21:04] * OvenWerks didn't make one and just did install anyway [21:05] Yeah, if one's already available it'll just use it. [21:05] If not, it'll create one. [21:05] But the mount point has to be there. [21:05] A check of lsblk will show you. [21:06] I have swap, / and /home/extra [21:07] That sounds to me like you're running in MBR mode, aka non-EFI. [21:08] yes, that was what I said [21:09] I have lots of partitions that depend on that [21:10] Yeah, that's fine. If it's working then you're good. [21:12] The installer really wanted me to create a small directory for efi but I refused. So it won't boot to this from the top, I have to go down the list. [21:14] Ah, I see. [21:14] The installer is supposed to auto detect whether or not it's on EFI, but I think that was an upstream bug in Camamares that only recently got fixed. Like, in the past week. [21:21] The system can do efi, but the disk is older. [21:40] Yeah, you likely are running an MBR disk on an EFI system. [21:40] If you were to reformat the disk, you'd want to reformat it as GPT in order to take advantage of EFI. [21:41] The system can be set up either way. What are the advantages? [21:52] OvenWerks: EFI contains more security since an actor can't simply overwrite the first couple blocks of the drive (the Master Boot Record) to install malware.