[SOLVED] Apps freezing for several seconds in stretch

[Faroe]

Another quick update: I ran `fstrim -v` on the SSD partition where my photos are kept and got this result:

Code: Select all

/media/photo: 22.8 GiB (24443183104 bytes) trimmed

Unfortunately, Mirage freezes just like before, if Gimp is running at the same time.

[phenest]

Are you trying to fix the problem you have on Windows? Just because they're doing different things, it doesn't mean the underlying problem is different. They are different OS's and will react in different ways.

Here's some ideas:
1. If you have another computer with similar spec, put your Debian drive in that to see if the problem still occurs.
2. If you have a spare hard drive, install Debian again (or Windows) to see if the problem still occurs.

[Faroe]

This week I did manage to investigate the Windows side a bit. I never knew about the Reliability Monitor, which looks like a pretty handy built-in tool in Windows 7. It seems that every time Windows had crashed, the exact same error message and error code was logged. I googled them and installed a hotfix that, according to some people, should cure the problem.

At the moment, it would seem that the issue in Windows is caused by the system files `csrss.exe` and `sxs.dll` misbehaving. As a matter of fact, Windows crashed twice this week before I installed the patch, which is way more frequent than before, so I'm seriously hoping the crashing would end here. Time will tell.

I haven't been able to do much about the freezes in Debian. It's unfortunate that I currently only have time to look into that during weekends. Another thing that's unfortunate is that I don't have the option of swapping either hard drive to another computer or replacing them.

[Faroe]

Sorry about another week of silence. This time I have, however, made some progress. The day after my last post something went so badly wrong with my /home partition on the HDD that Debian failed to mount it on boot. Unfortunately my root account was disabled, because I've always been happy just using `sudo`, so I couldn't access recovery mode either and the system became temporarily unusable. This was easily fixed, though, by booting another distro I had on a USB stick (Tiny Core in this case), commenting out the failing /home partition in /etc/fstab and creating a new home directory on the SSD. After that I was able to set up a root password and start the repairs.

I ran `e2fsck -cc` on the old /home partition on the HDD and as far as I could tell, no bad blocks were found, but other errors were reported during passes 1 and 5:

Code: Select all

Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 425252 was part of the orphaned inode list.  FIXED.
Inode 425420 was part of the orphaned inode list.  FIXED.
Deleted inode 425617 has zero dtime.  Fix<y>? yes
Inode 425962 was part of the orphaned inode list.  FIXED.
Inode 435657 was part of the orphaned inode list.  FIXED.
Inode 435658 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(2078241--2078243) -(2160238--2160257) -(2186804--2186814) -(2186928--2186935)
Fix<y>? yes
Free blocks count wrong for group #63 (18790, counted=18793).
Fix<y>? yes
Free blocks count wrong for group #65 (28821, counted=28841).
Fix<y>? yes
Free blocks count wrong for group #66 (18659, counted=18678).
Fix<y>? yes
Free blocks count wrong (1687086, counted=1687128).
Fix<y>? yes
Inode bitmap differences:  -425252 -425420 -425617 -425962 -(435657--435658)
Fix<y>? yes
Free inodes count wrong for group #52 (203, counted=207).
Fix<y>? yes
Free inodes count wrong for group #53 (6403, counted=6405).
Fix<y>? yes
Free inodes count wrong (501957, counted=501963).
Fix<y>? yes

Besides /home, there are two much larger partitions on the HDD and I've begun the process of running `e2fsck -cc` on them too. That's going to take a while. I copied the most important contents from the old /home to the new one and haven't encountered any more freezes in Mirage, Gimp or Thunar since then. I'll mark this thread as "[SOLVED]" as soon as I've finished checking the larger partitions. I think it is likely that they will also contain errors, so now I'm considering buying a new HDD. This one must be at least ten years old.

Thanks for all the help, everyone!

[smoki]

There's a problem that has been occurring in my Debian testing system for about two months now. Some apps such as Mirage, Thunar and Audacity tend to freeze occasionally. The freeze usually lasts for about 5 to 10 seconds, during which time the frozen window won't refresh or respond to mouse or keyboard input.

Sounds like an xserver bug i recently read about

https://bugs.debian.org/cgi-bin/bugrepo ... bug=855206
https://bugs.freedesktop.org/show_bug.cgi?id=100863

fixes:
https://cgit.freedesktop.org/xorg/xserv ... eab34b5a19
https://cgit.freedesktop.org/xorg/xserv ... 1e2e424e11

It only affects 1.19 X and is not in stretch package yet, so maybe you can try to patch it.

[Faroe]

Well, I can finally say the freezing problem is history. There haven't been any more issues since I moved my home directory away from the old HDD. I backed up everything I needed and bought a new HDD, which I'm going to install next. I have run `badblocks` on the two larger partitions of the old drive and while one seemed to be OK, the other contained several million bad blocks. Windows also stopped crashing when I installed the hotfix I mentioned earlier. However, I have no idea whether or not the crashes were related to the failing HDD.

Thanks again! This thing has been solved.