System is F22 with Xfce
In the past, occasionally I would get what looks like a ScreenSaver popping over what I am viewing. It almost looks legit in content. It goes away if I <alt-tab> to another task then <alt-tab> back. QEMM seems to make it worst (running an 'old' F21/Xfce image there for a specific purpose).
Well with a recent update, I am now getting this flashing regularly. It make using the system very hard. It is much worst in my QEMM image than the main image.
I have looked at the Screensaver settings, and there is nothing there to indicate a problem. Plus I don't think it is really Screensaver which is set to lock the screen immediately (after 10 min of inactivity) which is not the case here.
Any idea where I should look? Yes, I know that I need to update to recent Fedora. That is on for later this week. I hope....
On Mon, 4 Jul 2016 15:25:03 -0400 Robert Moskowitz wrote:
Any idea where I should look? Yes, I know that I need to update to recent Fedora. That is on for later this week. I hope....
Anything like the videos linked to in this bugzilla?
https://bugzilla.redhat.com/show_bug.cgi?id=1352325
This nonsense just started happening to me with the new 4.6 kernel in f24. Not only does the windows 10 virtual machine flake out, but it bleeds into other screens on my desktop.
I'm running the previous 4.5 kernel at the moment with no problems cropping up.
On 07/04/2016 04:01 PM, Tom Horsley wrote:
On Mon, 4 Jul 2016 15:25:03 -0400 Robert Moskowitz wrote:
Any idea where I should look? Yes, I know that I need to update to recent Fedora. That is on for later this week. I hope....
Anything like the videos linked to in this bugzilla?
https://bugzilla.redhat.com/show_bug.cgi?id=1352325
This nonsense just started happening to me with the new 4.6 kernel in f24. Not only does the windows 10 virtual machine flake out, but it bleeds into other screens on my desktop.
I'm running the previous 4.5 kernel at the moment with no problems cropping up.
My problem is that the whole screen blanks out with a dialog box saying XScreenSaver 5.35 with one * in the password field.
If I move the mouse around, pieces of the real screen becomes visible, or I can <alt-tab>. Qemm has become unusable, now as unless I am scrolling constantly, it is switching to this false screensaver.
On 07/04/2016 04:01 PM, Tom Horsley wrote:
On Mon, 4 Jul 2016 15:25:03 -0400 Robert Moskowitz wrote:
Any idea where I should look? Yes, I know that I need to update to recent Fedora. That is on for later this week. I hope....
Anything like the videos linked to in this bugzilla?
https://bugzilla.redhat.com/show_bug.cgi?id=1352325
This nonsense just started happening to me with the new 4.6 kernel in f24. Not only does the windows 10 virtual machine flake out, but it bleeds into other screens on my desktop.
I'm running the previous 4.5 kernel at the moment with no problems cropping up.
Based on your comment, I just rebooted back to kernel 4.4.12 from 4.4.13 and so far no problem. Of course don't know it if was due to something that takes some fulling around to get running...
Problem seems to be back, and I see tumblerd eating up most of one cpu. Something I did caused this to run. Can I just kill it or do I need to kill more than it?
On 07/04/2016 04:01 PM, Tom Horsley wrote:
On Mon, 4 Jul 2016 15:25:03 -0400 Robert Moskowitz wrote:
Any idea where I should look? Yes, I know that I need to update to recent Fedora. That is on for later this week. I hope....
Anything like the videos linked to in this bugzilla?
https://bugzilla.redhat.com/show_bug.cgi?id=1352325
This nonsense just started happening to me with the new 4.6 kernel in f24. Not only does the windows 10 virtual machine flake out, but it bleeds into other screens on my desktop.
I'm running the previous 4.5 kernel at the moment with no problems cropping up.
On 07/04/2016 08:25 PM, Robert Moskowitz wrote:
Problem seems to be back, and I see tumblerd eating up most of one cpu. Something I did caused this to run. Can I just kill it or do I need to kill more than it?
Tumbler appears to be something pulled in by XFCE. It's a dbus service for creating thumbnails, so something must be calling it. I would think that's separate from your screen problem.
It sounds like there's a graphics driver issue. What graphics chipset do you have? Or possibly a window manager issue. Could you try out a different desktop for a while and see if it still happens there?
You keep mentioning QEMM. Do you really mean qemu?
My calling foul on tumblerd was premature. Other than eating up one CPU, it was not causing the 'screensaver' problems. I still get it once in a while, but not like I was getting with the 4.4.13 kernel. I did kill tumblerd; I was viewing some CDs with wedding pictures via gthumb yesterday.
On 07/05/2016 02:10 AM, Samuel Sieb wrote:
On 07/04/2016 08:25 PM, Robert Moskowitz wrote:
Problem seems to be back, and I see tumblerd eating up most of one cpu. Something I did caused this to run. Can I just kill it or do I need to kill more than it?
Tumbler appears to be something pulled in by XFCE. It's a dbus service for creating thumbnails, so something must be calling it. I would think that's separate from your screen problem.
So it seems.
It sounds like there's a graphics driver issue. What graphics chipset do you have?
Been so long since I looked for this info, what is the command for it? This is a Lenovo x120e
Or possibly a window manager issue. Could you try out a different desktop for a while and see if it still happens there?
Not really; I would have to install one. I could boot from a liveCD with GNOME, but I do have real work to do while I am testing...
You keep mentioning QEMM. Do you really mean qemu?
Brain fried. Yes QEMU. It has been a long time since running Quarterdeck's qemm on a 386 to get access to all that extra memory. :)
On 07/05/2016 01:50 PM, Joe Zeff wrote:
On 07/05/2016 10:33 AM, Robert Moskowitz wrote:
Been so long since I looked for this info, what is the command for it? This is a Lenovo x120e
lspci | grep VGA
I have GOT to add this to my list of tools....
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310]
On 07/05/2016 11:01 AM, Robert Moskowitz wrote:
I have GOT to add this to my list of tools....
Here's a one-liner that I've used so often I made a shell script out of it:
ps aux | grep $1 | grep -v grep
I will leave the reason for the second grep as an exercise for the reader.
On 07/05/2016 11:18 AM, Joe Zeff wrote:
On 07/05/2016 11:01 AM, Robert Moskowitz wrote:
I have GOT to add this to my list of tools....
Here's a one-liner that I've used so often I made a shell script out of it:
ps aux | grep $1 | grep -v grep
I will leave the reason for the second grep as an exercise for the reader.
Yeah, I use that one a lot, too. "pidof -x" is useful as well and you don't need the greps. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Is that a buffer overflow or are you just happy to see me? - ----------------------------------------------------------------------
On 07/05/2016 11:35 AM, Rick Stevens wrote:
Yeah, I use that one a lot, too. "pidof -x" is useful as well and you don't need the greps.
One of the wonderful things about *nix is the fact that there are so many different ways to get exactly the same results, depending on personal preference.
On 07/05/2016 01:36 PM, Joe Zeff wrote:
On 07/05/2016 11:35 AM, Rick Stevens wrote:
Yeah, I use that one a lot, too. "pidof -x" is useful as well and you don't need the greps.
One of the wonderful things about *nix is the fact that there are so many different ways to get exactly the same results, depending on personal preference.
Since "pidof" doesn't do the grep, so you need to specify the entire process name (e.g. "pidof chron" gets nothing, "pidof chronyd" gets the PID of the chronyd process).
In that sense, your "ps aux | grep | grep -v grep" is a more flexible in that you only need to know part of the process name. I use it a lot myself--but not to the point of turning it into a script/utility. :) ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------
On 07/05/2016 01:51 PM, Rick Stevens wrote:
In that sense, your "ps aux | grep | grep -v grep" is a more flexible in that you only need to know part of the process name. I use it a lot myself--but not to the point of turning it into a script/utility. :)
In my case, it's not that I use it so much, it's just that I decided that a one-line script was the easiest way to go. Also, I've found that having that extra line at the end listing grep is confusing to average users so I added the second invocation of grep. Besides, the output is much more tidy that way.
On Tue, Jul 05, 2016 at 01:51:48PM -0700, Rick Stevens wrote:
On 07/05/2016 01:36 PM, Joe Zeff wrote:
On 07/05/2016 11:35 AM, Rick Stevens wrote:
Yeah, I use that one a lot, too. "pidof -x" is useful as well and you don't need the greps.
One of the wonderful things about *nix is the fact that there are so many different ways to get exactly the same results, depending on personal preference.
Since "pidof" doesn't do the grep, so you need to specify the entire process name (e.g. "pidof chron" gets nothing, "pidof chronyd" gets the PID of the chronyd process).
In that sense, your "ps aux | grep | grep -v grep" is a more flexible in that you only need to know part of the process name. I use it a lot myself--but not to the point of turning it into a script/utility. :)
There is also "pgrep"
$ pgrep chronyd 1542
$ pgrep chron 1542
$ pgrep fire 1535 8708 21777
$ pgrep -l fire 1535 firewalld 8708 firewall-applet 21777 firefox
$ pgrep -a fire 1535 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid 8708 /usr/bin/python -Es /usr/bin/firewall-applet 21777 /usr/lib64/firefox/firefox
Jon
On 07/05/2016 02:18 PM, Jon LaBadie wrote:
On Tue, Jul 05, 2016 at 01:51:48PM -0700, Rick Stevens wrote:
On 07/05/2016 01:36 PM, Joe Zeff wrote:
On 07/05/2016 11:35 AM, Rick Stevens wrote:
Yeah, I use that one a lot, too. "pidof -x" is useful as well and you don't need the greps.
One of the wonderful things about *nix is the fact that there are so many different ways to get exactly the same results, depending on personal preference.
Since "pidof" doesn't do the grep, so you need to specify the entire process name (e.g. "pidof chron" gets nothing, "pidof chronyd" gets the PID of the chronyd process).
In that sense, your "ps aux | grep | grep -v grep" is a more flexible in that you only need to know part of the process name. I use it a lot myself--but not to the point of turning it into a script/utility. :)
There is also "pgrep"
$ pgrep chronyd 1542
$ pgrep chron 1542
$ pgrep fire 1535 8708 21777
$ pgrep -l fire 1535 firewalld 8708 firewall-applet 21777 firefox
$ pgrep -a fire 1535 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid 8708 /usr/bin/python -Es /usr/bin/firewall-applet 21777 /usr/lib64/firefox/firefox
Ok, now that's one I hadn't heard of. That's nice!
Thanks for the tip! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Real Time, adj.: Here and now, as opposed to fake time, which only - - occurs there and then - ----------------------------------------------------------------------
On Tue, Jul 05, 2016 at 02:34:20PM -0700, Rick Stevens wrote:
On 07/05/2016 02:18 PM, Jon LaBadie wrote:
There is also "pgrep"
$ pgrep chronyd 1542
$ pgrep chron 1542
$ pgrep fire 1535 8708 21777
$ pgrep -l fire 1535 firewalld 8708 firewall-applet 21777 firefox
$ pgrep -a fire 1535 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid 8708 /usr/bin/python -Es /usr/bin/firewall-applet 21777 /usr/lib64/firefox/firefox
Ok, now that's one I hadn't heard of. That's nice!
Thanks for the tip!
Its compabion, pkill, is nice too. Does the pgrep for you.
$ pkill firefox
jl
When Firefox is busy doing something. Like getting all the info to present cnn.com, or waiting for the video download from dafhachaim.org, I get this crazy constant flicking to the fake screensaver while trying to do something in QEMU. I get a bit of it switching workstation sessions, but not like I get in QEMU.
Once Firefox 'stablizes' (cnn.com loaded or daf download going) this behavior stops. Or at least is only a once in a while event.
On 07/05/2016 01:33 PM, Robert Moskowitz wrote:
My calling foul on tumblerd was premature. Other than eating up one CPU, it was not causing the 'screensaver' problems. I still get it once in a while, but not like I was getting with the 4.4.13 kernel. I did kill tumblerd; I was viewing some CDs with wedding pictures via gthumb yesterday.
On 07/05/2016 02:10 AM, Samuel Sieb wrote:
On 07/04/2016 08:25 PM, Robert Moskowitz wrote:
Problem seems to be back, and I see tumblerd eating up most of one cpu. Something I did caused this to run. Can I just kill it or do I need to kill more than it?
Tumbler appears to be something pulled in by XFCE. It's a dbus service for creating thumbnails, so something must be calling it. I would think that's separate from your screen problem.
So it seems.
It sounds like there's a graphics driver issue. What graphics chipset do you have?
Been so long since I looked for this info, what is the command for it? This is a Lenovo x120e
Or possibly a window manager issue. Could you try out a different desktop for a while and see if it still happens there?
Not really; I would have to install one. I could boot from a liveCD with GNOME, but I do have real work to do while I am testing...
You keep mentioning QEMM. Do you really mean qemu?
Brain fried. Yes QEMU. It has been a long time since running Quarterdeck's qemm on a 386 to get access to all that extra memory. :)
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-
Joe Zeff -
Jon LaBadie -
Rick Stevens -
Robert Moskowitz -
Samuel Sieb -
Tom Horsley