Spinlock acquisition timeout crash #84
Comments
|
Thanks for the detailed report. |
|
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. |
|
I've compiled your |
|
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. |
|
Thank you! It'd be great — the power gadget is quite nice to have access to. |
|
I've rebased the pull request to latest master. With that the latest AMDPowerGadget should work again. |
|
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) |
|
Right, the last release is a little behind master. I'm also using a modified version of the App. |
|
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. |
|
The difference is small in idle as long as core performance boost is disabled. 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. |
|
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. 🙂 |
|
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. |
|
I did some totally non-scientific testing with a part of our pipeline. Here are the results: In 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 |
|
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. |
|
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. |
|
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. |
|
@nehbit I never used Clover so I have no idea. It always worked for me with OpenCore. |
|
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! |
|
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) |
|
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. |
|
My kext has automatic speed adjustment and lower power state enabled and CPB disabled by default. |
|
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. |
|
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: |
|
@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? |
|
@aluveitie Sorry for the delay, I just have been very busy these days. I promise I will look into the merge ASAP :) |
|
@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 🤔 |
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.
The text was updated successfully, but these errors were encountered: