Re: [qubes-devel] guidelines for bug reporting?

[Alex Dubois]

Alex

On 17 May 2013, at 19:03, cjle...@gmail.com wrote:

Hi,
let me first say I love Qubes R2B2 from my experience so far.  For a couple of years prior I followed a "qubes-lite" practice of dividing up my work (especially anything that would access the internet, vs. any data I considered sensitive) in separate VMs.  But I find qubes a much nicer way of doing this (e.g. easy copy-paste, not to mention more secure!).  Now that I'm making qubes my primary work environment, I really want to dispense with various bugs I'm consistently hitting, and which I see other users asking about, but which I can't find on the qubes issue tracker (in my limited searching).  So I want advice on how best to get these in the tracker; I would be happy to enter them myself if that's what you want.

Examples on my totally stock install of R2B2 on a 16 GB thinkpad T430 (purchased specifically for Qubes because the HCL showed "OK, OK, OK, ..." as its status on Qubes; the install was effortless and the HCL reporter script reports everything VT-x VT-d etc. working great):

- trying to launch a dispVM reproducibly hangs with dispVM showing 99% cpu usage; log shows a kernel crash...  only way out is to kill the dispVM.  I already asked about this on qubes-users but no resolution.  I noticed that immediately after a templateVM update, I sometimes could get the dispVM to start successfully.  But after a short time it would again kernel crash, same 99% cpu usage etc.

Have you tried from dom0 terminal:

sudo qubes-dom0-update?

- regular appVMs often hit the same bug (startup hangs with 99% cpu usage; only way out is to kill the appVM).  However, because it only happens about half the time, I can just kill and try again.  Once the appVM is running, everything works fine.

- putting qubes to sleep (Leave -> Sleep) causes various kinds of havoc when it awakes: networking is nearly always hosed and no amount of fiddling gets it to work again;  I often hit severe GUI focus issues, e.g. unresponsive windows, typed characters don't show up; unable to do anything but hit the power button...  Workaround: always shutdown, never sleep.  This is made more annoying by the LONG startup and shutdown times (despite my fast SSD!).

- using multiple monitors leads to weird mouse focus issues.  On the one hand I've been impressed with how easily every monitor I've plugged in has been recognized and made to work; on the other hand I'm plagued by "dead spaces" that are unclickable.  I'd ordinarily assume the problem lay in Fedora, but I noticed that the problem seems to be qubes specific.  E.g. right now, I have an external monitor and my laptop display on; everything on the external monitor is clickable but on the laptop display only the dom0 parts are clickable (background, control bar and menus, the color-coded window frames but NOT anything inside an app window).  If I move a window over to the external monitor, then all the contents of the window become clickable.  I've also seen situations where a larger screen is "masked" so that only part of it (I think the same size as the primary display) is clickable, but the rest of the screen is not.

- on a related front, sometimes a window's contents (but not its color-coded frame) become unresponsive to mouse clicks *temporarily*, say for 30 seconds or so.  I've tried all sorts of tricks (e.g. minimizing then reopening) to break out of this, but it seems that only the passage of time clears it up.

Browsing the issue tracker and running simple text searches, I don't find these issues (please correct me if I am wrong!).  I see some other users mentioning similar problems on the qubes forums.  As a software developer, I'm wondering what's the official Qubes process for entering reports into the tracker.  For example, I already reported the dispVM problem on qubes-users, but it doesn't look like anyone entered an issue for this.  The Qubes team is *wonderfully* responsive on the forums (I thank you for that!), but the issue tracker seems to lag.  My personal feeling is: if someone has a reproducible bug, it should be entered into the bug database.  Otherwise it's pretty invisible both to the team and the community.  You have a very engaged and talented user base; getting them to enter and comment on bug reports is a great way to suck them into fixing bugs and become qubes developers.

Just my 2 cents.  Let me know how this should be addressed.

Thanks again for the great work on Qubes!!

Yours with all best wishes,

Chris Lee

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Christopher Lee]

Yes, I ran sudo qubes-dom0-update

That doesn't help.  I also tried to post this reply many times, and it doesn't show up on the forum...

[Alex Dubois]

Alex

On 30 May 2013, at 00:39, Christopher Lee <cjle...@gmail.com> wrote:

Yes, I ran sudo qubes-dom0-update

That doesn't help.  I also tried to post this reply many times, and it doesn't show up on the forum...

I have experienced similar issues to launch new VMs and also getting from time to time warning messages stating that the VM did not release the memory (might not be the message, I am stating from memory), but overall, not so much of a problem to make it difficult to use.

Have you looked in the Qubes logs