Bug 1360705
| Summary: | [abrt] WARNING: CPU: 0 PID: 5075 at drivers/cpufreq/cpufreq.c:2173 cpufreq_update_policy+0x102/0x150 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alan Jenkins <alan.christopher.jenkins> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 23 | CC: | anton, gansalmon, itamar, jonathan, kernel-maint, lpancescu, madhu.chinakonda, mchehab, sergio | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/74da2a292d35269de81f8a1d7c8830bb8d9ea029 | ||||||
| Whiteboard: | abrt_hash:ee8c1895b19ab952d4e5627d8ad59bb71022c87a;VARIANT_ID=workstation; | ||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-09-20 04:36:47 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Alan Jenkins
2016-07-27 11:19:55 UTC
Created attachment 1184601 [details]
File: dmesg
same here happens in all resumes from sleep , also found in ask a similar problem , I think, https://ask.fedoraproject.org/en/question/29705/how-to-fix-temperature-threshold-cpu-throttled-errors/?answer=91650#post-id-91650 After downgrade to microcode_ctl-2.1-10.fc23.x86_64 run "dracut --kver 4.6.5-200.fc23.x86_64 --force " for all kernels and reboot again , I was able to fix this kernels oops . Suggested fix/workaround does not work for me.[1] My working hypothesis was the WARNING happened due to recent cpufreq rewrite, and hence would not be related to microcode. So it's quite frustrating to have the issue I reported re-assigned to microcode, without an explanation of why that was considered a candidate cause :-(. Note the cpufreq changes would be consistent with it being in kernel version 4.6 and not 4.5. See https://lwn.net/Articles/682391/ Note for me, I'm finding the WARNING does _not_ happen every suspend. I have to follow the sequence below to get it. _Then_ it triggers reliably, I believe. (I have... some experience with reproducing annoying ACPI bugs :). My hope is something similar (not necessarily exactly the same) led to you thinking microcode was responsible. It would be great if you could think about your testing, and whether that's a possibility in your case. - thinkpad running on AC power - enter suspend *specifically* by closing the lid - unplug from AC power - re-open lid, triggering resume from suspend [1] Downgraded to microcode_ctl-2:2.1-9.1.fc23.x86_64, ran "dracut --force" to regenerate current initrd, which mentions my current kernel version 4.6.4-201.fc23.x86_64. Rebooted. WARNING message still occurred. Versions seems slightly different on Sergio machine - proposed-updates? To use the new microcode, initrd for the kernel to boot needs to be (re)created after the new microcode_ctl package is installed. This is done automatically by a new installed kernel package, or you can do it manually using dracut (see "man dracut"). For example, for the current running kernel, run But that's what I did?
"Downgraded to microcode_ctl-2:2.1-9.1.fc23.x86_64, ran "dracut --force" to regenerate current initrd, which mentions my current kernel version 4.6.4-201.fc23.x86_64. Rebooted. WARNING message still occurred."
> For example, for the current running kernel, run
It looks like you were trying to suggest a specific command, but it got eaten somewhere?
Also my system reliably boots. Symptoms like boot failure as per #1353103 are more like what I would have thought CPU microcode issues would do. (In reply to Alan Jenkins from comment #7) > But that's what I did? > > "Downgraded to microcode_ctl-2:2.1-9.1.fc23.x86_64, ran "dracut --force" to > regenerate current initrd, which mentions my current kernel version > 4.6.4-201.fc23.x86_64. Rebooted. WARNING message still occurred." no , Downgraded to microcode_ctl-2:2.1-9.1.fc23.x86_64 , reboot , to an old kernel preferably, that haven't this issues , after boot with old microcode_ctl run "dracut --force" > > For example, for the current running kernel, run > > It looks like you were trying to suggest a specific command, but it got > eaten somewhere? Sorry. I don't believe that's needed. Please, can you write and/or copy-paste your own issue against microcode_ctl. If a third party decides we have the same issue, that's not a problem. Issues can always be marked as duplicates. cpufreq was changed in kernel version 4.6. WARNING messages from cpufreq starting in version kernel 4.6, are most likely caused by this. CPU microcode issues are unusual, and expected to have much more impact (like complete failure during boot). Well https://paste.fedoraproject.org/396654/69672341/ line 1001 [1] doesn't happens to me anymore , you have several bugs opened , TBH now I'm using kernel 4.6.5-200.fc23.x86_64 and not 4.6.4 ... [1] [ 836.906123] WARNING: CPU: 0 PID: 53 at drivers/cpufreq/cpufreq.c:2173 cpufreq_update_policy+0x102/0x150 > you have several bugs opened
I'm still struggling to understand you. But I guess I'm in the process of upgrading to Fedora 24. ABRT shows us a separate bug for Fedora 24, which is still assigned to the kernel package.
So actually I shouldn't mind, if you switch this bug back again to the microcode_ctl package. (It will at least make the assignee consistent again - my bad).
I can subscribe to the Fedora 24 bug. The reason I wanted to report this to the kernel team, was that ABRT was failing to report it automatically. It looks like ABRT has been reporting it correctly for Fedora 24, so I can be confident the message will get through to the kernel developer(s) who are rewriting cpufreq.
(In reply to Alan Jenkins from comment #12) > > you have several bugs opened https://bugzilla.redhat.com/show_bug.cgi?id=1353103 and 1351943 1352700 1353061 1353586 1357317 1357862 and 1361183 and this one at least > I'm still struggling to understand you. Sorry , for my weak English, what I can say ? , after downgrade microcode_ctl , I boot with kernel-4.5.7-202.fc23.x86_64 , I update initramfs and this problem has gone is what I can tell you, if kernel-4.6.5 makes difference to 4.6.4, etc I don't know, I just follow the instructions ( https://www.happyassassin.net/2016/07/07/psa-failure-to-boot-after-kernel-update-on-skylake-systems/ ) The bug is yours, I'm not going to change it. I lost more than one day with very stupid problems, just after regenerate initramfs, never understood well what happened, but now, that things are running well, I will not do more tests. This was one hell of week, they update in F23 ! kernel, microcode_ctl and kde plasma 5.7.1 all buggy ! , without fully test in F24 or rawhide, that is what makes me mad and also I'm tired . Sorry for any inconvenience . I speak to early (even with microcode_ctl-2.1-10), on second resume from sleep I got again : [12530.888028] WARNING: CPU: 0 PID: 15865 at drivers/cpufreq/cpufreq.c:2173 cpufreq_update_policy+0x102/0x150 :/ , so it is kernel your are right. *** Bug 1364983 has been marked as a duplicate of this bug. *** kernel 4.7.0-300.fc24 from kernel packages maintainers [1] fix this issue for me. [1] https://copr.fedorainfracloud.org/coprs/jforbes/kernel-stabilization/ This used to happen on every single wakeup with kernels 4.6.3 to 4.6.5; since updating to kernel 4.6.6-200.fc23, I counted 26 wakeups in the logs, without any WARNING at all. I upgraded yesterday to kernel 4.6.7-200.fc23: 4 wakeups without any issues. I assume the problem was fixed? Neat, it looks like the fix for cpufreq_update_policy() got into 4.6.6-stable. https://lkml.org/lkml/2016/8/8/623 ABRT hasn't been bugging me either lately. I think this bug could be closed. yes, I think so , closing this bug. FYI I'm running kernels from "official" repo "Rawhide kernels built without debugging turned on" and since kernel-4.8.0-0.rc6.git0.1.fc26.x86_64 performance of laptop, especially of thermal and fans etc looks great again on my DELL Latitude E6410 ... |