Created attachment 145472 [details] Screenshot of the issue I usually suspend my PC in the evening. Weeks may go by without reboot or logoff from KDE, meaning a desktop session can live over dozens of suspends. Sometimes, the disk applet doesn’t take kindly to that and has some kind of run-off. I have been observing this problem for quite some time now, but can’t remember for how long precisely. It is rather sporadic. I have no proof that it’s the suspend/resume that causes this, but I can hardly imagine anything else. However, I never saw this on my laptop, which I also suspend almost daily. The PC in question has two SATA drives: a system SSD and a hard disk and several ramdisk. There is also a davfs and an nfs configured in fstab, but they are currently not mounted. The applet uses two sensors: total disk write (“Schreiben“ on the screenshot) and total disk read (“Lesen”). OBSERVED RESULT The legend goes up to around 2^65 and the graph shows permanent full load. EXPECTED RESULT It shouldn’t do that. :) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.15.13-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: AMD PITCAIRN
Little update: I just noticed that it’s doing it again. But this time there is no prior suspend. However, earlier I did some juggling with removable storage devices, including ones that are LUKS-encrypted and opened via Dolphin.
Created attachment 145818 [details] Screen capture of the applet while inserting a USB stick Update: the reason why I never noticed it on my other machine was that it didn’t have a plasmoid with the disk sensors there. 😅 So I set one up. Then I plugged in an external disk and as soon as I mounted it, the issue appears—in 100 % of cases. In some instances I didn’t even have to mount it. In the attached screencap, I opened the plasmoid popup to watch it, then plugged in the stick and a fraction of a second later the scales changed without any mounting involved. One interesting detail here is that the sensor values don’t stay at the high level, but return to 0—in contrast to my first screenshot. Only when watching my recording did I notice that I recorded at reduced picture size. So I reset it to 100 % and began another recording, but from then on I was unable to reproduce the issue as I did in the first capture. At first I though that was because recording at FullHD now put a lot more load on the system which may slow down other stuff (thinking of a timing issue). But even after I stopped recording and just replayed my steps about a dozen times, I could not recreate the glitch right at media insertion.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksystemstats/-/merge_requests/29
Git commit 75dad23ba525647bd3f3acf6a2c71e9a84b552de by Arjen Hiemstra. Committed on 27/01/2022 at 15:12. Pushed by ngraham into branch 'master'. disks: Properly initialize read/write counters These are used to calculate the read/write rate. If they are left uninitialised, the first update of those rates will be a bogus value. M +2 -2 plugins/disks/disks.cpp https://invent.kde.org/plasma/ksystemstats/commit/75dad23ba525647bd3f3acf6a2c71e9a84b552de
Git commit 9a301fc661c8ac7a46c6d2d5bcdfb6987b794092 by Nate Graham, on behalf of Arjen Hiemstra. Committed on 27/01/2022 at 19:38. Pushed by ngraham into branch 'Plasma/5.24'. disks: Properly initialize read/write counters These are used to calculate the read/write rate. If they are left uninitialised, the first update of those rates will be a bogus value. (cherry picked from commit 75dad23ba525647bd3f3acf6a2c71e9a84b552de) M +2 -2 plugins/disks/disks.cpp https://invent.kde.org/plasma/ksystemstats/commit/9a301fc661c8ac7a46c6d2d5bcdfb6987b794092