System slowdown with dmesg: "interrupt took too long lowering "kernel perf_event_max_...

Hi I’ve been running Leap 15 on six computers since it came out. Yesterday one of my desktop machines slowed to a crawl such that the GUI was essentially frozen. I logged in from another machine. The dmesg command showed the last three entries as: "interrupt took too long lowering “kernel perf_event_max_sample_rate…” I recently changed nothing in the configuration or installed software other than the suggested updates.

This happens when I have firefox, chrome, thunderbird, and libreoffice running. This machine is a relatively new one with Intel i7-7700 CPU @ 3.6 GHz.

This behavior suggests that either I have a hardware problem, or a configuration problem that an update caused to result in this issue appearing. The beginning of dmesg says:

0.000000] microcode: microcode updated early to revision 0x8e, date = 2018-03-24
0.000000] Linux version 4.12.14-lp150.12.28-default (geeko@buildhost) (gcc version 7.3.120180323 [gcc-7-branch revision 258812] (SUSE Linux) ) #1 SMP Mon Dec 3 16:46:15 UTC 2018 (b91289f)
0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp150.12.28-default root=UUID=93ee115f-c4f5-4c9d-83b2-04d325a5430e resume=/dev/disk/by-id/ata-Samsung_SSD_850_EVO_1TB_S2RENX0H512224E-part3 splash=silent quiet showopts

[FONT=arial]I did some searching and it seems that Samsung SSD’s have been associated with this issue in the past. Having not diagnosed kernel issues in recent memory, and finding no other posts with this behavior on OpenSUSE suggests that this is most likely a hardware problem. I thought I would ask if any other maintainers or sysadmins have seen this behavior recently. Did a recent software update precipitate this problem? I ask this because this machine has been running without problem since I built it six or seven months ago. The 1 TB Samsung 850 EVO SSD has been in service for several years in different machines. -Thanks


Does this happen with a previous kernel?
Btrfs? If so, boot a previous snapshot and see if the issue exists there.

Device is formatted Btrfs. I booted previous kernel after I read your reply (six hours ago). Does not seem to happen with kernel 4.12.14-lp150.12.25-default. This problem seems to have appeared with the upgrade to kernel 4.12.14-lp150.12.28-default. That seems bad. Bad, as in not something that I’m going to fix, and bad, as in something that might really cause problems for others .



If you can reproduce it again after booting newer kernel you should open bug report.