Created attachment 1724991 [details] dmesg logs 1. Please describe the problem: upgrade from F32 gnome wayland completed without any issues but my laptop is now very slow and totally unusable after first boot, CPU utilization reaches 100% whenever i open an app (like browser) and UI is choppy Tried switching to xorg, disabled extensions and even switched to older kernel but no luck also i didn't find any errors in journalctl and dmesg Hardware Asus x412ua, Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz/Mesa Intel® HD Graphics 620 (KBL GT2F) 2. What is the Version-Release number of the kernel: 5.8.16-300.fc33.x86_64 #1 SMP Mon Oct 19 13:18:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : There were no issues with F32 and 5.8.16-200 kernel 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. dmesg attached
Update: Issue is present in the Live ISO of fedora 33 (Fedora-Workstation-Live-x86_64-33-1.2.iso) I should have tested it using live image before upgrading my laptop :(, Anyway I am now reinstalled fedora 32 on my laptop
Given that the kernel is the same on F33 and on F32, I am guessing this is somewhere else in the system.
@justin Yes you are correct! I am currently running F32 with kernel 5.8.16-200 and its running perfectly fine! Issue must be somewhere else , It would be great If Someone can shed some light on how to debug this issue
Could be almost anything, glib, clutter, mutter, gtk... Possibly Sysprof would help narrow down what it is and why?
Maybe: https://gitlab.gnome.org/GNOME/mutter/-/issues/1455 I'm not seeing anything obvious though.
Created attachment 1730461 [details] rob's dmesg
Are you still seeing this issue? I did a fresh install today from F32 to F33 to btrfs and my laptop is essentially unusable. YouTube is so slow the audio is unintelligible. DNF takes 15 minutes plus to run despite it showing network speeds of 5 mb/sec. Did a quick check on the CPU during the slow behavior... [rob@localhost ~]$ cat /proc/cpuinfo | grep MHz cpu MHz : 400.003 cpu MHz : 400.004 cpu MHz : 399.887 cpu MHz : 400.001 cpu MHz : 400.004 cpu MHz : 400.016 cpu MHz : 400.002 cpu MHz : 400.004 That's no so great for Intel Core i7-8565U 4 x 1.8 - 4.6 GHz, Intel UHD Graphics 620 and 16 GB RAM.
Created attachment 1730462 [details] rob's sensor data
It looks like it might be thermally throttled however the laptop is cool to the touch. I stopped thermald and the problem stopped. [rob@localhost ~]$ cat /proc/cpuinfo | grep MHz cpu MHz : 1800.050 cpu MHz : 1800.003 cpu MHz : 1800.022 cpu MHz : 1800.026 cpu MHz : 1800.008 cpu MHz : 1800.008 cpu MHz : 1800.032 cpu MHz : 1800.015 laptop is still cool to the touch dispite 3 HD videos playing and using jitsi video conference.
Sorry for the multiple posts, but I just found this... https://github.com/intel/thermal_daemon/issues/280 And while it hasn't fixed anything yet it looks promising.
Could you run the following commands and paste the output? That should be a quick way to verify you have the ASUS PL2 problem: grep -r . /sys/class/powercap/intel-rapl/intel-rapl:0/* grep -r . /sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio:0/* I have created a scratch build with https://github.com/intel/thermal_daemon/commit/57897f54a67744f6625ba88c64ef398209095d34 Everyone affected, please try it: https://koji.fedoraproject.org/koji/taskinfo?taskID=55788083
(In reply to Benjamin Berg from comment #11) > Could you run the following commands and paste the output? That should be a > quick way to verify you have the ASUS PL2 problem: > > grep -r . /sys/class/powercap/intel-rapl/intel-rapl:0/* > grep -r . /sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio:0/* > > > I have created a scratch build with > https://github.com/intel/thermal_daemon/commit/ > 57897f54a67744f6625ba88c64ef398209095d34 > > Everyone affected, please try it: > https://koji.fedoraproject.org/koji/taskinfo?taskID=55788083 It looks like this issue is slightly different than the Asus issue as Srinivas Pandruvada had to send me a Lenovo patch to apply on top of the Asus branch they had created. https://github.com/intel/thermal_daemon/issues/280#issuecomment-729704521 This fixed my problem. (In case the data you requested is still useful I have attached it, this is before I applied the Lenovo patch) Thanks for taking a look at this! Rob
Created attachment 1730577 [details] rob's sysfs dump before lenovo patch
Thanks, Rob Musial for your findings , so its seems like my Asus x412ua laptop is also affected by this throttling issue!! [root@localhost-live liveuser]# cat /proc/cpuinfo | grep MHz cpu MHz : 400.015 cpu MHz : 399.998 cpu MHz : 400.012 cpu MHz : 400.003 @
(In reply to Shyam Jos from comment #14) > Thanks, Rob Musial for your findings , so its seems like my Asus x412ua > laptop is also affected by this throttling issue!! > > [root@localhost-live liveuser]# cat /proc/cpuinfo | grep MHz > cpu MHz : 400.015 > cpu MHz : 399.998 > cpu MHz : 400.012 > cpu MHz : 400.003 > > @ Seems like it so far. To verify try running 'systemctl stop thermald' since you are using a live image. The better test would be to install F33 again (which I know is a pain if it isn't working) and disabling thermald with 'systemctl disable thermald' and rebooting. If that stops your issue then try applying this fix from upstream https://github.com/intel/thermal_daemon/issues/280#issuecomment-728643156 That one seems to have been enough to fix Asus issues, Lenovo required a bit more work. Hopefully that helps.
Thanks for confirming that the upstream fix works. Shyam, you can try the scratch build from https://koji.fedoraproject.org/koji/taskinfo?taskID=55788083 which should fix it.
@benjamin Currently I am running F32 (work machine), Let me check if I can install https://koji.fedoraproject.org/koji/taskinfo?taskID=55788083 on a live media with persistence storage. Also, I am attaching output for grep -r . /sys/class/powercap/intel-rapl/intel-rapl:0/* grep -r . /sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio:0/*
(In reply to Benjamin Berg from comment #16) > Thanks for confirming that the upstream fix works. Shyam, you can try the > scratch build from > https://koji.fedoraproject.org/koji/taskinfo?taskID=55788083 which should > fix it. Does that scratch build contain the Lenovo fix upstream released this morning as well?
> Does that scratch build contain the Lenovo fix upstream released this morning as well? Not yet, no. It only contains the PL2 fix.
Created attachment 1730582 [details] shyam jos - powercap
(In reply to Benjamin Berg from comment #19) > > Does that scratch build contain the Lenovo fix upstream released this morning as well? > > Not yet, no. It only contains the PL2 fix. Thanks for confirming. If you do end up incorporating it I'd be happy to test. Thanks for your work on this.
@Benjamin I installed the scratch build on F33 live media and I can confirm that it fixed the issue!! [root@localhost-live liveuser]# cat /proc/cpuinfo | grep -i mhz cpu MHz : 1836.096 cpu MHz : 1217.607 cpu MHz : 1937.207 cpu MHz : 1903.344 [root@localhost-live liveuser]# cat /proc/cpuinfo | grep -i mhz cpu MHz : 798.522 cpu MHz : 799.790 cpu MHz : 798.463 cpu MHz : 799.387 [root@localhost-live liveuser]# cat /proc/cpuinfo | grep -i mhz cpu MHz : 886.887 cpu MHz : 894.583 cpu MHz : 944.328 cpu MHz : 866.637 [root@localhost-live liveuser]# cat /proc/cpuinfo | grep -i mhz cpu MHz : 917.227 cpu MHz : 1005.706 cpu MHz : 961.355 cpu MHz : 1007.796 [root@localhost-live liveuser]# paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/' acpitz 46.0°C pch_skylake 42.5°C INT3400 Thermal 20.0°C B0D4 48.0°C SEN1 38.0°C x86_pkg_temp 48.0°C BTW I am seeing some warnings in thermald service ● thermald.service - Thermal Daemon Service Loaded: loaded (/usr/lib/systemd/system/thermald.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-11-18 21:46:55 EST; 10h left Main PID: 1054 (thermald) Tasks: 4 (limit: 14150) Memory: 4.5M CPU: 150ms CGroup: /system.slice/thermald.service └─1054 /usr/sbin/thermald --systemd --dbus-enable --adaptive Nov 18 21:46:57 localhost-live thermald[1054]: Unsupported conditions are present Nov 18 21:46:57 localhost-live thermald[1054]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 18 21:46:57 localhost-live thermald[1054]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 18 21:46:57 localhost-live thermald[1054]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 18 21:46:57 localhost-live thermald[1054]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 18 21:46:57 localhost-live thermald[1054]: 22 CPUID levels; family:model:stepping 0x6:8e:9 (6:142:9) Nov 18 21:46:57 localhost-live thermald[1054]: Polling mode is enabled: 4 Nov 18 21:46:57 localhost-live thermald[1054]: sensor id 9 : No temp sysfs for reading raw temp Nov 18 21:46:57 localhost-live thermald[1054]: sensor id 9 : No temp sysfs for reading raw temp Nov 18 21:46:57 localhost-live thermald[1054]: sensor id 9 : No temp sysfs for reading raw temp Is this warnings safe to ignore ? I am planning to upgrade my F32 system by tomorrow evening and when can I expect the updated package on main repo ? Thanks a lot for your quick response and support Benjamin
That is just a test build. I'll probably submit a proper package update either tomorrow or start of next week (kind of hoping we'll get a new 2.4 upstream release by then). At that point, it'll take another week or so to go through the process to reach stable.
(In reply to Benjamin Berg from comment #23) > That is just a test build. I'll probably submit a proper package update > either tomorrow or start of next week (kind of hoping we'll get a new 2.4 > upstream release by then). At that point, it'll take another week or so to > go through the process to reach stable. Thanks for the update, regarding thermald warnings I have raised an issue at upstream repo : https://github.com/intel/thermal_daemon/issues/282
Those warning are not an issue. This is during a earlier check to choose a fallback target, but there is a condition to check temperature. This is before even the thermald starting loading sensors. But after the actual start the condition will be processed.
I have pushed 2.4-pre. Please give a try.
The repository is here: https://github.com/intel/thermal_daemon
For convenience, you can use the following scratch build (simply includes a patch to update 2.3 to 2.4-pre): https://koji.fedoraproject.org/koji/taskinfo?taskID=56001267
(In reply to Benjamin Berg from comment #28) > For convenience, you can use the following scratch build (simply includes a > patch to update 2.3 to 2.4-pre): > > https://koji.fedoraproject.org/koji/taskinfo?taskID=56001267 I tried the new scratch build and its working fine ● thermald.service - Thermal Daemon Service Loaded: loaded (/usr/lib/systemd/system/thermald.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2020-11-21 15:08:17 IST; 1h 0min ago Main PID: 1399 (thermald) Tasks: 4 (limit: 14178) Memory: 3.8M CGroup: /system.slice/thermald.service └─1399 /usr/sbin/thermald --systemd --dbus-enable --adaptive Nov 21 15:08:18 asus-vivobook thermald[1399]: Unsupported conditions are present Nov 21 15:08:18 asus-vivobook thermald[1399]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 21 15:08:18 asus-vivobook thermald[1399]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 21 15:08:18 asus-vivobook thermald[1399]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 21 15:08:18 asus-vivobook thermald[1399]: Unable to find a sensor for \_SB_.PCI0.LPCB.EC0_.SEN1 Nov 21 15:08:18 asus-vivobook thermald[1399]: 22 CPUID levels; family:model:stepping 0x6:8e:9 (6:142:9) Nov 21 15:08:18 asus-vivobook thermald[1399]: Polling mode is enabled: 4 Nov 21 15:08:18 asus-vivobook thermald[1399]: sensor id 9 : No temp sysfs for reading raw temp Nov 21 15:08:18 asus-vivobook thermald[1399]: sensor id 9 : No temp sysfs for reading raw temp Nov 21 15:08:18 asus-vivobook thermald[1399]: sensor id 9 : No temp sysfs for reading raw temp Thanks Benjamin Thanks Srinivas for the update
(In reply to Benjamin Berg from comment #28) > For convenience, you can use the following scratch build (simply includes a > patch to update 2.3 to 2.4-pre): > > https://koji.fedoraproject.org/koji/taskinfo?taskID=56001267 I tested both the upstream release and the scratch build and both fix the Lenovo issue. Thanks everyone for the work.
FEDORA-2020-c56a6bedef has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c56a6bedef
FEDORA-2020-c56a6bedef has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c56a6bedef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c56a6bedef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-c56a6bedef has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.