What is the expected cpu frequency behavior for a Core 2 Duo with Kernel > 4.14?
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am using a simple Core 2 Duo which is not i-anything, or *Lake whatever.
FWIW (OT), I have at least 7 working Core2Duo CPUs. Every one of them runs on a motherboard that incorporates an *Lake chipset. Yours probably does too.
For those who care about software freedom, Core 2 Duo is hardly "vintage hardware" - it's the newest you've got this side of a Rockchip Chromebook that has, oh, I don't know, no ethernet jack and one USB port.
You're clearly refering to something here - why don't you just spit it out? Afraid to get off your high horse?
Glad to see those reporting this as fixed. Indeed, I am not trying to run the latest kernel here - I've been sticking with the old LTS kernels, but once I tried out 4.14 I noticed this in a big way (otherwise 4.14 seems fine, as it *finally* fixes i915 on one of my laptops). So those jumping from 4.4.x to 4.19.x and beyond may never have noticed it.
There's no high horse here - I just care about openness and reproducibility. I get upset when people think that all "modern" computing necessitates > i3 processors which can't be used without management engines and other malicious nonsense, and it seems that's what the kernel developers must use personally or else bugs like this never would have gotten out. Likewise there is much effort for gpu drivers that are nowadays almost all cryptographically signed. So this newfangled Linux kernel, if you can call it that, is getting farther and farther away from it's first and foremost role as the kernel for the GNU operating system which has clearly different goals.
Not to mention, the performance increase from Core 2 Duo to i-whatever isn't necessarily that noticeable on most tasks, except that you get more cores and less power consumption.
Chromebooks which can be operated without any of this (like those usable with libreboot) are probably fine, but I just see that as a cell phone in a laptop case.
As for being reproducible, and I digress here, I first became slightly aware of its need a number of years ago in one of my mathematical programming classes. A graduate student pressed the professor on the appearance of a particular graph being projected on the wall. After going around and around, the professor threw up his hands and said "Mathematica says so." That's not acceptable in any mathematical sense. Likewise, I see even professional photographers yanking "exposure" sliders around freely in certain Adobe programs. This is mathematical nonsense, because all of these sliders are in-house, closed-source non-linear transformations. In documenting what you do, you can only say "In program X, version Y, move slider A from a to b." Regardless of whether libre programs like Gimp exist in the next millennium or can run on whatever hardware exists then, if you can write down what steps you used to manipulate an image, the mathematical instructions are transparent and can be ported over.
At least in principle with a libreboot bios, clean/sane kernel, open userspace programs, and honest (human) users, the steps to complete a task can be mathematically reproduced back to the moment the power button was pressed. In this sense these nowadays older chips that at least in principle could be used with libreboot and friends HAVE to work - these should be considered bench marks like the Sevres meter sticks and the like.
I get upset when people think that all "modern" computing necessitates > i3 processors which can't be used without management engines and other malicious nonsense, and it seems that's what the kernel developers must use personally or else bugs like this never would have gotten out.
In principle I agree here (I currently experience something similar with pango dropping support for Type 1 bitmap fonts), but OTOH I always thought that using hardware that is much older than 10 years is kinda pointless - well, at least that was my opinion when I started using Linux and tried A LOT of hand-me-down laptops. But then again, my 2008 32-bit laptop is still running strong as a server. I have never noticed any CPU issues (I would hear if the fan span constantly). But that one is just on the other side of the IME divide, unfortunately.
Well we're just now getting to the point that 10 year old hardware isn't that much different - when I got my first "new" laptop (up to 4 GB RAM, dual core, etc), I was replacing a desktop that initially came with 64 MB (which I upgraded to 256) and a 6 GB hard drive. Contrast 10 years prior to that, when Windows 2.1 was current.
Didn't know about the pango situation - looks like trouble on the line for my next BLFS build.
Distribution: slackware x86_64 , arm , slackware , AlmaLinux
Posts: 83
Rep:
RTFM again
Quote:
Originally Posted by ordealbyfire83
Really, I should start reading docs and mucking around with BIOS settings on a 10 year old laptop that worked perfectly until now?
The kernel documentation here explicitly states that the Linux kernel p-state driver is for Sandy Bridge and newer. This, from Wikipedia, means: "the codename for the microarchitecture used in the "second generation" of the Intel Core processors (Core i7, i5, i3)" which I stated in the original post that I am not using.
The instructions you describe such as using "dynamic scaling of frequencies from the p-states backend" isn't going to get exposed for a CPU that the kernel says can't support the p-state driver at all.
I also noticed recently that there's one or two active (not the old ones seen below) threads on very similar topics. "frequency scaling" might find them.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.