Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upslowness of "any" operation #4128
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Possible duplicate of #3639. |
andrewdavidwong
added
bug
C: other
labels
Jul 23, 2018
andrewdavidwong
added this to the Release 4.0 updates milestone
Jul 23, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nailgao
Jul 23, 2018
just thought adding a detail may be relevant:
during the aforementioned long delays of operations, i.e. of launching applications, it doesn't help to click again and again on the respective application in the menu. though it sometimes gets started in the 5th or 10th click, this state makes it seem to me like it is unrelated to whether I click on it again or not.
nailgao
commented
Jul 23, 2018
|
just thought adding a detail may be relevant: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
manasb
Jul 23, 2018
Not sure if this is related but since upgrading to R4.0, my whonix-gw and whonix-ws take an extremely long period of time before successfully launching any program - in this period of time disk is constantly accessed.
Launching whonix-ws and checking on top with the use of sudo xl console whonix-ws in dom0 shows the kswapd0 process consuming 100% CPU for a number of minutes before gradually reducing CPU usage to around 20% but not completely stopping. This kswapd problem was noticable on R3.2 but only sometimes and that too randomly - I did not have a reliable way of reproducing that behavior. Now, however, I am seeing this behavior everytime I start up my whonix-ws or whonix-gw TemplateVMs.
manasb
commented
Jul 23, 2018
|
Not sure if this is related but since upgrading to R4.0, my Launching |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
t4777sd
Jul 24, 2018
This sounds dumb, but are you sure each VM has enough memory and no where in the system is swapping?
t4777sd
commented
Jul 24, 2018
|
This sounds dumb, but are you sure each VM has enough memory and no where in the system is swapping? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
manasb
Jul 24, 2018
Checking with free shows over 1 GB of "available" RAM, so a shortage of RAM doesn't seem to be the cause in my case.
manasb
commented
Jul 24, 2018
|
Checking with |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nailgao
Jul 26, 2018
@manasb, why do you NOT, if you are not sure -as you say- create a new issue for your problem?
don't you see that you break the communication flow of the issue that I created?
what attitude is this?
if it is too much work for you to fill in a new issue, maybe you should turn to other OSes that you will not have to do that!
nailgao
commented
Jul 26, 2018
|
@manasb, why do you NOT, if you are not sure -as you say- create a new issue for your problem? don't you see that you break the communication flow of the issue that I created? what attitude is this? if it is too much work for you to fill in a new issue, maybe you should turn to other OSes that you will not have to do that! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nailgao
Jul 26, 2018
@andrewdavidwong can you please -if technically possible- remove the latter posts that is not related to my issue? or ask the respective dude to delete and publish his issue elsewhere?
if everyone posted own issue under everyone else's issue, what kind of place would this platform become?
nailgao
commented
Jul 26, 2018
•
|
@andrewdavidwong can you please -if technically possible- remove the latter posts that is not related to my issue? or ask the respective dude to delete and publish his issue elsewhere? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nailgao
Jul 26, 2018
also in connection with the issue #4120, the problem persists.
anon-whonix turned instantly unclickable while there were 2 tabs open.
other open apps such as the file manager and disk utility were not affected.
with these "instant freeze" problems of the desktop and in particular the browsers, qubes presents itself no more suitable for daily use. can you please solve these ASAP?
nailgao
commented
Jul 26, 2018
|
also in connection with the issue #4120, the problem persists. anon-whonix turned instantly unclickable while there were 2 tabs open. with these "instant freeze" problems of the desktop and in particular the browsers, qubes presents itself no more suitable for daily use. can you please solve these ASAP? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Jul 27, 2018
Member
@manasb, why do you NOT, if you are not sure -as you say- create a new issue for your problem?
don't you see that you break the communication flow of the issue that I created?
what attitude is this?
if it is too much work for you to fill in a new issue, maybe you should turn to other OSes that you will not have to do that!
@andrewdavidwong can you please -if technically possible- remove the latter posts that is not related to my issue? or ask the respective dude to delete and publish his issue elsewhere?
if everyone posted own issue under everyone else's issue, what kind of place would this platform become?
It doesn't look like @manasb was (intentionally or unintentionally) issue-jacking. Rather, it looks like @manasb commented here because he had reason to believe that he might be having the same problem, which is understandable, given how broad this issue is. This is appropriate conduct, so his comments will not be deleted. Please don't lash out at others like this. Doing so runs contrary to the spirit of our Code of Conduct.
It doesn't look like @manasb was (intentionally or unintentionally) issue-jacking. Rather, it looks like @manasb commented here because he had reason to believe that he might be having the same problem, which is understandable, given how broad this issue is. This is appropriate conduct, so his comments will not be deleted. Please don't lash out at others like this. Doing so runs contrary to the spirit of our Code of Conduct. |
nailgao commentedJul 23, 2018
•
edited
Edited 3 times
-
nailgao
edited Jul 23, 2018 (most recent)
-
nailgao
edited Jul 23, 2018
-
nailgao
edited Jul 23, 2018
-
nailgao
created Jul 23, 2018
Qubes OS version:
4.0.
Affected component(s):
any application, any process run on desktop
Steps to reproduce the behavior:
use your desktop for at least half an hour.
have a number of VMs open, ideally as many as your hardware memory allows you to.
have various applications running; maybe several browser windows, file managers, editors etc..
Expected behavior:
you move back and forth between applications, and smoothly proceed with whatever you are doing.
Actual behavior:
after you are past the first 10-15 minutes of your desktop session, it begins to take "long" to run any operation (mostly starting/running applications).
and after yet another while, it may take AGES to do so.
depending on at which timepoint of your desktop session you do it, the application opens in anywhere from 5 minutes to 15 minutes (and longer!). and this when you have a total of around 10 windows (or less) open on desktop.
so far this happens when you want to start an application from qubes menu on the panel, or else with firefox tabs, like in the issue #4120 that I posted.
yet there have been moments when no click on any spot of the desktop was responsive for long minutes, too.
General notes:
Related issues:
INTERESTING PHENOMENON:
have Qubes developers added any fixes for this problem in the most recent fedora -27 update?
after I updated fedora template today, my last two sessions, particularly my last session, unlike the previous ones severely affected by desktop freezes, have been considerably more pleasant in terms of speed and seamless procession between and within apps.