aluveitie
commented
4 years ago Thanks for the detailed report. I've run into the same issue, 15-30min after sleep MacOS completely froze. #70 fixed that issue for me, no panic in the last two weeks.
Open nehbit opened 4 years ago
aluveitie
commented
4 years ago Thanks for the detailed report. I've run into the same issue, 15-30min after sleep MacOS completely froze. #70 fixed that issue for me, no panic in the last two weeks.
nehbit
commented
4 years ago Thank you! Yes, you're correct, I'm also having the complete freeze, updated the report as such. I'll try and report back whether it makes a difference.
nehbit
commented
4 years ago I've compiled your sleep-restore-state branch and it has not crashed after sleep for the past hour just yet. However, the AMDPowerGadget says No AMDRyzenCPUPowerManagement Found! and quits. Is this supposed to happen, or did I make a mistake in the compile process? I don't usually use Xcode or Swift, so it's quite possible that I did.
aluveitie
commented
4 years ago All fine, the branch is based on an older state that is probably not compatible with the latest version of the gadget. I can update it tomorrow.
nehbit
commented
4 years ago Thank you! It'd be great — the power gadget is quite nice to have access to.
aluveitie
commented
4 years ago I've rebased the pull request to latest master. With that the latest AMDPowerGadget should work again.
nehbit
commented
4 years ago I got a chance to compile + run your rebased version — for some reason it still doesn't appear to be compatible with the app, not entirely sure why. (I pulled the updates to the branch on your repo, not sure if there's a way to pull directly from a pull request)
aluveitie
commented
4 years ago Right, the last release is a little behind master. I'm also using a modified version of the App. You could just build the App from latest master/my branch too, that will work.
nehbit
commented
4 years ago Good idea, I should do that.
By the way, I discovered that the 'Automatic Speed Adjustment' setting on the app shaves a good 150 points off the machine's Cinebench R15 score (Enabled: 1570~, disabled, 1750~). Reading the description a little closely, it does make sense, but it's a little unintuitive considering that it does not appear to actually slow down my 2700x at idle — the idle power consumption is around 30W, regardless of it is on or off. This is with the vanilla, non-patched version, not with the pull request.
aluveitie
commented
4 years ago The difference is small in idle as long as core performance boost is disabled. In idle my CPU at 33C independent of P-State, but if I've CPB enabled then it gets up to 50C in P0 without any load. In that case the power adjustment effectively disables boosting when idle.
It lowers benchmark scores a little yet it does not really affect real world usage. But it keeps the fans from spinning up all the time with CPB enabled.
nehbit
commented
4 years ago Interesting. I have CPB and CPB Overdrive enabled and maxed out. My idle temp is 40-41C, at which point fans are at the lowest possible rate. I've also set the CPU and chassis fans to ramp up aggressively, so at full load the CPU is at 145W with peaks at 155W, and the temperature stabilises around 74C at 100% on all cores.
My work involves hammering the CPU with hundreds of compiles every day, so even shaving a few seconds off each is meaningful improvement.
Compared to the 2015 Macbook Pro I was using just two weeks ago it's definitely been worth the pain getting it working, though. 🙂
trulyspinach
commented
4 years ago There should not be any difference for your compilation jobs. Cinebench is very sensitive when your score is high enough. If I were you I would not worry too much about few hundred difference in Cinebench score when it is already above 7000. In fact I feel like compilation will most likely cap by IO unless every single of your source files is 10000 lines long :). The current configuration of this kext will for sure put all of your cores into the highest power mode when you compiling source codes. Just make sure you also have CPB enabled.
nehbit
commented
4 years ago I did some totally non-scientific testing with a part of our pipeline. Here are the results:
Webpack at High
88558ms
87616ms
88848ms
88340 avg
= 100% speed
Webpack at Auto
87455ms
88303ms
90114ms
88624 avg
= 99.6% speed
Difference
High is faster by
%0.4In essence, you're right. Subjectively speaking, having it on High all the time does feel slightly more responsive but I'm almost certain that's placebo.
Edit / more context: What is of note, though, is that my Macbook Pro 2015 with i7-4870HQ is also completing the task at around 90 to 100 seconds bracket as well, but the systems are worlds apart in responsiveness in almost any other task, or when doing other tasks while this compile is going.
Interestingly, Ryzen retains most of its snappiness from its 'unloaded' state even when I'm running make as another part of our compile pipeline on 16 logical cores at 100% utilisation, while doing the same on my MBP2015 at 8 logical cores largely renders the machine unusable for the duration, gasping for air. I guess raw clock-speed is not the only difference between those cores — for the lack of a better word, Ryzen feels like it has much more breathing space in its compute pipeline than my laptop, even if on paper, on a single-core task they perform almost exactly the same.
trulyspinach
commented
4 years ago It is too hard to control other factors. OS can schedule some other task to do at any time. And a higher CPU temp could also have negative effect on CPB performance.
When you've mention compiling thing I thought it is CMake projects, etc. I don't have many experience with Webpack but from my limited experience i believe that it was running mostly in a single thread. And maybe it will fetch something from internet that will slow down the speed? You will see a huge different if you compile some big C project like XNU kernel :) That is the main reason I love this new Ryzen processor so much.
nehbit
commented
4 years ago Yes, Webpack is entirely single threaded but it doesn’t download things in the compile process. It’s only a party of our compile process though, we have a lot of native binaries emitted from make / clang as well.
nehbit
commented
4 years ago Bringing this issue back to the spinlock crash I've been experiencing, I've discovered that the reason why the app wasn't seeing the kext isn't the version mismatch ... but because the compiled kext wasn't being loaded. /facepalm.
@aluveitie, do you have any idea why the kext would not load? It compiles fine with no errors, and appears to generate well-formed build artifacts. It just seems that they're not being loaded when fed into the appropriate EFI/Clover folder.
I've also managed to pinpoint this spinlock issue (which happened for the 6th time today, I have the crash reports if needed) to it happening after a sleep, and the pair of kexts from this repo being loaded. If they are not, the spinlock crash does not happen, with or without sleep. If they are, it always happens, though the time it happens varies fairly wildly, between 0 to ~3 hours after wake from sleep. It you wake the computer in the morning from sleep, within the day it will certainly crash once with a full screen freeze due to spinlock, usually before noon.
To make the kexts load I checked their code signatures, and tried them with their code signatures removed as well. No dice, the compiled kexts are not being loaded. Any ideas why they might not be loaded? I'd normally check logs, but I don't know where the logs go for something that happens this early in the boot process, or even if the logs for this exists at all.
aluveitie
commented
4 years ago @nehbit I never used Clover so I have no idea. It always worked for me with OpenCore.
nehbit
commented
4 years ago I think it's probably something with my compile not being right because the releases from this (non-forked) repository work fine, it's just the ones I compile that have the issue. I'll spend some more time working on it I guess — could be something like a Lilu version mismatch. If you're inclined, it'd be super useful to have a compiled version of both kexts as a Github release on your fork, or to have this pull request merged so we can get the fix into the official repository and have official builds.
Anyway, thanks for all the help!
aluveitie
commented
4 years ago You could try mine: AMDRyzenCPUPowerManagement.kext.zip
(it also contains some minor modifications to the power management algorithm/default settings but that should not make any difference)
nehbit
commented
4 years ago I got yours in and it definitely loads now. Thank you. I'll report back in a few days to see if I've seen any more spinlock crashes. Should be fairly fast, I usually get one every day.
One interesting side effect is that after installing your kext, my CPU for the first time started to go below 3.7ghz — its idle power consumption dropped from 30~Watts to 13. Sweet! Though I'm not sure why this was not working with the unmodified kext.
aluveitie
commented
4 years ago My kext has automatic speed adjustment and lower power state enabled and CPB disabled by default.
nehbit
commented
4 years ago Interesting, then it's definitely working. I had the lower power states enabled already on the unmodified version but it had not made a difference. This time though, it actually does work. Oh well — let's see how this fares, shouldn't take much longer to figure out if it helps with the spinlock issues.
nehbit
commented
4 years ago Reporting back after two days and several sleep cycles. No spinlock crash since then, no performance regressions, everything seems fine, while the non-modified kext is reliably crashing after sleep. I recommend this pull request (#70) be merged if there are no other concerns.
Here are my system details:
aluveitie
commented
4 years ago @trulyspinach Since we didn't hear anything back it looks like with that pull requests it's working much better. Any chance to get that in?
trulyspinach
commented
4 years ago @aluveitie Sorry for the delay, I just have been very busy these days. I promise I will look into the merge ASAP :)
borygo77
commented
4 years ago @nehbit how did you hot this working with Clover? Can I have a look on your efi folder please? I just can't get it to work with clover despite system runs totally fine 🤔 Sorry to steal your topic 😉
Hi there,
Thanks for this kext — both the app and power management has been super useful. I've just experienced a kernel panic that could have been caused by this, just wanted to pass over the crash report.
Potentially relevant circumstances:
Here's the report below. Hope it's useful.