| Eickmeyer | Gdflk7sj | 00:19 |
|---|---|---|
| Eickmeyer | Dang dog... | 00:19 |
| OvenWerks | cool, what is the official speed of your cpu? | 02:36 |
| OvenWerks | Eickmeyer: is your cpu rated at 2.6G then? | 02:37 |
| Eickmeyer | 2.6Ghz | 02:37 |
| Eickmeyer | Turbo boost goes to 3.3Ghz | 02:38 |
| OvenWerks | Ya, I see that, my boost is much lower compared to normal | 02:39 |
| OvenWerks | Mine is 3.2 but goes only till 3.6 (I think) | 02:39 |
| Eickmeyer | My new machine is 3.4 boost to 3.9. | 02:40 |
| OvenWerks | My son's is something like that too. | 02:41 |
| OvenWerks | Basically, in intel speak, Your default setup is boost on and CPU controls the speed | 02:42 |
| OvenWerks | This the same as intel boost on and powersave. | 02:42 |
| Eickmeyer | Soooooo... basically, AMD controls everything, including the governor. | 02:43 |
| OvenWerks | It looks like we can turn turbo boost off, but not set governor to OS control... with the kernel you have | 02:44 |
| Eickmeyer | Strange, used to be able to do that. I wonder what changed. | 02:44 |
| OvenWerks | First of all, a scaling driver has to be registered for CPUFreq to work. It is only possible to register one scaling driver at a time, so the scaling driver is expected to be able to handle all CPUs in the system. | 02:46 |
| Eickmeyer | Gotcha. I might check a different install to see if there's an issue. If not, then it's likely my install got borked somehow. | 02:47 |
| OvenWerks | Al,ost like the module that got loaded was the wrong one for the cpu | 02:47 |
| OvenWerks | The page I am reading is for kernel 4.15... which happens to be what we have in 18.04. My liquerix is a 5.4 | 02:49 |
| Eickmeyer | Clean install has same issue. I'm guessing the module got removed from Ubuntu or the kernel. | 02:51 |
| OvenWerks | If you encounter a problem while using this driver, add intel_pstate=disable to your kernel line. | 02:55 |
| OvenWerks | The module you should find is acpi-cpufreq | 02:58 |
| OvenWerks | So far as I can tell we don't ship that... I see: amd_freq_sensitivity.ko p4-clockmod.ko speedstep-lib.ko | 03:00 |
| Eickmeyer | Just modprobed that and no response, so assuming OK. intel_pstate=disable was added to the command line. Still showing 'no or unknown cpufreq driver is active on this CPU'. | 03:00 |
| OvenWerks | does lsmod |grep amd | 03:01 |
| OvenWerks | show anything | 03:01 |
| Eickmeyer | https://paste.ubuntu.com/p/Dcx5jyDDDk/ | 03:01 |
| OvenWerks | so modprobe amd_freq_sensitivity does that help or work? | 03:03 |
| Eickmeyer | still no or unknown cpufreq driver | 03:03 |
| OvenWerks | does lsmod |grep amd show it loaded? | 03:04 |
| Eickmeyer | Yep, shows loaded. | 03:07 |
| OvenWerks | and the first line of cpupower frequency-info | 03:10 |
| OvenWerks | doesn't show that as the driver? | 03:10 |
| OvenWerks | (mine says: driver: intel_pstate | 03:10 |
| Eickmeyer | https://paste.ubuntu.com/p/4kGwVJwrwZ/ | 03:11 |
| Eickmeyer | That's exactly what it shows. | 03:11 |
| OvenWerks | no driver | 03:12 |
| Eickmeyer | Exactly. Something in 19.10 got screwed up. | 03:12 |
| Eickmeyer | Confirmed with two different installations. I might up this one to 20.04 to see if that changes anything. | 03:13 |
| OvenWerks | sounds like a kernel bug | 03:13 |
| Eickmeyer | Right. | 03:13 |
| OvenWerks | which release did it last work with? | 03:13 |
| Eickmeyer | It definitely worked in 19.04. | 03:14 |
| OvenWerks | liquerix includes acpi-cpufreq.ko | 03:15 |
| OvenWerks | *liquorix | 03:16 |
| OvenWerks | Eickmeyer: for the generic kernel maybe this is not a problem but for lowlatency work it matters | 03:17 |
| Eickmeyer | OvenWerks: Agreed. | 03:27 |
| Eickmeyer | I'm prepping my machine to upgrade to Focal. | 03:28 |
| OvenWerks | I may do that as well | 03:29 |
| Eickmeyer | I'm also opening autobuilds for focal. | 03:29 |
| OvenWerks | Ok, controls bug 1 and two fixed (pulseout remove button works now, displaying no bridge works and does not error. | 04:09 |
| ubottu | bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 | 04:09 |
| OvenWerks | :) thankyou ubottu | 04:10 |
| OvenWerks | Eickmeyer: With regard to connections for pulse. A simple number still works. For example 1 is the same as system:capture_1 (and _2) (or playback) | 04:12 |
| Eickmeyer | OvenWerks: That's still not intuitive. | 04:12 |
| OvenWerks | :) no | 04:12 |
| OvenWerks | but it is there. I an thinking that for the first bridge set up that should be the default | 04:13 |
| Eickmeyer | Agreed. | 04:13 |
| OvenWerks | to be honest, I am not sure what would be intuitive | 04:13 |
| OvenWerks | (that is at the same time reasonably easy to do) | 04:14 |
| Eickmeyer | A drop-down with only hardware connections. No software, let patchbay software handle that. | 04:15 |
| OvenWerks | And not midi | 04:17 |
| Eickmeyer | Right. | 04:17 |
| OvenWerks | That would mean it could only be set if jack is actually running | 04:18 |
| Eickmeyer | Well, you could also make that a process where it sets right after Jack is started. | 04:20 |
| Eickmeyer | However it was being done before was perfect. | 04:21 |
| OvenWerks | Yes but... many people would expect to be able to set this before starting jack. | 04:21 |
| OvenWerks | The way it was done before only dealt with the default output which was expected to go to jack master. It also used two entries | 04:23 |
| OvenWerks | This will need some thought | 04:23 |
| OvenWerks | There are people who want more than what we had before | 04:24 |
| Eickmeyer | Then they need to use a patchbay. There's a reason we have a shortcut to Carla. | 04:24 |
| OvenWerks | Eickmeyer: Not the connection so much as number of bridges and naming | 04:25 |
| Eickmeyer | The bridges and the naming is going in a good direction. Just the default connections? That needs to be intuitive. | 04:26 |
| OvenWerks | Ya, I know. | 04:26 |
| Eickmeyer | Naming can be arbitrary. But the default connections cannot. | 04:26 |
| OvenWerks | Anyway, There are a few things to fix first | 04:28 |
| Eickmeyer | Yep. | 04:28 |
| Eickmeyer | I do like where it is going. It looks good, things are categorized... it's looking good. | 04:29 |
| OvenWerks | I think I might just do system:* and have a drop down that goes from 1-2 to 15-16 or 31-32. I will make the system:capture part of the label | 04:37 |
| Eickmeyer | That might work. | 04:37 |
| OvenWerks | (when jack is not running) when jack is running we can rebuild to the actual number the device has. | 04:38 |
| Eickmeyer | Not a bad idea! | 04:38 |
| OvenWerks | BTW, I am not going to worry about AMD cpu speeds at this point. I think it is straight driver problems and not something I can really work on. | 04:41 |
| Eickmeyer | Yeah, I agree. | 04:42 |
| Eickmeyer | Just updated to Focal, we'll see what's going on. | 04:42 |
| Eickmeyer | Nope, same issue. | 04:50 |
| OvenWerks | two bug reports? or one | 04:51 |
| Eickmeyer | Just the cpufreq issue | 04:51 |
| OvenWerks | Should be a bug report agaist 19.10 that is still there in 20.04 | 04:51 |
| Eickmeyer | I'm not even looking at -controls right now. No cpufreq driver still in 20.04. | 04:53 |
| OvenWerks | right, that is where the bug should be | 04:53 |
| OvenWerks | -controls just deals with what the os gives it.... which is nothing in this case | 04:54 |
| Eickmeyer | OvenWerks: Just filed bug 1856440 against the kernel in 20.04. I doubt any bug will get fixed and backported for 19.10. | 05:17 |
| ubottu | bug 1856440 in linux (Ubuntu) "cpufreq: no or unknown cpufreq driver" [Undecided,New] https://launchpad.net/bugs/1856440 | 05:17 |
| OvenWerks | Eickmeyer: I have fixed the errors with no pulse bridges on one side or the other | 05:45 |
| OvenWerks | I have not yet fixed the connection display. but I need to do other things so I pushed what I have. | 05:46 |
| Eickmeyer | OvenWerks: Cool | 05:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!