[opensuse] Intermittent freezing of system/desktop
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors. Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper. I'm running gkrellm, including its 'Proc' viewer. This shows ~540 processes and 4 users, but when the lockup occurs, the brown graph climbs up to the top of the view port then gradually subsides. I've also tried having htop running, but it doesn't provide much useful information - no CPU hogging, no swapping out, etc. It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act. TIA Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUj3/cACgkQ0Sr7eZJrmU45cQCdG+GhsnwcNKfI+8Cca4VKzwPw UHMAoIEVgJBt4a217Wsv4Ssf+rOjDZtW =n3lq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 07 Apr 2015 14:47:36 +0100 Bob Williams <linux@barrowhillfarm.org.uk> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
I'm running gkrellm, including its 'Proc' viewer. This shows ~540 processes and 4 users, but when the lockup occurs, the brown graph climbs up to the top of the view port then gradually subsides.
I've also tried having htop running, but it doesn't provide much useful information - no CPU hogging, no swapping out, etc.
It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act.
TIA
Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlUj3/cACgkQ0Sr7eZJrmU45cQCdG+GhsnwcNKfI+8Cca4VKzwPw UHMAoIEVgJBt4a217Wsv4Ssf+rOjDZtW =n3lq -----END PGP SIGNATURE-----
This is also occurring in OS 13.1 w/hardware shown below. Tom -- You don't get to choose how you're going to die, or when. You can decide how you're going to live now. -Joan Baez ^^ --... ...-- / -.- --. --... -.-. ..-. -.-. ^^^^ Tom Taylor KG7CFC openSUSE 13.1 (64-bit), Kernel 3.11.6-4-default, KDE 4.11.2, AMD A8-7600, GeForce GTX 740 T/PCIe/ 16GB RAM -- 3x1.5TB sata2 -- 128GB-SSD FF 37.0, claws-mail 3.10.1 registered linux user 263467 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 7, 2015 3:46:31 PM PDT, Thomas Taylor <linxt@comcast.net> wrote:
On Tue, 07 Apr 2015 14:47:36 +0100 Bob Williams <linux@barrowhillfarm.org.uk> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
I'm running gkrellm, including its 'Proc' viewer. This shows ~540 processes and 4 users, but when the lockup occurs, the brown graph climbs up to the top of the view port then gradually subsides.
I've also tried having htop running, but it doesn't provide much useful information - no CPU hogging, no swapping out, etc.
It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act.
TIA
Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlUj3/cACgkQ0Sr7eZJrmU45cQCdG+GhsnwcNKfI+8Cca4VKzwPw UHMAoIEVgJBt4a217Wsv4Ssf+rOjDZtW =n3lq -----END PGP SIGNATURE-----
This is also occurring in OS 13.1 w/hardware shown below.
Tom
Last time I saw this was a dieing drive. Run hdparm, and maybe smartd. A lot of times you can be convinced its ok because something you use rarely will occupy the bad sectors. So check your disk first. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/15 00:13, John Andersen wrote:
Last time I saw this was a dieing drive. Run hdparm, and maybe smartd.
A lot of times you can be convinced its ok because something you use rarely will occupy the bad sectors.
So check your disk first.
Thanks, I should have mentioned the disk hardware. The system (root) is on sda2 and sdg2, /home is on sda3 and sdg3, both in btrfs raid1 configuration. The disks are less than a year old. SMART gives the following: Monitoring 2 ATA and 0 SCSI devices Device: /dev/sda [SAT], opened ATA device Device: /dev/sda [SAT], previous self-test completed without error Device: /dev/sdg [SAT], opened ATA device Device: /dev/sdg [SAT], previous self-test completed without error [...] Started with '-q onecheck' option. All devices sucessfully checked once. smartd is exiting (exit status 0) Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUlXvEACgkQ0Sr7eZJrmU7BXgCePj3udawMwOJq0WPslOvPZRt4 YAUAn0DKpaaZ24P9bFz8CkdmlCXFAwJW =KJkd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2015 09:47 AM, Bob Williams wrote:
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
....
It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act.
There are a number of issues that might come into play, but it all gets back to the fact that Linux is not a Real Time Operating System with a guaranteed response time. While it is possible to configure stock Linux to do a good job in that area, it also requires making sure that the right application are used, that the hardware performs properly and more. As John points out, dying disks can produce this phenomena; anything that eats time in the kernel, spin loops, waiting for events, means user level processing isn't being done. I once wrote a disk driver for V7 UNIX that did bad sector handling in the kernel. On poor reads it re-read, perhaps used the checksum to try error correction. Oh, it worked, it worked well, but all that was done in the kernel with interrupts turned off! That mouse events, a very high priority, still respond, means your machine isn't dead :-) I can repeat this phenomena. If I'm in eBay and visit a site and using Firefox, and click items to open them in a background tab, and do this a lot, then suddenly the machine freezes. If I kill Firefox the machine comes back. if, during that, I hot key out of X/KDE to a VT running root and use 'w' or 'top' I see I have a load factor of 10 ...1 ..12. 15...20 ...25 YIKES And I see that the amount of swap being used is rising ... Rising Conclusion: FF has a memory leak. Well actually on close examination, opening just one or two tabs, I see that it isn't actually FF but rather a plugin -- its the 'plugin container' that is at the top of the list showing excessive CPU consumption. I suspect that it might be associated with displaying an animation, graphic or possibly an embedded video/animation. We can. Perhaps, blame any oen f a number of well known plugins for this :-0 The other occurrence seems to be with the dreaded LinkedIn. I get pop-ups telling me that a JavaScript isn't responding. What it means is that its in a spin loop of some kind. In short, what we have is complex programs interacting in strange ways. The great power of UNIX of the 1970s era, what made it revolutionary compared to the mainframe applications of the day, was that it was made up of short lived, small programs that were strung togehter with poles and scripting. By comparison, the mainframes were running things like CICS which were so enormous, so complex that they did all their database and teleprocessing internally. One huge address space. It grew so complex that IBM had to come up with a way of extending the address space so as to accommodate it! UNIX of the 1970s era was roll-in/roll-out not virtual memory. back then we said "Virtual memory means virtual performance". Memory was !expensive! Realistically, an application had about 56K of memory MAX. It produced a particular discipline of programm ing that we don't seem to have today. Some intermediate era GUI front ends were just that, perhaps a shell script that used termcap/terminfo and like the CLI shell scripts of old ran processes to do the work and filtered the results for display. These were still 'slim'. The work was not in the GUI. Along the way we had the intermediate of Tk, with Perl or some other scripting language that was more capable that the traditional shell. You could do a lot with Perl, but you still made calls to regular programs to do specific work. But once you reach a certain level of sophistication things have to be dragged into the GUI body, and once that threshold is passed then programmers naturally work that way. It might be possible to write a mail UI in Perl/Tk that makes use of many external programs. You may even be happier using your favourite editor for message composition :-) Heck, the Thunderbird 'enigmail' plug-in does use an external OpenPGP application. But the gVIM spell checker is .... Lets face it, clunky. See http://emailproject.perl.org/ http://www.perl.com/pub/2004/06/10/email.html http://perlcomposer.sourceforge.net/ https://glade.gnome.org/ I don't know of an off-the-shelf Perl based email GUI or one for browsing the web. I'm not familiar with Python. The real enemy here is complexity. It the enemy of security, traditionally, and if you count the 'availability' aspect of security http://en.wikipedia.org/wiki/Information_security#Availability then its 'in scope'. As i said, what made UNIX revolutionary was that it broke away from the idea that a program had to encompass everything on one address space with all the threads and interactions etc which came with that approach. We seem to have rescinded this paradigm shift. We are paying the price. We are justifying it on the alter of 'performance'. Personally I think our edifice is too high (or deep) When I look at what it took in V7 for a character being typed on the keyboard to being echoed on the screen, and I look at what it takes to do the same using KDE (or gnome or even LXDE or e16 or xfce) I'm amazed. X was, is, just so comprehensive, so far reaching, that it astounding it works at all. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2015-04-08 at 10:36 -0400, Anton Aylward wrote:
On 04/07/2015 09:47 AM, Bob Williams wrote:
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors. Every so often, the system freezes for between 5 and 60 seconds.
Not this is not normal.
mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper. It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act.
Can you still switch virtual terminals? Ctrl-Alt-F1, for example? Often that still works when a system is "frozen" as the system is not frozen - the DE is frozen. If so log in on tty1, run top, and go back to the DE and start working. Then when it freezes pop back to tty1 and see what is what? Might be informative, might not.
There are a number of issues that might come into play, but it all gets back to the fact that Linux is not a Real Time Operating System with a guaranteed response time.
Hmmmm. A 5 to 60 second free is not an RTOS issue; some hardware or software in the system is a problem.
That mouse events, a very high priority, still respond, means your machine isn't dead :-)
Yep, the first part is to figure out what is actually "frozen".
I can repeat this phenomena. If I'm in eBay and visit a site and using Firefox, and click items to open them in a background tab, and do this a lot, then suddenly the machine freezes. If I kill Firefox the machine comes back. if, during that, I hot key out of X/KDE to a VT running root and use 'w' or 'top' I see I have a load factor of 10 ...1 ..12. 15...20 ...25 YIKES And I see that the amount of swap being used is rising ... Rising Conclusion: FF has a memory leak. Well actually on close examination, opening just one or two tabs, I see that it isn't actually FF but rather a plugin -- its the 'plugin container'
Oh, yeah. I've seen that. It would be nice if there were defined cgroups for common applications. Like just kill firefox if it or its children climb past 4GB.
As i said, what made UNIX revolutionary was that it broke away from the idea that a program had to encompass everything on one address space with all the threads and interactions etc which came with that approach. We seem to have rescinded this paradigm shift.
Ugh, this historical trope. (A) It was never true that UNIX/LINUX was nicely modular (B) Modern systems, include modern DEs like GNOME, are extremely modular and competent oriented - they just stitch things together [rather] seamlessly [when it works] (C) It doesn't matter either way in diagnosing a problem. A problem plaguing LINUX desktops is that modern "PC" hardware is a cheap mish-mash of any-odd-thing. -- Adam Tauno Williams <mailto:awilliam@whitemice.org> GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2015 11:05 AM, Adam Tauno Williams wrote:
If I kill Firefox the machine comes back.
if, during that, I hot key out of X/KDE to a VT running root and use 'w' or 'top' I see I have a load factor of 10 ...1 ..12. 15...20 ...25 YIKES And I see that the amount of swap being used is rising ... Rising Conclusion: FF has a memory leak. Well actually on close examination, opening just one or two tabs, I see that it isn't actually FF but rather a plugin -- its the 'plugin container' Oh, yeah. I've seen that. It would be nice if there were defined cgroups for common applications.
I can still, manually, kill firefox from a root login at a VT. But it would be nice to have firefox running, as you say, in a container that limited how much memory, or CPU it can have. I'd happily put up wuth FF alone 'freezing' so long as it didn't drag down the rest of the system. I think a few here would agree on that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2015 11:05 AM, Adam Tauno Williams wrote:
There are a number of issues that might come into play, but it all gets back to the fact that Linux is not a Real Time Operating System with a guaranteed response time.
Hmmmm. A 5 to 60 second free is not an RTOS issue; some hardware or software in the system is a problem.
Ultimately we are saying the same thing here. I've dealt with RTOS in avionics and other industrial control applications and the DISCIPLINE surrounding the hardware and software is part of what guarantees the response. Commercial off the shelf and 'white box' equipment isn't spec'd the same way that RTOS grade equipment is. Desktop Linux might be tuned to be more responsive to interactive events than the server model, but there is still no guarantees. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2015 11:05 AM, Adam Tauno Williams wrote:
Ugh, this historical trope. (A) It was never true that UNIX/LINUX was nicely modular (B) Modern systems, include modern DEs like GNOME, are extremely modular and competent oriented - they just stitch things together [rather] seamlessly [when it works] (C) It doesn't matter either way in diagnosing a problem.
We are using 'modular' in two different senses here. You are using 'modular' in the sense of 'structured software', thank you Ed Yourdon and many others. I am using 'modular' in the sense of discrete programs running in separate address spaces communicating using defined protocols over defined communication channels, the separation being enforced by the simple fact that they are not resident in the computer memory at the same time. And that being a roll-in/roll-out model not a virtual memory mapping model. I'm not questioning the 'modular' construction of things like Gnome. I am questioning what amounts to the call-tree and the combinatorial complexity of the execution path and how it all fits into one address space. The Yourdon model of modularity had a pretty strict 'tree' and issues about things like 'stubs'. Once we get into even-driven programming for things like Gnome and many GUI models, MVC and things like call-backs, we open a new can of worms in terms of complexity. All of a sudden 'modularity' has taken on a different meaning. Separate coding of things like 'plugins' that operate in the same address space are now 'modules. And we've all seen how that can produce problems in Firefox and Thunderbird: one of the basic debugging approaches there is to run with plugins disabled. Yes, "that was then, this is now". We have to deal with the "now", but the way we have built our "now" has replicated some of the problems I mentioned with CICS of old building too many functions into one megaprogram/address-space. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/15 16:05, Adam Tauno Williams wrote:
On Wed, 2015-04-08 at 10:36 -0400, Anton Aylward wrote:
On 04/07/2015 09:47 AM, Bob Williams wrote:
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors. Every so often, the system freezes for between 5 and 60 seconds.
Not this is not normal.
mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper. It would seem there may be some process that runs away every so often. Is there some file I can monitor or tail to catch it in the act.
Can you still switch virtual terminals? Ctrl-Alt-F1, for example? Often that still works when a system is "frozen" as the system is not frozen - the DE is frozen.
If so log in on tty1, run top, and go back to the DE and start working. Then when it freezes pop back to tty1 and see what is what? Might be informative, might not.
I think you're right about it being the Desktop Environment. The mouse cursor will move from side to side, but I cannot scroll the message pane in Thunderbird. I cannot switch between virtual desktops or open menus. But all this activity seems to get buffered, so when things come back to life, there is a flurry of activity as it catches up. I have set top running on virtual terminal 2. I previously ran it in konsole, but I guess as that's a GUI app it might not show me what's happening to the system. There is no increase in memory usage, swapping out or CPU hogging during these events.
There are a number of issues that might come into play, but it all gets back to the fact that Linux is not a Real Time Operating System with a guaranteed response time.
Hmmmm. A 5 to 60 second free is not an RTOS issue; some hardware or software in the system is a problem.
That mouse events, a very high priority, still respond, means your machine isn't dead :-)
Yep, the first part is to figure out what is actually "frozen".
I can repeat this phenomena. If I'm in eBay and visit a site and using Firefox, and click items to open them in a background tab, and do this a lot, then suddenly the machine freezes. If I kill Firefox the machine comes back. if, during that, I hot key out of X/KDE to a VT running root and use 'w' or 'top' I see I have a load factor of 10 ...1 ..12. 15...20 ...25 YIKES And I see that the amount of swap being used is rising ... Rising Conclusion: FF has a memory leak. Well actually on close examination, opening just one or two tabs, I see that it isn't actually FF but rather a plugin -- its the 'plugin container'
Oh, yeah. I've seen that. It would be nice if there were defined cgroups for common applications. Like just kill firefox if it or its children climb past 4GB.
As i said, what made UNIX revolutionary was that it broke away from the idea that a program had to encompass everything on one address space with all the threads and interactions etc which came with that approach. We seem to have rescinded this paradigm shift.
Ugh, this historical trope. (A) It was never true that UNIX/LINUX was nicely modular (B) Modern systems, include modern DEs like GNOME, are extremely modular and competent oriented - they just stitch things together [rather] seamlessly [when it works] (C) It doesn't matter either way in diagnosing a problem.
A problem plaguing LINUX desktops is that modern "PC" hardware is a cheap mish-mash of any-odd-thing.
- -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUlYOIACgkQ0Sr7eZJrmU7b7gCgqwDSzg1+hfNYwnbfFpRoQYj0 xYoAmwUszAzOYZ3C345nu7Tux5JnMFdZ =bm11 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2015 01:09 PM, Bob Williams wrote:
I think you're right about it being the Desktop Environment. The mouse cursor will move from side to side, but I cannot scroll the message pane in Thunderbird. I cannot switch between virtual desktops or open menus. But all this activity seems to get buffered, so when things come back to life, there is a flurry of activity as it catches up.
Yes, that makes sense and that's what I see. The system has queued the 'mouse events'
I have set top running on virtual terminal 2. I previously ran it in konsole, but I guess as that's a GUI app it might not show me what's happening to the system.
:-) The same goes for the widgets that show CPU and disk activity, unfortunately :-(
There is no increase in memory usage, swapping out or CPU hogging during these events.
Well *something* is going on! 'Top" used to be able show load average but it doesn't any more. It should show the amount of swap being used, but that's a high water mark, and not the current use. It can show the individual CPU cores activity levels. There's also iotop but its not as easy to interpret. try iotop -P -d 5 -o -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/15 05:10, Anton Aylward wrote:
On 04/08/2015 01:09 PM, Bob Williams wrote:
I think you're right about it being the Desktop Environment. The mouse cursor will move from side to side, but I cannot scroll the message pane in Thunderbird. I cannot switch between virtual desktops or open menus. But all this activity seems to get buffered, so when things come back to life, there is a flurry of activity as it catches up.
Yes, that makes sense and that's what I see. The system has queued the 'mouse events'
I have set top running on virtual terminal 2. I previously ran it in konsole, but I guess as that's a GUI app it might not show me what's happening to the system.
:-)
The same goes for the widgets that show CPU and disk activity, unfortunately :-(
So even though gkrellm shows the increased number of processes, the lack of information on CPU usage, memory, swap etc is unreliable?
There is no increase in memory usage, swapping out or CPU hogging during these events.
Well *something* is going on!
Absolutely.
'Top" used to be able show load average but it doesn't any more. It should show the amount of swap being used, but that's a high water mark, and not the current use. It can show the individual CPU cores activity levels.
There's also iotop but its not as easy to interpret. try iotop -P -d 5 -o
I'll try that Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUmOusACgkQ0Sr7eZJrmU6cIQCdFNMsApYlGoTLLq1MIP/Q5/q0 ssIAoIlG9XCq/wwmB7vDWos3Ow14ZKao =vy+7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/09/2015 04:40 AM, Bob Williams wrote:
I have set top running on virtual terminal 2. I previously ran it in konsole, but I guess as that's a GUI app it might not show me what's happening to the system.
:-)
The same goes for the widgets that show CPU and disk activity, unfortunately :-(
So even though gkrellm shows the increased number of processes, the lack of information on CPU usage, memory, swap etc is unreliable?
As you say, its running under konsole, the GUI, and if the GUI is affected then so are its children & spawned processes, or at very least the ability of the GUI display to keep up with them. What's frozen? Running 'top' on a vt, outside the GUI, avoids the whole issue. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/15 12:25, Anton Aylward wrote:
On 04/09/2015 04:40 AM, Bob Williams wrote:
I have set top running on virtual terminal 2. I previously ran it in konsole, but I guess as that's a GUI app it might not show me what's happening to the system.
:-)
The same goes for the widgets that show CPU and disk activity, unfortunately :-(
So even though gkrellm shows the increased number of processes, the lack of information on CPU usage, memory, swap etc is unreliable?
As you say, its running under konsole, the GUI, and if the GUI is affected then so are its children & spawned processes, or at very least the ability of the GUI display to keep up with them.
What's frozen?
Running 'top' on a vt, outside the GUI, avoids the whole issue.
The freeze just happened again. [Ctrl][Alt][F2] to where htop was running resulted in a rather scrambled display, so even a vt is not immune. Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over. Stable doors and bolting horses comes to mind. ;-) Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUmbswACgkQ0Sr7eZJrmU4SawCbB8o4x2JJPK1XjhuU+KemKHE+ OMgAn2qeCcWXb+Z3tHQhzwPlEzmjWaiN =HXPl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Bob Williams <linux@barrowhillfarm.org.uk> [04-09-15 08:24]:
On 09/04/15 12:25, Anton Aylward wrote: [...]
As you say, its running under konsole, the GUI, and if the GUI is affected then so are its children & spawned processes, or at very least the ability of the GUI display to keep up with them.
What's frozen?
Running 'top' on a vt, outside the GUI, avoids the whole issue.
The freeze just happened again. [Ctrl][Alt][F2] to where htop was running resulted in a rather scrambled display, so even a vt is not immune.
would indicate a display/display-driver problem?
Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over.
would enhance the indication of display or driver prob. Haven't followed that closely, do you have access to a different video-driver version you can try? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 09.04.2015 um 14:28 schrieb Patrick Shanahan:
* Bob Williams <linux@barrowhillfarm.org.uk> [04-09-15 08:24]:
On 09/04/15 12:25, Anton Aylward wrote: [...]
As you say, its running under konsole, the GUI, and if the GUI is affected then so are its children & spawned processes, or at very least the ability of the GUI display to keep up with them.
What's frozen?
Running 'top' on a vt, outside the GUI, avoids the whole issue.
The freeze just happened again. [Ctrl][Alt][F2] to where htop was running resulted in a rather scrambled display, so even a vt is not immune.
would indicate a display/display-driver problem?
Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over.
would enhance the indication of display or driver prob.
Haven't followed that closely, do you have access to a different video-driver version you can try?
I had similar problems due to a bad contact between graphic card and motherboard. There must have been a little "crack" that opened when the card or the MB got too hot. I changed the card to another slot and that solved the problem for a year... ... then the card sometimes got very hot and "disappeared": I had to clean the fan of the card with a vacuum cleaner... ... finally firefox's inability to release memory of closed windows makes the system slow up to a "freeze" for a limited time, but opening next window leads to next temporary freeze. (I often work link lists of tumblr photo sites, opening the links in new windows. Each window adds memory, at 2 GB firefox gets notably slower, at 4 GB firefox gets almost unusable, at 6 or 7 GB the whole system begins to suffer...). The only "help" is to terminate all firefox processes.... -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/09/2015 08:21 AM, Bob Williams wrote:
Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over.
The conditions under which that is helpful are limited. It may be that an application is asking the display layer that Xorg uses to do something pernicious. It may be that your video driver has a syndromic bug. So... What display hardware/driver do you use? If you use KDE, then systemsettings -> Desktop effects use the 'advanced' tab The first two options let you alter how the kwin layer works. openGL vs raster and Qt graphics being native or raster. Presumably similar exists for Gnome. I can't say what combination works for who/what/when. its a YMMV thing. But there you are, try that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/15 13:38, Anton Aylward wrote:
On 04/09/2015 08:21 AM, Bob Williams wrote:
Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over.
The conditions under which that is helpful are limited.
It may be that an application is asking the display layer that Xorg uses to do something pernicious.
It may be that your video driver has a syndromic bug.
So...
What display hardware/driver do you use?
nVidia 9600GT using proprietary nvidia drivers.
If you use KDE, then
systemsettings -> Desktop effects
use the 'advanced' tab
The first two options let you alter how the kwin layer works.
openGL vs raster
and
Qt graphics being native or raster.
Interesting. I found I was using openGL 2.0. I changed this to openGL 3.1. Will report back after a suitable test interval.
Presumably similar exists for Gnome.
I don't use Gnome
I can't say what combination works for who/what/when. its a YMMV thing. But there you are, try that.
Thank you. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUmh34ACgkQ0Sr7eZJrmU6g9gCgqiX6n42WcYc/cRXsJT9YKSzg fKEAoKiq3TS98zwuY64PxzkPyjpNPW5V =6AcI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 09 of April 2015 13:21:34 Bob Williams wrote:
Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over.
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch? -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/15 22:18, auxsvr@gmail.com wrote:
On Thursday 09 of April 2015 13:21:34 Bob Williams wrote:
Two processes seemed to be using a lot of processor power, namely kwin_X11 using 100% of one core, and /usr/bin/Xorg which was initially using >90% of a core, but then settled down to <1% after kwin_X11 took over.
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it? - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUnhM8ACgkQ0Sr7eZJrmU4PfgCgl97N1nr5PMvS9L7HjK8ulaVq I28An0CdQIIyYqJ1WAZbG5yk1ngnzE5h =MNcr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 10 of April 2015 09:07:44 Bob Williams wrote:
On 09/04/15 22:18, auxsvr@gmail.com wrote:
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it?
Try installing a package from here[1]. After installation, kill kwin_x11 and start the new one from a shell or krunner. -- Regards, Peter -------- [1] http://software.opensuse.org/download.html?project=KDE%3AFrameworks5&package=kwin5 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/15 14:36, auxsvr@gmail.com wrote:
On Friday 10 of April 2015 09:07:44 Bob Williams wrote:
On 09/04/15 22:18, auxsvr@gmail.com wrote:
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it?
Try installing a package from here[1]. After installation, kill kwin_x11 and start the new one from a shell or krunner.
OK. Done that. I'll report back here later. Thanks Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUn148ACgkQ0Sr7eZJrmU6loQCgmIT6SVV3QuhizbjCI2uyUj5l 7yQAni0FRVA6G3z+AD9xXAE4TMVPJ3eO =2eo0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/15 15:00, Bob Williams wrote:
On 10/04/15 14:36, auxsvr@gmail.com wrote:
On Friday 10 of April 2015 09:07:44 Bob Williams wrote:
On 09/04/15 22:18, auxsvr@gmail.com wrote:
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it?
Try installing a package from here[1]. After installation, kill kwin_x11 and start the new one from a shell or krunner.
OK. Done that. I'll report back here later.
Thanks
Bob
AFAICT the update kwin_x11 seems to have stopped the system-wide freezes that I was experiencing before. Thanks Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUqFSoACgkQ0Sr7eZJrmU5xcQCfczgh7RG772mIQ6Gj836SLT9p 3XcAn3Q5Uct79GvAPUtajzvep2ARI5tc =qOqj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/15 07:48, Bob Williams wrote:
On 10/04/15 15:00, Bob Williams wrote:
On 10/04/15 14:36, auxsvr@gmail.com wrote:
On Friday 10 of April 2015 09:07:44 Bob Williams wrote:
On 09/04/15 22:18, auxsvr@gmail.com wrote:
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it?
Try installing a package from here[1]. After installation, kill kwin_x11 and start the new one from a shell or krunner.
OK. Done that. I'll report back here later.
Thanks
Bob
AFAICT the update kwin_x11 seems to have stopped the system-wide freezes that I was experiencing before.
Spoke too soon. :-( It just happened again, after I'd started playing some music (which I hadn't tried in the couple of days since applying the patch). Lasted about 10 seconds. So, that brings mpd, pulseaudio and alsa into the mix... Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUqe4IACgkQ0Sr7eZJrmU4AHwCfSy22vlR4y6g0xP+kvvLWmSk1 a1YAoIoG3y4ePccqCiI7xnPkn7mzobHJ =OtKg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/15 15:04, Bob Williams wrote:
On 12/04/15 07:48, Bob Williams wrote:
On 10/04/15 15:00, Bob Williams wrote:
On 10/04/15 14:36, auxsvr@gmail.com wrote:
On Friday 10 of April 2015 09:07:44 Bob Williams wrote:
On 09/04/15 22:18, auxsvr@gmail.com wrote:
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it?
Try installing a package from here[1]. After installation, kill kwin_x11 and start the new one from a shell or krunner.
OK. Done that. I'll report back here later.
Thanks
Bob
AFAICT the update kwin_x11 seems to have stopped the system-wide freezes that I was experiencing before.
Spoke too soon. :-( It just happened again, after I'd started playing some music (which I hadn't tried in the couple of days since applying the patch). Lasted about 10 seconds.
So, that brings mpd, pulseaudio and alsa into the mix...
And htop running on vt2 confirms that kwin_x11 was running at 100% on one (of four) cores during this event. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUqfkoACgkQ0Sr7eZJrmU41uwCgn561RW1epFfNSt2IWKvpz1n+ 0CIAnR1FNg/bTx/Y+mUspr2Eci50EKge =t58n -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 12 of April 2015 15:04:52 Bob Williams wrote:
Spoke too soon. :-( It just happened again, after I'd started playing some music (which I hadn't tried in the couple of days since applying the patch). Lasted about 10 seconds.
Perhaps this bug report[1] is related? The common cause seems to be a driver bug. If so, a backtrace of kwin_x11 while stuck should point to the nvidia driver. -- Regards, Peter -------- [1] https://bugs.kde.org/show_bug.cgi?id=346116 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/15 00:32, auxsvr@gmail.com wrote:
On Sunday 12 of April 2015 15:04:52 Bob Williams wrote:
Spoke too soon. :-( It just happened again, after I'd started playing some music (which I hadn't tried in the couple of days since applying the patch). Lasted about 10 seconds.
Perhaps this bug report[1] is related? The common cause seems to be a driver bug. It sounds very similar, so yes, it's likely to be the same bug.
If so, a backtrace of kwin_x11 while stuck should point to the nvidia
driver.
I'd be glad to help, but I don't know how. I'm not a professional, but can follow simple, explicit instructions. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUrmzwACgkQ0Sr7eZJrmU4fEgCfXStf+37Hn4EmbrOQmvtdH5mn jPwAnjoE4leECj2LzGxI4YYfeS+9FXYs =0sRO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I have been having this same Issue (I think). As you may be aware my Nvidia 9500GT packed up a few weeks ago and I now have an NVIDIA 9600GSO Ever since I have had this card my entire plasma desktop freezes intermittently (as you guys have described) although the following situations replicate the issue every time: running Kerbal Space Program and waiting for the GPU temp to get to 70 degrees C running Google Maps in firefox and entering street view (CPU goes to 100% then entire dektop freezes) running Google Earth and having the mouse cursor outside the Google Earth window when the 'world' is still loading (CPU goes to 100% then entire dektop freezes) I have the official NVIDIA drivers installed from the community repo. I have re-installed opensuse entirely from the DVD (checked the DVD as well) and same issue. I never had this issue with my 9500GT at all, but now I can't use those 3 programs at all. I am forced to raise elephants (Magic sysrq) to reboot. On 13 April 2015 at 11:32, Bob Williams <linux@barrowhillfarm.org.uk> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 13/04/15 00:32, auxsvr@gmail.com wrote:
On Sunday 12 of April 2015 15:04:52 Bob Williams wrote:
Spoke too soon. :-( It just happened again, after I'd started playing some music (which I hadn't tried in the couple of days since applying the patch). Lasted about 10 seconds.
Perhaps this bug report[1] is related? The common cause seems to be a driver bug. It sounds very similar, so yes, it's likely to be the same bug.
If so, a backtrace of kwin_x11 while stuck should point to the nvidia
driver.
I'd be glad to help, but I don't know how. I'm not a professional, but can follow simple, explicit instructions.
Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlUrmzwACgkQ0Sr7eZJrmU4fEgCfXStf+37Hn4EmbrOQmvtdH5mn jPwAnjoE4leECj2LzGxI4YYfeS+9FXYs =0sRO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/15 14:31, Paul Groves wrote:
On 13 April 2015 at 11:32, Bob Williams <linux@barrowhillfarm.org.uk> wrote: On 13/04/15 00:32, auxsvr@gmail.com wrote:
On Sunday 12 of April 2015 15:04:52 Bob Williams wrote:
Spoke too soon. :-( It just happened again, after I'd started playing some music (which I hadn't tried in the couple of days since applying the patch). Lasted about 10 seconds.
Perhaps this bug report[1] is related? The common cause seems to be a driver bug. It sounds very similar, so yes, it's likely to be the same bug.
driver.
I'd be glad to help, but I don't know how. I'm not a
If so, a backtrace of kwin_x11 while stuck should point to the nvidia professional, but can follow simple, explicit instructions.
I have been having this same Issue (I think). As you may be aware my Nvidia 9500GT packed up a few weeks ago and I now have an NVIDIA 9600GSO
Ever since I have had this card my entire plasma desktop freezes intermittently (as you guys have described) although the following situations replicate the issue every time:
running Kerbal Space Program and waiting for the GPU temp to get to 70 degrees C running Google Maps in firefox and entering street view (CPU goes to 100% then entire dektop freezes) running Google Earth and having the mouse cursor outside the Google Earth window when the 'world' is still loading (CPU goes to 100% then entire dektop freezes)
I have the official NVIDIA drivers installed from the community repo. I have re-installed opensuse entirely from the DVD (checked the DVD as well) and same issue.
I never had this issue with my 9500GT at all, but now I can't use those 3 programs at all. I am forced to raise elephants (Magic sysrq) to reboot.
Interesting. I just tried launching GoogleEarth and can confirm that it freezes the system, with kwin_x11 running at 100% on one core. However, once GoogleEarth had loaded it was usable, with CPU usage dropping back to normal. The desktop then worked OK. But, when nothing appears to be amiss with the desktop GUI, if I then [Ctrl][Alt][F2], where I have htop running, it triggers kwin_x11 to use 100%. This continues until I do [Ctrl][Alt][F7] to get back to graphical mode, when CPU usage then drops back to normal (I have gkrellm running on the graphical desktop). Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUrzqsACgkQ0Sr7eZJrmU6wLACfVHwhMkyk3dOmrj3PJLqKGC2G lagAnjRnRTmhDoHe4+gY5swgtV9lkZom =2qq4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/10/2015 09:36 AM, auxsvr@gmail.com wrote:
On Friday 10 of April 2015 09:07:44 Bob Williams wrote:
On 09/04/15 22:18, auxsvr@gmail.com wrote:
Recently a patch was added to kwin5, so that a bug related to freezes with nvidia graphics cards is resolved. Could you try updating to the latest kwin5 with fix_nvidia.patch?
I'd be happy to. Where do I find it, and how do I run it?
Try installing a package from here[1]. After installation, kill kwin_x11 and start the new one from a shell or krunner.
Is this patch available without having to install the KDE5 framework? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-08 16:36, Anton Aylward wrote:
Conclusion: FF has a memory leak.
If you use addblock (or similar), on certain pages the amount of used memory skyrockets. I remember reading about the issue. A certain sample web page could use gigabytes.
Well actually on close examination, opening just one or two tabs, I see that it isn't actually FF but rather a plugin -- its the 'plugin container' that is at the top of the list showing excessive CPU consumption. I suspect that it might be associated with displaying an animation, graphic or possibly an embedded video/animation. We can. Perhaps, blame any oen f a number of well known plugins for this :-0
Typically flash. That's why I block all flash with "flashblock", and only allow it on the pages or frames I want. It causes problems on youtube, though, when html5 and flash both compete to render the same video, and both fail. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUlTB4ACgkQja8UbcUWM1wb0gEAmkhErLGdGnkxyZPtaX0rBwb4 XeZLg+/jB64dLF7o9YgA/23l5LvOyqZGYxcUIdXQBU2PGYSAAeV/2glej9waDZXd =xNdD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2015 08:47 AM, Bob Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
While some others report no issue, I can confirm this issue along with Anton. I'm running 13.1 2G/KDE3 but on Radeon w/default drivers from X, new disk, no errors. I too see to suspect this is due to a mozilla app, either FF or TB. For example, in just typing this e-mail, I typed "FF or T"... the box hung for ~5 seconds, then "B" appeared. I've looked and I can't pin it down either, other than to say it is "irritating". -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-11 02:59, David C. Rankin wrote:
While some others report no issue, I can confirm this issue along with Anton. I'm running 13.1 2G/KDE3 but on Radeon w/default drivers from X, new disk, no errors. I too see to suspect this is due to a mozilla app, either FF or TB. For example, in just typing this e-mail, I typed "FF or T"... the box hung for ~5 seconds, then "B" appeared.
Thunderbird stalls itself for some seconds when it is polling for email or nntp (specially the later). It stops responding to keyboard or mouse. But everything else in the machine continues responding fine, as long af you have more cpu cores and the disk is not too busy. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUoeQUACgkQja8UbcUWM1wTqQEAjXlLXXxOASC1HZhpLkM/NLKR BPQQ9vifSfrLzckAe60A/35VgKVIGrvnbW2+vVaBvzOAR8gA/ZoXMvFnbL0pUBIM =v1c7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/10/2015 09:29 PM, Carlos E. R. wrote:
Thunderbird stalls itself for some seconds when it is polling for email or nntp (specially the later). It stops responding to keyboard or mouse. But everything else in the machine continues responding fine, as long af you have more cpu cores and the disk is not too busy.
I have the applet in my bottom panel that shows CPU activity. I have a 4-core CPU and I have the applet set to display all/each core. When this phenomena with FF happens ALL FOUR CORES are at 100% -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/10/2015 08:44 PM, Anton Aylward wrote:
On 04/10/2015 09:29 PM, Carlos E. R. wrote:
Thunderbird stalls itself for some seconds when it is polling for email or nntp (specially the later). It stops responding to keyboard or mouse. But everything else in the machine continues responding fine, as long af you have more cpu cores and the disk is not too busy.
I have the applet in my bottom panel that shows CPU activity. I have a 4-core CPU and I have the applet set to display all/each core.
When this phenomena with FF happens ALL FOUR CORES are at 100%
I'll attribute most of it to Tbird since I have it running all the time and it does poll every 10 minutes. You'd think they would have pthreads down by now... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-11 05:55, David C. Rankin wrote:
On 04/10/2015 08:44 PM, Anton Aylward wrote:
On 04/10/2015 09:29 PM, Carlos E. R. wrote:
I'll attribute most of it to Tbird since I have it running all the time and it does poll every 10 minutes. You'd think they would have pthreads down by now...
I know that, in my case, thunderbird stalls periodically at a fixed interval, when it polls the local leafnode nntp store (which is big and fast). It takes several seconds to do it, and doesn't respond to the keyboard or refresh the display meanwhile. But everything else in the computer continues working fine (except perhaps disk i/o). This is a different thing than what some of you describe that the entire computer stalls. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUphTEACgkQja8UbcUWM1xYawD+PSIE7S37+dppbEuA5WMp9fCa yf6LGXF663DVB8ZU1ZoA/j0K+w4CwgbJojyl6F5Hv5QbVeU9MN9grVCnRonIJJSj =e9dy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/15 21:33, Carlos E. R. wrote:
On 2015-04-11 05:55, David C. Rankin wrote:
On 04/10/2015 08:44 PM, Anton Aylward wrote:
On 04/10/2015 09:29 PM, Carlos E. R. wrote:
I'll attribute most of it to Tbird since I have it running all the time and it does poll every 10 minutes. You'd think they would have pthreads down by now...
I know that, in my case, thunderbird stalls periodically at a fixed interval, when it polls the local leafnode nntp store (which is big and fast). It takes several seconds to do it, and doesn't respond to the keyboard or refresh the display meanwhile. But everything else in the computer continues working fine (except perhaps disk i/o).
This is a different thing than what some of you describe that the entire computer stalls.
I agree. I also see Firefox hogging CPU cycles and gradually accumulating memory, but this is not the effect I was describing in the original post. That problem appears to have been solved by an update to kwin_x11. See Message ID <552A152D.30208@barrowhillfarm.org.uk> in another part of this thread. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUqK6EACgkQ0Sr7eZJrmU7UUwCfXm87U8vcj7yknER7PcwGEWZ/ p+4AoKTAYK09bhiTjlZdLgrb+zWyI3bv =SamU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2015 03:24 AM, Bob Williams wrote:
I agree. I also see Firefox hogging CPU cycles and gradually accumulating memory, but this is not the effect I was describing in the original post. That problem appears to have been solved by an update to kwin_x11.
See Message ID<552A152D.30208@barrowhillfarm.org.uk> in another part of this thread.
Bob
Thank God for KDE3, I was blissfully unaware of any issue other then tbird blocking my keyboard input during polling of mail hosts. Kudos to Ilya who has done a great job with it for 13.1. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/10/2015 05:59 PM, David C. Rankin wrote:
On 04/07/2015 08:47 AM, Bob Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
While some others report no issue, I can confirm this issue along with Anton. I'm running 13.1 2G/KDE3 but on Radeon w/default drivers from X, new disk, no errors. I too see to suspect this is due to a mozilla app, either FF or TB. For example, in just typing this e-mail, I typed "FF or T"... the box hung for ~5 seconds, then "B" appeared.
I've looked and I can't pin it down either, other than to say it is "irritating".
Well you could probably confirm your suspicion by using Kmail and Kong for a week and see if the problem goes away. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin composed on 2015-04-10 19:59 (UTC-0500):
Bob Williams wrote:
I've had this problem off and on for several years, and over several iterations of openSUSE. My current setup is openSUSE 13.2 desktop with KDE5/plasma5. Graphics card is nVidia 9600GT running the latest nVidia proprietary drivers, driving twin monitors.
Every so often, the system freezes for between 5 and 60 seconds. The mouse cursor still moves, but windows won't scroll, desktops won't switch and often sound gets cutoff for the duration of the freexe-up. It's irritating, but not a show stopper.
While some others report no issue, I can confirm this issue along with Anton. I'm running 13.1 2G/KDE3 but on Radeon w/default drivers from X,
Fanless X600 on 32bit 13.1/KDE3 with radeon here too, first mention of shared non-Mozilla connection I've noticed in this thread.
new disk, no errors. I too see to suspect this is due to a mozilla app, either FF or TB. For example, in just typing this e-mail, I typed "FF or T"... the box hung for ~5 seconds, then "B" appeared.
I've looked and I can't pin it down either, other than to say it is "irritating".
It's happened to me too, but too rarely to "pin it down". I don't remember any more if it's a new development since replacing 11.4 with 13.1, but I do think the frequency has escalated considerably since if it isn't new, from maybe twice or thrice a year to maybe once or twice a month. The rarity here could be how I sandbox differently from others. All 5 of my usually open simultaneously Mozillas are started in a MOZ_NO_REMOTE=1 environment, as is any others I open only on occasion. Only one profile knows anything of the existence of Flash, and it gets little active use except for when Flash is required. The rest of the time its 15 tabs are simply parked on the taskbar on a virtual desktop used for nothing else. The only rpm installed is 17-esr, which is the only one ever with few enough open tabs to ever read a whole tab's title. All others are Mozilla binaries. That it ever happens here while the Flash-enabled profile is parked makes me suspect the responsible plugin involved isn't the high-profile one that first comes to mind, but rather Sqlite, which is almost constantly rebuilding the rather consequential places.sqlite, in addition to the other dozen+ .sqlite files it manages. ATM, moz storage or cache show up in iotop -o output at least 1 hit out of every dozen, of which half the rest are kworker or jbd. With so much disk I/O, any kind of glitch in filesystem journaling or systemd journaling presents a highlighted opportunity for one of the Mozillas to stumble. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (12)
-
Adam Tauno Williams -
Anton Aylward -
auxsvr＠gmail.com -
Bob Williams -
Carlos E. R. -
Daniel Bauer -
David C. Rankin -
Felix Miata -
John Andersen -
Patrick Shanahan -
Paul Groves -
Thomas Taylor