| Summary: | Random Freezes 20.04 | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | Scott <shagooserver> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | normal | CC: | nate |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Excerpt of syslog and kernel log around 9.33pm 17/09/20
syslog System Monitor 1 process tab |
||
|
Description
Scott
2020-09-16 00:13:31 UTC
I'm suspecting a kernel issue, but it could conceivably be KWin. Does the freeze only affect KDE apps, or all apps? No, it affects any/all applications. From memory it has occurred with Kate, Firefox, VLC, MPV, Dolphin. Not that I play games for any significant amount of time (maybe avg 1 hour/day)they have not been affected as yet. In many instances though many programs are running. If you disable compositing (hit Alt+Shift+F12), does the problem stop happening? I have Alt+Shift+F12 on both machines and will wait to see if it happens again though bear in mind it may be many days. Just some additional information which may or may not be of assistance, both the affected PCs are never turned off though the dual boot machine is restarted into Windows every day. The unusual thing which causes no harm is that when it escapes Kubuntu the log offs are not identical as I would expect. I log off pretty much every time with 2 Dolphin windows and firefox open and minimised. Again totally random. Does Alt+Shift+F12 cause the time widget to display incorrect time? Both machines are displaying 4.31 p but when I go to change the time (right click > adjust time and date) the time is correct, approx 8.34pm.The widget time is not changing each minute. That problem is Bug 353983 which was fixed in version 450.57 of the proprietary NVIDIA driver. You might consider updating it. Created attachment 131735 [details]
Excerpt of syslog and kernel log around 9.33pm 17/09/20
Experienced a freeze on one PC last night at approx 9:33pm. The preceding post is an excerpt of the kernel and syslog surrounding that time. The crash occurred while watching mpv which I killed and I then resumed the movie with vlc with a minute or two. Please note vlc writes to syslog. Just a thought, as the time displayed in the clock widget was correct, 9:33, does that indicate that Alt+Shift+F12 had been overidden by mpv which as a video player might invoke a compositor? Not necessarily; the nvidia panel freeze isn't a 100% thing. Created attachment 131793 [details]
syslog
The other machine also had a window freeze on 20/9/20 at around 11:30 am. Syslog is attached and no activity at all in the kernel log. The freeze occurred in Kate and unusually it was responding slowly just prior to and after the freeze, closing and reopening it fixed the problem.
Created attachment 131859 [details]
System Monitor 1
Please see the attached screenshot showing CPU usage where many cores are at 100%. Although there were no frozen screens there was very sluggish responsiveness of the system.
The interesting thing is that after leaving the PC for some hours CPU usage was at this level and without doing anything it returned to fairly low levels as can be seen at the start of the graph and then rose to extreme CPU usage after about 5 minutes.
A look at the processes tab showed Tixati using 1% CPU and everything else less than that. After closing Tixati, the only open program, CPU levels returned to idle. A google search found that Tixati had some high CPU usage issues back in 2013 that have since been fixed but nothing current.
Created attachment 131860 [details]
process tab
The CPU usage issue I last raised is likely an associated issue but may not be present when the active window freezes as seen in subsequent freezes. I think I have found a commonality with both machines: In, I think all cases, a very large file was in use, large being somewhere greater than 20+GB (not sure of the exact size threshold). I did some more tests on large files and discovered that there is indeed some problem with Kubuntu that is directly affected by what size file it is working on. For the tests I used MKVtoolnix GUI Ver 50 once on Kubuntu 20.04 against the same files and MKVtoolnix on Windows 10 using the same hardware, including disks. The test involved re-muxing a video file from an m2ts container to an mkv container, therefore the data of the movie was not changed. File size is output size. This is repeatable. File Time Size Windows Kubuntu 1GB 11 secs 7 secs (45 min TV show) 6.2GBs 2 mins 23 secs 2 mins 30 secs (typical DVD) 18.8GBs 6 mins 43 secs 38 mins 45 secs (HD Blu Ray) 43.4GBs 14 mins 172 mins (UHD Blu Ray) As would be expected the time increase for Windows is fairly linear being dependent on file size whereas Kubuntu needs fixing. I don't see how this issue is related to KDE software. If a (user) process hangs, please attach to it with gdb and get a backtrace during the freeze. You might need to do this via a remote ssh connection. If a system process hangs, it is a kernel or driver issue. As stated previously this problem affects multiple programs and is random so getting a backtrace, with my technical knowledge, is quite difficult. I have further highlighted that it appears to be somehow connected to large file sizes and have shown one example using just one application. Further the problem appears less pronounced on an older Intel based machine.It may well be that you are correct that it is an kernel or driver issue but after upgrading to 20.10 it is still there and not resolved. In the case of the mkv app I have raised a bug with them and they cannot reproduce it and I cannot remove the problem by using an earlier version of that program which did work much faster in 19.04. |