You are not logged in.
Pages: 1
My Ascii install has a strange problem. At random intervals an application I am using will freeze. The mouse does not stop moving, but the application(s) will not respond. Any sound that happens to be playing is also stopped. Fortunately, it is not permanent. The application resumes responding again after a few minutes. At first, it happened with the Firefox browser, and I suspected it was something to do with the extensions I had installed. After visiting the Mozillazine forums, I removed an extension at it seemed like the problem was gone.
But now it is occurring again, and this time not with the browser. I was looking at potential wallpapers in the Mirage image viewer and it froze. Again, the mouse did not stop working. The application simply would not respond. After a while, it returned and jumped all over the place to catch up with the mouse clicks it had been ignoring.
As I have posted elsewhere, I like to have Gkrellm on my desktop. I could see it as this happened. It did not stop updating, and it did not show any huge spike in CPU usage as some sort of loop problem might cause. When the freezing app was the browser, there was a large spike in processes. But when the image viewer was frozen, there was no spike in processes.
Now I am suspecting this has something to do with the video driver. There is a problem that occurs in Windows with nVidia drivers. The display will freeze, but only for a few seconds, and then an error is generated. "Display Driver Stopped Responding and has Recovered" is the error message. There are a number of threads about this error on various support boards out there. The recommended solution is to change the timer that triggers the error, but that just means your system freezes longer. The real solution is to make sure the card is properly initialized when loading the OS. I stopped this problem on my Windows systems by turning off "quick boot" so the BIOS had time to properly start everything. It was a frequent annoying problem, but has only hit me once or twice since making that change.
But it seems very possible that this sort of problem could be different in Linux than in Windows. Maybe the conflict can cause just a particular program to freeze instead of the whole display? Which log would I check for display driver errors?
The only other possibility I can think of is a conflict with the Trinity desktop resources. I wouldn't let it install the whole different desktop base it wanted to install. My system is still using the default desktop-base that comes with Xfce. So I would expect any problems to occur within Trinity, not Xfce. But these are very complex systems. I suppose it is very possible that some of the libraries conflict and could cause a problem like this. In which case I guess I would need to use "uninstall --purge" or something like that to get rid of everything?
Offline
Could you elaborate on which graphiccard model you are using and also what driver is active for it, nouveau or Nvidia proprietary?
You can try to use bellow to find which driver is in use:
lspci -nnk | grep -i vga -A3
Are you able to test your system with an other card?
Offline
Well, I thought it was clear that I was using the nVidia driver since I compared it to the nVidia problems in Windows. But anyway:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK106 [GeForce GTX 660] [10de:11c0] (rev a1)
Subsystem: ASUSTeK Computer Inc. GK106 [GeForce GTX 660] [1043:8422]
Kernel driver in use: nvidia
Kernel modules: nvidia
The other cards I have are of the same generation. Well, one other machine has a GTX960 but I don't want to go disassembling machines to swap parts around. That's a considerable risk of damaging things. I guess I might install Devuan to that other machine and see if similar problems occur. But I was hoping to work out the problems on this "test" machine before installing on my other machines.
Offline
I had this problem earlier last week but was using Ceres. Screen freeze was random and unpredictable. Would be fine for only 2 minutes one boot and then it would be fine for hours the next boot. Ever since installing the nVidia proprietary driver the system has been stable and running for almost a week with no freezes. Machine is a HP Z420 with a Quadro K2000.
Since you mentioned that Windows also had the problem though, I'd be more inclined to think that you have a possible hardware issue. The card swap might be worth it to keep yourself from going crazy trying to find a software fix for a hardware issue....
Offline
But I solved the problem in Windows. Just turn off "quick boot" and allow the MB and card to fully initialize and the problem goes away. Also, this machine is dual-boot, with a currently working Windows install. It works flawlessly, or as close to flawlessly as any Windows install can run. No freezing or other noticeable problems when running browsers and media players and many other tasks at the same time. Admittedly, this is using an older driver. I have not updated the driver in years. The Linux driver in the repository is probably newer and it could be that the current nVidia driver has grown more complex and error-prone with the need to support newer generation cards.
It looks like the best bet is to remove Trinity desktop first, because this is the odd thing that practically no one else has (apparently no one else on this board, anyway). Some sort of conflict could occur even if I am in Xfce rather than Trinity. If that doesn't fix it, I guess I'll go back to the OSS nouveau driver. I don't think that is suitable for actual gaming, but this is not the machine I plan to do much gaming on anymore.
Offline
Well, this is why I used a test system first. It's a good way to learn that something sucks before getting to tangled up with it. It turns out the "tde-trinity" package used to install Trinity desktop is a meta package and does not allow uninstall. Aptitude just says it can't find the package. There is apparently no way to get rid of it other than a complete re-install of Devuan. Or maybe some sort of tedious search for all of the packages it pulls in and removing each one.
That leaves removing the nVidia drivers, which will be easier. And if that doesn't fix the problem I can go the full re-install route.
Edit: And things continue to get worse. The supposed command to remove the nVidia drivers doesn't work. Looks like it's re-install no matter what. Ugh... I guess I'll be trying an earlier version of the nVidia drivers after all this trouble.
Last edited by Micronaut (2019-07-26 00:35:50)
Offline
No, it's not the video drivers at all. I had just finished running the installer, and was in the process of adding other things manually, when it happened again. This was with the default nouveau driver in place, and I wasn't using any graphical application like a browser or the image viewer. Just a text editor (mousepad) and the file manager. I can't imagine how any of the small things I like to add could have caused it, so it seems likely to be a compatibility problem with the system itself. Nothing like this occurred with Mint 17.3 on the same hardware. And it sure doesn't happen with Windows. Now I am wondering how to proceed with any further debugging to isolate it further. Is there some sort of "watchdog" you can install in Linux to monitor for some specific condition?
Offline
Maybe the system interrupts reported in /proc/interrupts can help you? If you can observe abnormally large values for a device then maybe that is the one, otherwise you hopefully can exlude some factors.
You can view it with cat /proc/interrupts or watch cat /proc/interrupts to get a live output. My recommendation for best troubleshooting would be to save the output to a file and on a schedule with cron or likewise.
Offline
Interesting that the entire system does not lock up, though. It does seem to be the display that gets interfered with even if it is not specific to the graphical driver. I ran my test system for a few more hours today, and it had more freezes. Once I figure out where to enable compositing, it froze the entire display solid instead of just one window. And yet the streaming audio I was playing continued. But interaction was not possible, and I had to hit the "Big Red Switch" to recover control of the system.
Finally, I went back through the list of things I added when I installed. Only one of them is graphics related, and I thought it was only a set of command line utilities. "mesa-utils" is a package that I've been using since I first learned about Linux. But it's graphics related, and not essential anymore, so I removed it. The system then ran for several more hours with no detectable problems. Hmmm... Could there be a library conflict? The Linux version of DLL Hell? I'll have to run it a few more days to be sure.
Offline
After the freeze problem hit again, I realized I would have to try different hardware. The test system is ~12-year-old hardware. If not for the huge amount of kernel modifications for the Spectre and Meltdown panic, I bet it would still work fine. But things have changed and some hardware is just going obsolete.
The next system is "only" ~5-year-old hardware. A Haswell generation CPU on an Asus motherboard rather than the ancient nForce. Since it is a completely different system, there might be other problems. But I'll be watching for the video freeze problem and report if this occurs again. What concerns me is some of my other systems are older than this, though not as old as the first test system. I hope they are still compatible with all these kernel tweaks.
Offline
Now I am wondering if I ought to open a completely different thread. Before resorting to trying a completely different distro to escape the random freezing problem, I decided to experiment with enabling swap. Since modern computers always have plenty of RAM, at least for ordinary desktop use, I have tended to skip the swap partition and just run any Linux without swap at all. But when I edited a swap partition into my Devuan test system and enabled it, things seem to work much better. Haven't had the time to test extensively yet, but it seems to have run for a whole afternoon without any freezing. This seems bizarre, since I've never come close to filling the RAM on this machine, so I don't see how swap would make any difference. But as I have searched around other forums, the discussions (which can get very technical about kernel issues) seem to say that swap is very deeply embedded in how the kernel works and you ought to have at least a token swap partition on any system.
Offline
Now I am wondering if I ought to open a completely different thread. Before resorting to trying a completely different distro to escape the random freezing problem, I decided to experiment with enabling swap. Since modern computers always have plenty of RAM, at least for ordinary desktop use, I have tended to skip the swap partition and just run any Linux without swap at all. But when I edited a swap partition into my Devuan test system and enabled it, things seem to work much better. Haven't had the time to test extensively yet, but it seems to have run for a whole afternoon without any freezing. This seems bizarre, since I've never come close to filling the RAM on this machine, so I don't see how swap would make any difference. But as I have searched around other forums, the discussions (which can get very technical about kernel issues) seem to say that swap is very deeply embedded in how the kernel works and you ought to have at least a token swap partition on any system.
/swap is always a good idea. In general GNU/Linux will use what is available, if you have more memory available the same DE with the same settings will use more memory, if less is available it will generally be more conservative of the memory usage. Even if you have 16GB of memory /swap is still beneficial. Of course I mean real /swap not this silly swapfile nonsense.
Offline
How nice that your system now seems functional! I too have read some stuff lately about systems with low ram situations.
https://www.phoronix.com/scan.php?page= … ad-Low-RAM
....and this article about the situation was posted just today:
https://www.phoronix.com/scan.php?page= … ry-Monitor
I don't know how much of this is actually connected to your problem, but it is interesting that enabling swap helped you out.
Last edited by climbingturtle (2019-08-21 13:46:26)
Offline
Well, the freezing has hit again. It's very odd how the desktop becomes unresponsive, but any running processes just continue. When my Gkrellm is visible, I can see the process count skyrocket. If only I could figure out what those processes are being created for.
Now I guess I'll have to try a different distro on this hardware, and also install Devuan on another machine that is a bit newer and see what happens.
Offline
top or htop will let you investigate running processes. mate-system monitor is also useful (but pulls in quite a few gnome deps).
Online
@Micronaut Hello, I think I have the same problem as you and it was very difficult to isolate. This is what happen for me and when it happen.
My OS is Devuan Ascii 64 bit with XFCE on the following hardware :
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)
00:02.0 Display controller: Intel Corporation HD Graphics 530 (rev 06)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
CPU : Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
MEM : 32 Go
SSD : 500 Go
And the problem occurs with Virtualbox. I have a guest with the same OS : Devuan Ascii 64 bit installed on that VM.
Suddenly the desktop seems frozen : I can move the mouse but I cannot click anywhere (nothing happen). What I noticed is the keyboard remains functional inside the VM and I'm trapped inside the VM, I can not go out. So when it happens, I just close all the applications with ALT+F4 and close XFCE with ALT+F4 and only after the VM is completly shutdown I recover the desktop (acting normaly).
I used the nouveau and proprietary (apt-get install nvidia-driver) and that changed nothing. And I think the virtualbox graphic driver changes nothing (VBoxVGA, VMSVGA, VBoxSVGA)
It happens two or three times a week.
Offline
Skylake (and other *lake processors) have been troublesome for years. That may or may not be the OP's issue but there could be something useful in that thread. There are other references to Skylake on this forum too.
Online
@golinux Oh Thank you, I didn't know that, I think I will try this soon :-)
Offline
This is a much older system, and I've not gotten to the point of setting up any VMs yet. But who knows, there could be a relationship between the problems since they are so similar.
Just today I've gotten MX Linux 18.3 setup on this system that was having the problems. Now I just need to run it for a while and see if something similar happens. And I'll be installing Devuan Ascii on some other newer systems soon.
Offline
Further experiments, this time on an MSI motherboard with the G41 chipset, using an E8600 ("Wolfdale"). This is a "hybrid" system that allowed DDR3 to be used with some of the the older generation CPUs from the DDR2 generation. So far it has not experienced any hard freezes, but this is only the first day. It does experience little 'glitches' where it freezes for just a moment. It's difficult to say if these are not caused by something else. Many things can make your system pause for a moment.
00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 01)
00:1c.2 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 3 (rev 01)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1)
03:00.0 Ethernet controller: Qualcomm Atheros AR8131 Gigabit Ethernet (rev c0)
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz
stepping : 10
microcode : 0xa07
cpu MHz : 2003.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm kaiser tpr_shadow vnmi flexpriority dtherm
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 6666.68
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz
stepping : 10
microcode : 0xa07
cpu MHz : 2670.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm kaiser tpr_shadow vnmi flexpriority dtherm
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 6666.68
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Offline
I'm sorry to revive a so old thread but exactly same issue since months/year happen and not only on this computer. Nvidia or AMD seem not change anything read somewhere that's caused by login interface why I replace lighdm by slim.
My problem is similar often only one window work and all other are "unreachable" with mouse.
With keyboard you can change switch between windows and terminal work but mouse just can't select windows.
Sometime by right clicking everywhere you can change focus to another window but still locked on this windows with mouse.
Reboot often give the exact same issue each time for solve my issue I open a terminal and restart slim. That's restart whole GUI and work fine after that. This problem come totally random sometime at boot and sometime nothing during weeks.
I read somewhere that's an issue caused between login manager and gnome. I use mate and slim on all computers.
Same type of issue happen sometime when wake up from sleep you just can't login because can't select password field and can't enter the password. Rebooting slim in a terminal work but you lost all open windows.
If this can help someone
Offline
Pages: 1