diff --git a/docs/troubleshooting/intel-igfx-troubleshooting.md b/docs/troubleshooting/intel-igfx-troubleshooting.md index a6fc711..2398db5 100644 --- a/docs/troubleshooting/intel-igfx-troubleshooting.md +++ b/docs/troubleshooting/intel-igfx-troubleshooting.md @@ -1,24 +1,36 @@ -# Intel Integrated Graphics Troubleshooting # +# Intel Integrated Graphics Troubleshooting ## Software Rendering or Video Lags -If you are experiencing this issue, you will see extremely slow graphics updates. -You will be able to watch the screen and elements paint slowly from top to bottom. -You can confirm this is the issue by looking for a line similar to the following in your `/var/log/Xorg.0.log` file: +If you are experiencing this issue, you will see extremely slow graphics +updates. You will be able to watch the screen and elements paint slowly from +top to bottom. You can confirm this is the issue by looking for a line similar +to the following in your `/var/log/Xorg.0.log` file: [ 131.769] (EE) AIGLX: reverting to software rendering -Newer versions of the Linux kernel have renamed the `i915.alpha_support=1` option (which was originally called `i915.preliminary_hw_support=1`) to `i915.force_probe=*`, so if you needed this kernel option in the past you will have to rename it or add it to your configuration files (follow either GRUB2 or EFI, not both): - * GRUB2: `/etc/default/grub`, `GRUB_CMDLINE_LINUX` line and - Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`) +Newer versions of the Linux kernel have renamed the `i915.alpha_support=1` +option (which was originally called `i915.preliminary_hw_support=1`) to +`i915.force_probe=*`, so if you needed this kernel option in the past you will +have to rename it or add it to your configuration files (follow either GRUB2 or +EFI, not both): + + * GRUB2: `/etc/default/grub`, `GRUB_CMDLINE_LINUX` line and + Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`) + * EFI: `/boot/efi/EFI/qubes/xen.cfg`, `kernel=` line(s) -If you are unsure as to which parameter works with your kernel, check whether your kernel log from your latest boot has a message containing "i915: unknown parameter". +If you are unsure as to which parameter works with your kernel, check whether +your kernel log from your latest boot has a message containing "i915: unknown +parameter". -## IOMMU-related issues ## +## IOMMU-related issues -Dom0 Kernels currently included in Qubes have issues related to VT-d (IOMMU) and some versions of the integrated Intel Graphics Chip. -Depending on the specific hardware / software combination the issues are quite wide ranging, from apparently harmless log errors, to VM window refresh issues, to complete screen corruption and crashes rendering the machine unusable with Qubes. +Dom0 Kernels currently included in Qubes have issues related to VT-d (IOMMU) and +some versions of the integrated Intel Graphics Chip. Depending on the specific +hardware / software combination the issues are quite wide ranging, from +apparently harmless log errors, to VM window refresh issues, to complete screen +corruption and crashes rendering the machine unusable with Qubes. Such issues have been reported on at least the following machines: @@ -29,32 +41,34 @@ Such issues have been reported on at least the following machines: * Thinkpad T450s Log errors only on : -* Librem 13v1 +* Librem 13v1 * Librem 15v2 -The installer for Qubes 4.0 final has been updated to disable IOMMU for the integrated intel graphics by default. -However, users of 3.2 may experience issues on install or on kernel upgrades to versions higher than 3.18.x. +The installer for Qubes 4.0 final has been updated to disable IOMMU for the +integrated intel graphics by default. However, users of 3.2 may experience +issues on install or on kernel upgrades to versions higher than 3.18.x. -Disabling IOMMU for the integrated graphics chip is not a security issue, as the device currently lives in dom0 and is not passed to a VM. -This behaviour is planned to be changed as of Qubes 4.1, when passthrough capabilities will be required for the GUI domain [1](#f1). +Disabling IOMMU for the integrated graphics chip is not a security issue, as the +device currently lives in dom0 and is not passed to a VM. This behaviour is +planned to be changed as of Qubes 4.1, when passthrough capabilities will be +[required for the GUI +domain](https://github.com/QubesOS/qubes-issues/issues/2841). - -## Workaround for existing systems with VT-d enabled (grub / legacy mode) ## +### Workaround for existing systems with VT-d enabled (grub / legacy mode) Edit the startup parameters for Xen: 1. Open a terminal in dom0 2. Edit `/etc/default/grub` (e.g. `sudo nano /etc/default/grub`) -3. Add to the line `GRUB_CMDLINE_XEN_DEFAULT` the setting `iommu=no-igfx`, save and quit +3. Add to the line `GRUB_CMDLINE_XEN_DEFAULT` the setting `iommu=no-igfx`, save + and quit 4. Commit the change with`sudo grub2-mkconfig --output /boot/grub2/grub.cfg` -## Workaround for existing systems with VT-d enabled (UEFI) ## +### Workaround for existing systems with VT-d enabled (UEFI) Edit the startup parameters for Xen: 1. Open a terminal in dom0 -2. Edit `/boot/efi/EFI/qubes/xen.cfg` (e.g. `sudo nano /boot/efi/EFI/qubes/xen.cfg`) +2. Edit `/boot/efi/EFI/qubes/xen.cfg` (e.g. `sudo nano + /boot/efi/EFI/qubes/xen.cfg`) 3. Add to the line `options` the setting `iommu=no-igfx`, save and quit - -1 [↩](#a1-1) -