Comment 42 for bug 36014

Revision history for this message
Constantine Evans (cevans) wrote :

Fjodor, throttling and scaling *are not the same*, as I noted before. Throttling has nothing to do with this bug. Please don't discuss it here.

John, I'm rather certain that the max_freq cannot be set manually. If max == min, then you probably have the race condition problem that this bug is discussing. If it doesn't resolve by itself, you could try commenting out the relevant checks in the kernel, as I discussed earlier in the bug. Your sudo command didn't work because of order-of-operations problems (what you wrote was essentially (sudo (echo 1)) > /file from an order of operation standpoint). But you might want to look into a howto on cpufreq operation, because it does not appear that you are going about setting it up in the right way.

fishwithapipe, your problem is not related to this bug.

slazZ, in the worst case, you can do what I discussed (I didn't post a patch because it was too much of a kludge):

"The problem occurs in the verification steps of __cpufreq_set_policy in cpufreq.c. If one comments out that (from after the memcpy to before the data->min = policy->min), cpufreq works fine."

If you look at that code, you should be able to find the portions that need to be commented out. If I recall correctly, the basic idea was to comment out the part where the driver checked the PPU for the maximum frequency it allowed.