Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1480221 > unrolled thread

Regression in 4.8 - CPU speed set very low

Back to article view | Back to linux.kernel

Contents

  Regression in 4.8 - CPU speed set very low Larry Finger <Larry.Finger@lwfinger.net> - 2016-09-09 19:40 +0200
    Re: Regression in 4.8 - CPU speed set very low Larry Finger <Larry.Finger@lwfinger.net> - 2016-09-14 18:10 +0200
      Re: Regression in 4.8 - CPU speed set very low Larry Finger <Larry.Finger@lwfinger.net> - 2016-09-19 05:00 +0200

#1480221 — Regression in 4.8 - CPU speed set very low

I have found a regression in kernel 4.8-rc2 that causes the speed of my laptop 
with an Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz to suddenly have a maximum cpu 
frequency of ~400 MHz. Unfortunately, I do not know how to trigger this problem, 
thus a bisection is not possible. It usually happens under heavy load, such as a 
kernel build or the RPM build of VirtualBox, but it does not always fail with 
these loads. In my most recent failure, 'hwinfo --cpu' reports cpu MHz of 
396.130 for #3. The bogomips value is 5787.73, and the cpu clock before the 
fault is 3437 MHz. Nothing is logged when this happens.

If I were to get a patch that would show a backtrace when the maximum CPU 
frequency is changed, perhaps it would be possible to track this bug.

Sorry that I can not be more specific.

Larry

[toc] | [next] | [standalone]

#1483457

On 09/09/2016 12:39 PM, Larry Finger wrote:
> I have found a regression in kernel 4.8-rc2 that causes the speed of my laptop
> with an Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz to suddenly have a maximum cpu
> frequency of ~400 MHz. Unfortunately, I do not know how to trigger this problem,
> thus a bisection is not possible. It usually happens under heavy load, such as a
> kernel build or the RPM build of VirtualBox, but it does not always fail with
> these loads. In my most recent failure, 'hwinfo --cpu' reports cpu MHz of
> 396.130 for #3. The bogomips value is 5787.73, and the cpu clock before the
> fault is 3437 MHz. Nothing is logged when this happens.
>
> If I were to get a patch that would show a backtrace when the maximum CPU
> frequency is changed, perhaps it would be possible to track this bug.

I have not yet found the bad commit, but I have reduced the range of commits a 
bit. This bug has been difficult to trigger. So far, it has not taken over 1/2 
day to appear in bad kernels, thus I am allowing three days before deciding that 
a given trial is good. I never saw the problem with 4.7 kernels, but I did in 
4.8-rc1. I also know that it appeared before commit 581e0cd. Commit 1b05cf6 did 
not show the bug.

Testing continues.

Larry

[toc] | [prev] | [next] | [standalone]

#1486105

On 09/14/2016 11:00 AM, Larry Finger wrote:
> On 09/09/2016 12:39 PM, Larry Finger wrote:
>> I have found a regression in kernel 4.8-rc2 that causes the speed of my laptop
>> with an Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz to suddenly have a maximum cpu
>> frequency of ~400 MHz. Unfortunately, I do not know how to trigger this problem,
>> thus a bisection is not possible. It usually happens under heavy load, such as a
>> kernel build or the RPM build of VirtualBox, but it does not always fail with
>> these loads. In my most recent failure, 'hwinfo --cpu' reports cpu MHz of
>> 396.130 for #3. The bogomips value is 5787.73, and the cpu clock before the
>> fault is 3437 MHz. Nothing is logged when this happens.
>>
>> If I were to get a patch that would show a backtrace when the maximum CPU
>> frequency is changed, perhaps it would be possible to track this bug.
>
> I have not yet found the bad commit, but I have reduced the range of commits a
> bit. This bug has been difficult to trigger. So far, it has not taken over 1/2
> day to appear in bad kernels, thus I am allowing three days before deciding that
> a given trial is good. I never saw the problem with 4.7 kernels, but I did in
> 4.8-rc1. I also know that it appeared before commit 581e0cd. Commit 1b05cf6 did
> not show the bug.
>
> Testing continues.

And still does. My bisection seemed to be trending toward an improbable set of 
commits, and I needed to do some other work with the machine, thus I started 
running 4.8-rc6. It failed nearly 48 hours after the reboot, which indicated 
that using 3 days to indicate a "good" trial was likely too short. I am 
currently testing the first of the trial and will run it for at least a week. It 
is unlikely that these tests will be complete before 4,8 is released, even if 
-rc8 is needed. I will keep attempting to find the faulty commit.

Larry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web