I just updated to 19.04 from 18.10 (and previously from Debian Stretch). Since the upgrade, any writing operation freezes the entire system, including mouse, for 3 or more seconds. It's quite bizarre because didn't happen before the upgrade, and the system is the same. hdparm reports 517 MB/s reads and smart is not showing any errors:

sudo smartctl -a /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-5.0.0-13-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Device Model:     LITEON L8H-128V2G-11 M.2 2280 128GB
Serial Number:    BR0RJW291CB0075GB0VE
Firmware Version: F87110C
User Capacity:    128.035.676.160 bytes [128 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      M.2
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Apr 20 11:47:56 2019 -03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x02) Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (    0) seconds.
Offline data collection
capabilities:            (0x11) SMART execute Offline immediate.
                    No Auto Offline data collection support.
                    Suspend Offline collection upon new
                    No Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    No Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   1) minutes.
Extended self-test routine
recommended polling time:    (  10) minutes.
SCT capabilities:          (0x003d) SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
  5 Reallocated_Sector_Ct   0x0003   100   100   000    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0002   100   100   000    Old_age   Always       -       681
 12 Power_Cycle_Count       0x0003   100   100   000    Pre-fail  Always       -       535
175 Program_Fail_Count_Chip 0x0003   100   100   000    Pre-fail  Always       -       0
176 Erase_Fail_Count_Chip   0x0003   100   100   000    Pre-fail  Always       -       0
177 Wear_Leveling_Count     0x0003   100   100   000    Pre-fail  Always       -       76
178 Used_Rsvd_Blk_Cnt_Chip  0x0003   100   100   000    Pre-fail  Always       -       0
179 Used_Rsvd_Blk_Cnt_Tot   0x0003   100   100   000    Pre-fail  Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0003   100   100   000    Pre-fail  Always       -       147
181 Program_Fail_Cnt_Total  0x0003   100   100   000    Pre-fail  Always       -       0
182 Erase_Fail_Count_Total  0x0003   100   100   000    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0003   100   100   000    Pre-fail  Always       -       0
195 Hardware_ECC_Recovered  0x0003   100   100   000    Pre-fail  Always       -       0
241 Total_LBAs_Written      0x0003   100   100   000    Pre-fail  Always       -       215371
242 Total_LBAs_Read         0x0003   100   100   000    Pre-fail  Always       -       68520

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%        58         -
# 2  Short offline       Completed without error       00%        58         -
# 3  Short offline       Completed without error       00%        58         -
# 4  Short offline       Completed without error       00%         0         -

Selective Self-tests/Logging not supported

fstab has the common options for a system with LVM:

cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/euclides--vg-root / ext4    noatime,nodiratime,errors=remount-ro 0       1
# /boot was on /dev/sdb1 during installation
UUID=456b218a-f23c-4a35-8b39-ad416b03204f /boot           ext2    defaults        0       2
/dev/mapper/euclides--vg-home /home           ext4    defaults        0       2
/swapfile                                 none            swap    sw              0       0

Any ideas on what's going on and how to fix this?

EDIT: For testing, I switched from Gnome to KDE and, surprise surprise, the lag was gone. So this probably was not an issue with my SSD but really something related to Gnome.

  • I seem to have the same problem. But I installed it again fresh (I previously had 18.10 as well). Haven't checked any other desktop environments yet. Did you install KDE on your installation or something else (e.g. booting kubuntu from live usb)?
    – Andrew
    Apr 23 '19 at 18:56
  • I installed KDE on the same installation. No problems so far, so it really seems to be related to Gnome.
    – Ivan
    Apr 24 '19 at 0:07
  • I had the system monitor open while a freeze happened and you could see a CPU core going 100% for the duration of the freeze and gnome-shell rising in CPU usage (it was 50% right when the freeze ended, during the freeze the GUI didn't update)
    – Andrew
    Apr 24 '19 at 13:06
  • I would report a bug but I'm not sure against which package. So far, KDE without freezes, with several sleep cycles and some heavy computing.
    – Ivan
    Apr 24 '19 at 23:13
  • I reinstalled ubuntu again yesterday and had no issues since (still using the default gnome shell). Some of the programs I was running while the freezes happened/some of the packages i installed around that time were openjdk, eclipse and insync. Although freezes still occured on reboot with none of those running by just opening the terminal sometimes so not sure how relevant that is. I also remade my installation media (live usb but still same physical usb stick) so maybe my first time around it was corrupted? Don't know really
    – Andrew
    Apr 26 '19 at 0:51

If you have nVIDIA and Gnome 3.32 on Ubuntu 19.04 then please follow: https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/post/5323965/#5323965 Add the variable as follows:

sudo gedit /etc/environment

On my Dell 7577 laptop (with nVIDIA GTX 1060 with max-Q design) I had since the upgrade from Ubuntu 18.10 to 19.04 freezes of 2 seconds when starting an application like Thunderbird or Firefox. Also VLC was stuttering. With the above variable my gnome is running smooth.

  • On my Oryo Pro, I was seeing random lockups. Until I did this. Now ALL is good!!! Thanks much for the suggestion!!
    – JoelParke
    May 28 '19 at 1:06

You could have hit the APST bug described here:
1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184
2. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1689357

They suggest editing /etc/default/grub and adding kernel parameter nvme_core.default_ps_max_latency_us=xxx in the kernel command line
for the different devices, xxx is different, if it works with 0, you can start increasing to (max 5500) to allow for deeper power saving states. Don't forget to run update-grub after editing & before reboot. Anyway, read the thread.


Exact same thing here, but instead of Ubuntu, with an update of Debian Stretch to Debian Buster. The 3 seconds freeze, and the high CPU usage on gnome-shell, just by doing a simple touch hello in a terminal.

I have been using that user on Stretch for years, so it has a ton of docs and configs.

I did not want to go to KDE, as the comments suggest. So, what I did was to see if the problem was happening on a brand-new user. On the new user, no problem at all.

So, my solution has been:

  1. log out of every session
  2. log in as root on console
  3. mv /home/myusualuser /home/myusualuser2
  4. mkdir /home/myusualuser
  5. chown myusualuser:myusualuser /home/myusualuser
  6. and login again as myusualuser

Problem gone.

Now I am moving my files gradually. If I find what directory/file/config was creating the problem I'll update this entry.


I'm pretty sure I was experiencing the same problem. Here were some things I noticed:

  • Freezing tended to get worse (system would hang for longer) after it had been running for a while
  • Commonly would hang for several seconds on resuming from suspend, saving a downloaded file to my desktop in Firefox, closing a file selection dialog (for example, to upload an email attachment or open a document) -- and would hang regardless of whether I actually opted to access a file or cancel the dialog
  • After a day of simple web work and a few suspend/resume cycles, my system would feel sluggish in ways not at all justified by my hardware (brand new system, SSD, 8th gen i7, 16 GB RAM, this should not be bogged down by word processing and Gmail)
  • Problem was totally nonexistent prior to upgrading to 19.04 from 18.10

I have now upgraded to 19.10 and the problem is less apparent. Immediately after upgrade, the hang reduced to less than a second instead of several seconds -- my system still did seem to hang slightly, but not in a way that I minded so much.

HOWEVER, I also tend to keep a lot of files on my desktop -- we're talking at least 60-200 at any given time. Many of them are small, but some are quite large (a Linux ISO, for example). On a hunch, I cleaned all these files off of my desktop, and the hang totally seems to have disappeared now. I would imagine that, even under 19.04, cleaning my desktop would have helped with this issue, but I'm not about to revert to test this hypothesis.

I'm curious whether upgrading to 19.10 and/or cleaning the desktop has helped anyone else with similar issues.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.