Qubes R3.2 - Severe graphics issues/glitches ? (HCL Report included)

74 views
Skip to first unread message

Marek Jenkins

unread,
Nov 2, 2017, 1:13:46 PM11/2/17
to qubes-devel
Dear users and devs,

I really like Qubes and hope I can make it work.

I have severe graphics glitches that happen at random intervals.
If they happen I must reboot the system to fix them temporarily (potential data loss).
Unfortunately, those issues make Qubes 3.2 unusable for me because I need reliability.

Glitch #1: https://imgur.com/a/fkAjW
Looks like a green screen to me. Happens mostly when the system was idle / stand-by and I get back to it.

Glitch #2: https://www.youtube.com/watch?v=sIaOWpFsdTM
Weird screen glitch - also green but with some kind of flickering. Appears randomly.

HCL REPORT:

(Also attached the files !)

---
layout:
  'hcl'
type:
  'desktop'
hvm:
  'yes'
iommu:
  'no'
slat:
  'yes'
tpm:
  'unknown'
brand: |
  Gigabyte Technology Co., Ltd.
model: |
  Z97X-UD5H
bios: |
  F9
cpu: |
  Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller])
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Connection I217-V
  Qualcomm Atheros Killer E220x Gigabit Ethernet Controller (rev 10)
  Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
memory: |
  32550
scsi: |
  Samsung SSD 840  Rev: BB6Q
  DT HyperX 3.0    Rev: PMAP

versions:

- works:
    'FIXME:yes|no|partial'
  qubes: |
    R3.2
  xen: |
    4.6.1
  kernel: |
    4.4.14-11
  remark: |
    FIXME
  credit: |
    FIXAUTHOR
  link: |
    FIXLINK

---


Qubes-HCL-Gigabyte_Technology_Co___Ltd_-Z97X_UD5H-20171101-194315.yml
Qubes-HCL-Gigabyte_Technology_Co___Ltd_-Z97X_UD5H-20171102-170224.cpio.gz

Jean-Philippe Ouellet

unread,
Nov 2, 2017, 2:03:12 PM11/2/17
to Marek Jenkins, qubes-devel
Try updating your kernel in dom0. 4.4.14 is very old and hardware
support improves over time.

Also, posts like this should probably go on qubes-users instead of qubes-devel.

Regards,
Jean-Philippe

Marek Jenkins

unread,
Nov 2, 2017, 3:47:13 PM11/2/17
to qubes-devel
Hi Jean-Philippe,

thanks for your advice.

I have read the docs over here regarding kernel updates: https://www.qubes-os.org/doc/software-update-dom0/

So should I simply run the following terminal commands in dom0 ?

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm

Also, do I need to enable / specify a repo (e.g. unstable, current-testing, etc) or can I also use the command like this:

sudo qubes-dom0-update kernel kernel-qubes-vm

Thank you for your support !

PS: I posted this also in qubes-devel, because I thought this issue is quite difficult for normal users to solve.
Sorry about that, I have also posted my HCL Report in qubes-users and will update there if I find a fix !

Best regards,
Marek

Yuraeitha

unread,
Nov 7, 2017, 12:40:34 PM11/7/17
to qubes-devel


Be very careful when updating untested kernels unless, you should have the ability to recover in case it goes wrong, i.e. switching back updates and switching back to older kernels, should it happen to fail. At the very minimum backup everything before you proceed. Beyond that, yes upgrading the kernel might certainly fix it. It's most likely an issue in the templates kernel or it's associated driver modules, upgrading the kernel would potentially upgrade your drivers and modules. Upgrading the Qubes kernel, also upgrades your template kernels.

The below here is a long shot, but here is something I'd try my self before trying to fix the kernel, if I were in your situation. It's safe, as long as you make the proper precautions and don't experiment on something you don't want to loose.

Also is it mostly after standby, such as suspend or hibernate, or is always after these states? Knowing this will make it easier to verify if the solution works or not.

It sounds to me, without knowing with any certainty, like some kernel modules did not close or start up properly before or after suspend/hibernate.
You can typically avoid the issue by making the modules forced to shutdown before the system goes to standby. The driver or module, whichever is causing this, seems to work, but breaks when the VM is put into sleep mode during Qubes suspend or hibernate. Right?

I've only done with with Wi-Fi and other similar devices, I've never done it with graphics before. Frankly, I don't know if it'll work, but it seems like its worth a shot.
https://www.qubes-os.org/doc/wireless-troubleshooting/
Look for the last headline at the bottom in particular, but also the ones up above regarding how to locate modules.

Granted your issue is not W-Fi issues, however it may be worth trying this, so that graphics are properly shutdown before suspend/hibernate, and properly started up again when returned.

Since I don't know if this works, or even if it'd break anything, I'd recommend you first try this out on a testing AppVM, or testing Template, before you make anything permanent to your current Templates. I.e. make a qvm-clone copy of a template for experimentation, and make a test AppVM.

Then put your system in suspend or hibernate while only your testing AppVM based on your modified testing Template is running.

There are easier methods to test, but at least making full fledged dummy copies that can't cause harm to your data, is more safe if you haven't done this before.
Reply all
Reply to author
Forward
0 new messages