Closed h1z1 closed 2 years ago
... Sure the clock was way out but the host was running fine.
Because the Kernel loops per jiffies need to calibrated again
In this Wiki page, I'm gathering the README instructions:
CoreFreq as the Clock Source, CPU Freq and CPU Idle driver
At that point CoreFreq is mastering and no other drivers should have switch Processor features on; you will drive from the various Client windows; like:
Processor>P-State>target
Technologies>Turbo
Kernel>Idle Limit
Not sure I follow, TGT was changed from within Corefreq :)
Not sure I follow, TGT was changed from within Corefreq :)
Great. You got no issue logged in kernel log ?
By the way, could you confirm if my provided code fix is working with your Atom ? Let me know if my instructions are unclear.
Great. You got no issue logged in kernel log ? Nothing besides the messages above.
By the way, could you confirm if my provided code fix is working with your Atom? Let me know if my instructions are unclear.
Not sure what that is in reference to, I don't have an atom :) If you mean the wiki page above, the drivers are loaded. Might want to add a note about cpuidle_sysfs_switch.
It will enable changing the driver while booted with cpuidle/current_governor
Looks like they removed the option because it's default now o_O So much for deprecation warnings sigh.. that parameter's behaviour has been like that since ... 2.6.22 .. 14 years
That host is not running 5.4.70
Great. You got no issue logged in kernel log ? Nothing besides the messages above.
By the way, could you confirm if my provided code fix is working with your Atom? Let me know if my instructions are unclear.
Not sure what that is in reference to, I don't have an atom :) If you mean the wiki page above, the drivers are loaded. Might want to add a note about cpuidle_sysfs_switch.
Oh sorry, I made a confusion among issues
It will enable changing the driver while booted with cpuidle/current_governor
Looks like they removed the option because it's default now o_O So much for deprecation warnings sigh.. that parameter's behaviour has been like that since ... 2.6.22 .. 14 years
That host is not running 5.4.70
I will check for cpuidle_sysfs_switch
, especially if it can be directly managed from my kernel module
I have gone through cpuidle_sysfs_switch
but considering current kernel version which comes without safe exported functions to achieve the same, I'm postponing the enhancement.
This is what you will get in the develop
branch: you switch the Clock Source from the box.
Fully acknowledge this may be a kernel bug but given it happened with corefreq can't hurt to start here..
Short version is I had a host with a system clock that was hours out of sync (unrelated to corefreq). Ran corefreq for shits'n giggles which appeared to be fine until trying to change the pstate target.. whole box acted like it did a clock jump and the kernel has permanently marked tsc as unstable
From what I gather that is coming from https://github.com/torvalds/linux/blob/e7c124bd04631973a3cc0df19ab881b56d8a2d50/kernel/time/clocksource.c#L408-L409
Have to reboot the host because hpet is godawful on zen. What I don't understand though is why it triggered? Sure the clock was way out but the host was running fine.