Description of problem: On Fedora 25 Workstation, I have been experiencing random lags while using the default GNOME desktop environment. On several occasions, including typing text, system notification audio, opening and closing windows and even menus, the system responds after a delay of a second or more, and I can sometimes hear a whirring sound at that time, such as that of the hard drive resuming from a suspended state or the CPU/motherboard fan starting up (but I do not know what actually causes it). The laptop is a new Lenovo Ideapad 110-15ISK (80UD). Such a problem does not occur on any other distribution. Since I do not know which component causes these delays, I have tentatively marked basesystem in the bug report. The problem occurs in the live session as well on the installed system, irrespective of whether updates have been installed or not, and on both Wayland and Xorg. There does not seem to be any resource-intensive activity ongoing at these times. The occurrence is very unpredictable but not very frequent. Version-Release number of selected component (if applicable): Fedora 25 Workstation (x86_64) kernel 4.9.4-201 (also 4.8.6-300) gnome-desktop3 3.22.2-1 gnome-shell 3.22.2-2 How reproducible: Always Steps to Reproduce: 1. Try or install Fedora 25 Workstation. 2. Use the system for some time (maybe even days). Actual results: There is a random, perceptible lag on some occasions of interacting with the system. Expected results: No perceptible lag in circumstances where there is no other resource-intensive activity in progress.
I have now found that when the delay is caused, at least some of the time, the hard drive is read, but I still do not know why. The GNOME System Monitor shows that the swap space is free.
basesystem is wrong component for this - it is just metapackage with no content. Let's try distribution, but please change the component accordingly if you find out what causes the hdd reads.
Well, I don't think distribution is too much better. ;) Anyhow, can you try running: sudo perf top and when one of these lags shows up, what is at the top of the list?
The problem is that the lag lasts for only a second or two and is completely unpredictable, so I am not sure that the perf top output will show the culprit, but I will try. I have UEFI and the 1000 GB HDD layout as 200 MiB EFI (FAT-16), 512 MiB /boot (Ext4), 5684 MiB swap, rest / + /home (btrfs), in that order. I hope this does not have anything to do with it. At least, I have always used such layouts and never experienced problems.
I also have relatime on all partitions, plus space_cache, autodefrag and nodatacow on btrfs.
I have run sudo perf top and, although the lags occurred a few times, I got nothing consistently the same in the perf data. The top was different each time. There is one [unknown] shared object in it with symbol something like [k] 0000000000000000 (all zeroes), but it too does not consistently come up on top. As of now I have got nothing definite, but it appears that deleting or renaming /var/log/journal, which should effectively disable journal persistence as far as I know, causes the problem to occur more frequently, but I cannot be sure; it has occurred even with the journal in place but seems to be less frequent.
Not sure what else to suggest. Moving this to gnome-shell to see if they have any more debugging ideas.
Sorry, the journal idea was a shot in the dark, it's not the journal; the lags keep occurring even with journal persistence. It's the random nature of the problem that's making it so difficult. One point I have noticed is that the problem seems to occur mostly when something has to be read (apparently) from disk (cache?). For example, they have occurred when an icon was to be shown, when a shell autocomplete was needed (Tab key), and when the system notification sound was to be played. But it has also occurred once when a window was just to be closed (just after clicking the window's close button). In the live session it has occurred during cursor movement in vi and when the system was to be shut down. I also hear the whirring sound every now and then, even when not interacting with the system, and even at those times I have seen nothing consistent in the top processes and functions.
I encountered the same issue on the KDE spin, and found through smartctl that the APM level on the primary hard drive (on which Fedora is installed) was 96. I don't know whether this is only on battery or when plugged in as well, but 96 seems too low to me for a desktop configuration. Manually setting it to anything above 127, so that spin-down is not allowed, seems to solve the problem. I noticed in GNOME Disks that when it is below 128, the disk keeps going into standby and resuming on reads, causing a noticeable lag (maybe it's just my hardware?). However, on Ubuntu I see that by default all drives are at 128 on battery power and at 254 when plugged in. I don't know whether this automatic switching will be possible with a forced setting as mentioned above. I have changed the component to udisks2. Please correct this if it is wrong.
(In reply to Saurav Sengupta from comment #9) > I have changed the component to udisks2. Please correct this if it is wrong. We're going through a transition period here... in Fedora 25 udisks2 has been removed and replaced with storaged. In Fedora 26, storaged will (hopefully) be renamed to udisks2. So any other time, this would have been right.
There has been no update on this in the past few months. I had thought that it would be resolved with a new version of storaged/udisks2, but the situation is the same on Fedora 26 with udisks2 - APM level is still 96.
Installing and enabling TLP (package tlp) also causes the hard drive APM levels to be set to 254 on mains power and 128 on battery, which is a workaround. Before that, I was using udev rules with hdparm to set the levels, but that requires triggering it after resuming from suspend as well, otherwise it gets re-set to 96.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.