[3.2] Issues with Intel® HD Graphics 620 after update of clean installation
396 views
Skip to first unread message
Vít Šesták
May 4, 2017, 1:16:33 PM5/4/17
to qubes-users
I have installed Qubes OS on a new laptop. Immediately after installing, I decided to run qubes-dom0-update and then also qubes-dom0-update --enablerepo=qubes-dom0-security-testing in order to patch recent Xen vulnerabilities.
Before reboot, Qubes worked smoothly. After reboot, the GUI is quite lazy – mouse movement is slooow, typing lag is high (so I prefer tty over xfce
-terminal for performance reasons) etc. I haven't measured the lag exactly, but it can be about 1s.
So, I have looked at /var/log/Xorg.0.log. There are few errors, the first one seems to be the root cause:
open /dev/dri/card0: No such file or directory
(I have retyped it, because it would be painful to copy&paste it.)
Others are about GPU fallbacks and also “AIGLX: reverting to software rendering”.
So, my reconstruction is that /dev/dri does not exist and thus it to use HW acceleration and thus it is so slow. It makes sense, except that I don't know why /dev/dri is missing. It is reportedly created by kernel, so I assume it is related to i915 module and/or newer kernel version.
When I run lsmod | grep i915, it shows it is loaded. But it is apparently not used, because I can rmmod it. I have tried to reinstall GPU drivers package, but it did not help.
My other idea was to boot Qubes with the old kernel. But I don't know how to do it with UEFI boot. With Legacy boot, there is a Grub menu where I can choose an old kernel, edit kernel cmdline etc. With UEFI boot, I can see nothing like it. Just when I press F12 in early boot stage, I can select what to boot, but I can select just Qubes here, without any options.
What to do now?
Configuration:
* Dell Inspiron 15Z Touch 5578
* Intel i7-7500U CPU
* No dedicated GPU (I hoped to have less issues when I have just the integrated one…)
* UEFI boot.
Regards,
Vít Šesták 'v6ak'
Before reboot, Qubes worked smoothly. After reboot, the GUI is quite lazy – mouse movement is slooow, typing lag is high (so I prefer tty over xfce
-terminal for performance reasons) etc. I haven't measured the lag exactly, but it can be about 1s.
So, I have looked at /var/log/Xorg.0.log. There are few errors, the first one seems to be the root cause:
open /dev/dri/card0: No such file or directory
(I have retyped it, because it would be painful to copy&paste it.)
Others are about GPU fallbacks and also “AIGLX: reverting to software rendering”.
So, my reconstruction is that /dev/dri does not exist and thus it to use HW acceleration and thus it is so slow. It makes sense, except that I don't know why /dev/dri is missing. It is reportedly created by kernel, so I assume it is related to i915 module and/or newer kernel version.
When I run lsmod | grep i915, it shows it is loaded. But it is apparently not used, because I can rmmod it. I have tried to reinstall GPU drivers package, but it did not help.
My other idea was to boot Qubes with the old kernel. But I don't know how to do it with UEFI boot. With Legacy boot, there is a Grub menu where I can choose an old kernel, edit kernel cmdline etc. With UEFI boot, I can see nothing like it. Just when I press F12 in early boot stage, I can select what to boot, but I can select just Qubes here, without any options.
What to do now?
Configuration:
* Dell Inspiron 15Z Touch 5578
* Intel i7-7500U CPU
* No dedicated GPU (I hoped to have less issues when I have just the integrated one…)
* UEFI boot.
Regards,
Vít Šesták 'v6ak'
Reg Tiangha
May 4, 2017, 2:39:21 PM5/4/17
to qubes...@googlegroups.com
On 2017-05-04 11:16 AM, Vít Šesták wrote:
> My other idea was to boot Qubes with the old kernel. But I don't know how to do it with UEFI boot. With Legacy boot, there is a Grub menu where I can choose an old kernel, edit kernel cmdline etc. With UEFI boot, I can see nothing like it. Just when I press F12 in early boot stage, I can select what to boot, but I can select just Qubes here, without any options.
>
> What to do now?
>
> Configuration:
>
> * Dell Inspiron 15Z Touch 5578
> * Intel i7-7500U CPU
> * No dedicated GPU (I hoped to have less issues when I have just the integrated one…)
> * UEFI boot.
>
> Regards,
> Vít Šesták 'v6ak'
>
Wish I could help. I don't know how to alter the UEFI boot menu, but
> My other idea was to boot Qubes with the old kernel. But I don't know how to do it with UEFI boot. With Legacy boot, there is a Grub menu where I can choose an old kernel, edit kernel cmdline etc. With UEFI boot, I can see nothing like it. Just when I press F12 in early boot stage, I can select what to boot, but I can select just Qubes here, without any options.
>
> What to do now?
>
> Configuration:
>
> * Dell Inspiron 15Z Touch 5578
> * Intel i7-7500U CPU
> * No dedicated GPU (I hoped to have less issues when I have just the integrated one…)
> * UEFI boot.
>
> Regards,
> Vít Šesták 'v6ak'
>
maybe try installing the 4.4.62 kernel in current-testing and see if
that fixes your issue? It could be a bug in the 4.4.55 kernel that was
pushed onto your system.
Either that, or rather than trying to change kernels at the bootloader
level, while you're logged in, figure out where the UEFI bootloader
keeps its config file and edit it (back it up first, though) to try and
boot the older kernel.
Vít Šesták
May 4, 2017, 5:28:40 PM5/4/17
to qubes-users
Well, found that. I can edit /boot/efi/EFI/qubes/xen.cfg. It does not look like there is something like Grub menu, though.
* Downgrade to the previous kernel version fixes the issue, but in a quite different way I thought: All symptoms (missing /dev/dri, error messages in Xorg.0.log) except lags remain. So, it seems that the no Qubes kernel supports HD620, but the old one doesn't suck at nonaccelerated video.
* Upgrade to the new kernel does not change anything. Maybe it is slightly less laggy, maybe not.
Staying with older kernel might be a temporary workaround, but only if it does not open any relevant vulnerability (dom0 has a pretty small attack surface, so it might be the case) and if it is likely that this issue will be somehow fixed in 4.0.
By the way, how is hardware support determined? I know that dom0 for Q3.2 is based on Fedora 23, but it has a kernel compiled by ITL. I am unsure which one of those facts have bigger influence on HW compatibility. If the compatibility is derived from F23, it is rather clear that KabyLakes will not be supported well there.
Regards,
Vít Šesták 'v6ak'
Regards,
Vít Šesták 'v6ak'
* Downgrade to the previous kernel version fixes the issue, but in a quite different way I thought: All symptoms (missing /dev/dri, error messages in Xorg.0.log) except lags remain. So, it seems that the no Qubes kernel supports HD620, but the old one doesn't suck at nonaccelerated video.
* Upgrade to the new kernel does not change anything. Maybe it is slightly less laggy, maybe not.
Staying with older kernel might be a temporary workaround, but only if it does not open any relevant vulnerability (dom0 has a pretty small attack surface, so it might be the case) and if it is likely that this issue will be somehow fixed in 4.0.
By the way, how is hardware support determined? I know that dom0 for Q3.2 is based on Fedora 23, but it has a kernel compiled by ITL. I am unsure which one of those facts have bigger influence on HW compatibility. If the compatibility is derived from F23, it is rather clear that KabyLakes will not be supported well there.
Regards,
Vít Šesták 'v6ak'
Regards,
Vít Šesták 'v6ak'
Reg Tiangha
May 4, 2017, 8:28:48 PM5/4/17
to qubes...@googlegroups.com
- Upgrade everything to current-testing. There is an updated
qubes-gui-agent package that might help with window performance issues.
- On the newer kernel, set this option in the boot menu next to all of
the other kernel options: i915.preliminary_hw_support=1
You might be encountering something similar to this:
https://www.phoronix.com/scan.php?page=news_item&px=intel-skl-prelim-support
Vít Šesták
May 5, 2017, 12:17:15 AM5/5/17
to qubes-users
I can try updating everything to current-testing, but I doubt it helps. Specifically, the issue occurs even in lightdm and dom0 windows, so we can't blame GUID which is not even running.
On premilinary HW support: It is actually there by default. I've tried to remove it temporarily, but it did not change anything.
I also don't insist on HW acceleration, as it has proven to be unneeded there. My issue seems to be conjunction of two issues, where solving any of them solves my issue:
* Some generic GPU drivers are used instead of i915.
* Rendering X11 output this way is slow.
I can also try installing X11 from F24 or F25 repositories. I know, this can break it totally, but it might be worth trying. The idea is to try recent (?) kernel from Qubes with recent X11 from newer Fedora.
Regards,
Vít Šesták 'v6ak'
On premilinary HW support: It is actually there by default. I've tried to remove it temporarily, but it did not change anything.
I also don't insist on HW acceleration, as it has proven to be unneeded there. My issue seems to be conjunction of two issues, where solving any of them solves my issue:
* Some generic GPU drivers are used instead of i915.
* Rendering X11 output this way is slow.
I can also try installing X11 from F24 or F25 repositories. I know, this can break it totally, but it might be worth trying. The idea is to try recent (?) kernel from Qubes with recent X11 from newer Fedora.
Regards,
Vít Šesták 'v6ak'
Reg Tiangha
May 5, 2017, 12:35:46 AM5/5/17
to qubes...@googlegroups.com
check, one or two of your templates; maybe it really is qubes-gui-agent
that needs to be fixed as two new xserver dummy drivers were introduced
with the latest rounds of stable updates and the issues only showed up
in templates using X versions older than the one found in FC25. You'll
also get the latest version of Xen that's been patched to fix the latest
XSAs so it's probably worth doing.
But yeah, I can't figure out what else might have changed. Nothing
really changed with respect to the kernel config options between 4.4.15
and 4.4.55, and I'm doubtful the kernel code base changed that much too
so I'm really leaning towards something on the Qubes platform end.
Vít Šesták
May 5, 2017, 1:28:57 AM5/5/17
to qubes-users, r...@reginaldtiangha.com
On Friday, May 5, 2017 at 6:35:46 AM UTC+2, Reg Tiangha wrote:
> Well, maybe just update dom0 to current-testing
I'll try this later today/tomorrow.
> Well, maybe just update dom0 to current-testing
> maybe it really is qubes-gui-agent
> that needs to be fixed
> You'll
> also get the latest version of Xen that's been patched to fix the latest
> XSAs so it's probably worth doing.
> But yeah, I can't figure out what else might have changed. Nothing
> really changed with respect to the kernel config options between 4.4.15
> and 4.4.55, and I'm doubtful the kernel code base changed that much too
> so I'm really leaning towards something on the Qubes platform end.
Some other notes:
* I'll probably also try some troubleshooting mentioned at https://wiki.archlinux.org/index.php/intel_graphics .
* I also have some issues with suspend/restore. Briefly: whenever I restore, I get a blank screen. Not sure how to debug it. Not sure if I should create a separate thread. (It at least does not fit to the original title, but OTOH it might be useful to solve those issues together.)
* I have disabled additional C states in BIOS settings. It sounds like something new and potentially buggy.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
May 6, 2017, 1:16:14 PM5/6/17
to qubes-users
I've investigated it further, found a crazy hack (with some drawbacks) and maybe I am close to working system.
My investigation briefly: Fedora 23 (live distribution, no updates) has the same issues Qubes 3.2 with old kernel (resume issues, i915 not used, cannot control brightness). Fedora 25 (live distribution, no updates) has those issues fixed. I guess, Qubes 4 will work fine out of box on this laptop.
The crazy hack is: take the kernel from Fedora 25 and use it in Qubes. Theoretically, PV support is in Fedora out of box for a long while (see https://wiki.xen.org/wiki/Fedora_Host_Installation ), so it should work.
And it… actually works! It was a bit tricky, but not very hard. (I can write more if someone is interested.) System resumes, i915 is used, screen backlight can be controlled etc. But there are still some theoretical and practical issues:
* Qubes kernel contains some patches. I don't know what patches are important and what patches can be skipped, but for example, patch for skipping partition scan should not be skipped: https://github.com/QubesOS/qubes-linux-kernel/blob/stable-4.4/patches.qubes/0001-block-add-no_part_scan-module-parameter.patch
* Although i915 is used, OpenGL renderer is still llvmpipe, likely due to old mesa package. But I don't care much about this.
* It prints some error messages during the boot.
* VM sys-net sometimes needs reboot. Maybe it misses some Qubes patches… Maybe this could be prevented by module unloading, not sure.
What I want to do next: Compile a recent dom0 kernel with all relevant patches. Maybe I should just take kernel for Qubes 4. (I've found no compiled Qubes 4 kernel in repositories, which is the reason why I want to compile it.) But maybe I'll need some advice:
* The repository I linked contains just a branch for kernel 4.4.* and some olders, but it doesn't contain anything newer. Fedora 25 live contains kernel 4.8.6, updateable to 4.10.something. Is dom0 kernel something that has yet to be done for Qubes 4.0?
* Where to start with build? Should I use the Makefile? Or should I start with Qubes Builder?
Regards,
Vít Šesták 'v6ak'
My investigation briefly: Fedora 23 (live distribution, no updates) has the same issues Qubes 3.2 with old kernel (resume issues, i915 not used, cannot control brightness). Fedora 25 (live distribution, no updates) has those issues fixed. I guess, Qubes 4 will work fine out of box on this laptop.
The crazy hack is: take the kernel from Fedora 25 and use it in Qubes. Theoretically, PV support is in Fedora out of box for a long while (see https://wiki.xen.org/wiki/Fedora_Host_Installation ), so it should work.
And it… actually works! It was a bit tricky, but not very hard. (I can write more if someone is interested.) System resumes, i915 is used, screen backlight can be controlled etc. But there are still some theoretical and practical issues:
* Qubes kernel contains some patches. I don't know what patches are important and what patches can be skipped, but for example, patch for skipping partition scan should not be skipped: https://github.com/QubesOS/qubes-linux-kernel/blob/stable-4.4/patches.qubes/0001-block-add-no_part_scan-module-parameter.patch
* Although i915 is used, OpenGL renderer is still llvmpipe, likely due to old mesa package. But I don't care much about this.
* It prints some error messages during the boot.
* VM sys-net sometimes needs reboot. Maybe it misses some Qubes patches… Maybe this could be prevented by module unloading, not sure.
What I want to do next: Compile a recent dom0 kernel with all relevant patches. Maybe I should just take kernel for Qubes 4. (I've found no compiled Qubes 4 kernel in repositories, which is the reason why I want to compile it.) But maybe I'll need some advice:
* The repository I linked contains just a branch for kernel 4.4.* and some olders, but it doesn't contain anything newer. Fedora 25 live contains kernel 4.8.6, updateable to 4.10.something. Is dom0 kernel something that has yet to be done for Qubes 4.0?
* Where to start with build? Should I use the Makefile? Or should I start with Qubes Builder?
Regards,
Vít Šesták 'v6ak'
Vít Šesták
May 6, 2017, 5:38:41 PM5/6/17
to qubes-users
OK, I've found how to compile it https://groups.google.com/forum/#!topic/qubes-users/yBeUJPwKwHM/discussion .
Now, I am running on a compiled kernel with the Qubes-related patches. It works mostly the same (supend/resume OK, graphic output OK and using i915, brightness works, OpenGL via llvmpipe, sys-net issues I mentioned earlier). Well, qubes-dom0-update works better now, because it does not want to remove the kernel I am currently using…
The sys-net issues after resume are easy to resolve: rmmod and then modprobe iwlvmv+iwlwifi. This seems to be minimal set of modules you need to refresh via rmmod+modprobe.
So, it works now. With Qubes 4, it will probably work more out-of-box…
Regards,
Vít Šesták 'v6ak'
Now, I am running on a compiled kernel with the Qubes-related patches. It works mostly the same (supend/resume OK, graphic output OK and using i915, brightness works, OpenGL via llvmpipe, sys-net issues I mentioned earlier). Well, qubes-dom0-update works better now, because it does not want to remove the kernel I am currently using…
The sys-net issues after resume are easy to resolve: rmmod and then modprobe iwlvmv+iwlwifi. This seems to be minimal set of modules you need to refresh via rmmod+modprobe.
So, it works now. With Qubes 4, it will probably work more out-of-box…
Regards,
Vít Šesták 'v6ak'
Chris Laprise
May 6, 2017, 10:36:01 PM5/6/17
to Vít Šesták, qubes-users
On 05/06/2017 01:16 PM, Vít Šesták wrote:
> I've investigated it further, found a crazy hack (with some drawbacks) and maybe I am close to working system.
>
> My investigation briefly: Fedora 23 (live distribution, no updates) has the same issues Qubes 3.2 with old kernel (resume issues, i915 not used, cannot control brightness). Fedora 25 (live distribution, no updates) has those issues fixed. I guess, Qubes 4 will work fine out of box on this laptop.
>
> The crazy hack is: take the kernel from Fedora 25 and use it in Qubes. Theoretically, PV support is in Fedora out of box for a long while (see https://wiki.xen.org/wiki/Fedora_Host_Installation ), so it should work.
Wish I noticed this earlier... There is a newer kernel v4.8.12 in
> I've investigated it further, found a crazy hack (with some drawbacks) and maybe I am close to working system.
>
> My investigation briefly: Fedora 23 (live distribution, no updates) has the same issues Qubes 3.2 with old kernel (resume issues, i915 not used, cannot control brightness). Fedora 25 (live distribution, no updates) has those issues fixed. I guess, Qubes 4 will work fine out of box on this laptop.
>
> The crazy hack is: take the kernel from Fedora 25 and use it in Qubes. Theoretically, PV support is in Fedora out of box for a long while (see https://wiki.xen.org/wiki/Fedora_Host_Installation ), so it should work.
"unstable" repo and it works very well.
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Vít Šesták
May 7, 2017, 3:33:54 AM5/7/17
to qubes-users
OK, thanks. It seems I have compiled it with slightly newer set of patches (4.8.14-12 vs. 4.8.14-9). I haven't noticed the unstable repo (https://yum.qubes-os.org/r3.2/unstable/dom0/fc23/rpm/ )…
I don't see it in official repo. Is it compiled from slightly older version of https://github.com/marmarek/qubes-linux-kernel/tree/devel-4.8?files=1 ?
I don't see it in official repo. Is it compiled from slightly older version of https://github.com/marmarek/qubes-linux-kernel/tree/devel-4.8?files=1 ?
mirek.woj...@gmail.com
Sep 16, 2017, 6:32:53 AM9/16/17
to qubes-users
I have removed the kernel option: nomodeset
Now, /boot/efi/EFI/qubes/xen.cfg looks like this:
-----
[global]
default=4.9.35-19.pvops.qubes.x86_64
[4.9.35-19.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M
kernel=vmlinuz-4.9.35-19.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-00 rd.luks.uuid=luks-06c35d45-4a71-4b89-973b-ef8f8aebc2a8 rd.lvm.lv=qubes_dom0/00 rd.lvm.lv=qubes_dom0/swap rhgb quiet
ramdisk=initramfs-4.9.35-19.pvops.qubes.x86_64.img
[4.9.35-19.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M
kernel=vmlinuz-4.9.35-19.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-00 rd.luks.uuid=luks-06c35d45-4a71-4b89-973b-ef8f8aebc2a8 rd.lvm.lv=qubes_dom0/00 rd.lvm.lv=qubes_dom0/swap rhgb quiet
ramdisk=initramfs-4.9.35-19.pvops.qubes.x86_64.img
-----
Regards
Reply all
Reply to author
Forward
0 new messages