i5 540m Intel HD integrated graphics corruption with any Qubes 4.x series kernel

[vincentadultman]

Qubes OS version (e.g., R3.2):

R3.2

Expected behavior:

System boots with usable graphics as with kernel 3.18.17-8

Actual behavior:

"Q" boot splash screen is corrupted from its initial load, while disk password can be entered, machine then reboots later in the boot process (when X starts?)

Steps to reproduce the behavior:

Attempt to boot any and all 4.x series qubes dom0 kernels

General notes:

Could an option have got deselected in 4.x series kernel configs necessary for this older hardware? https://ark.intel.com/products/43544/Intel-Core-i5-540M-Processor-3M-Cache-2_53-GHz

The i915.modeset=0 kernel command line option to disable kernel modesetting coupled with systemd.unit=multi-user.target allows the kernel to boot with basic graphics, and me to login to the system in basic text mode i.e. a non-gui Qubes. Does this imply that the newer kernels are not detecting the screen capabilities correctly?

I'm at a loss as to what to try next, as modern distros I believe rely on kernel modesetting for X to work. The various components of FC23 and Xen obviously still interact correctly with the older kernel on this hardware, so it seems somehow less likely the problem is Qubes/Xen specific, unless the problem interaction is specific to kernel 4.x

I read that distros more recently than FC23 are changing the modesetting driver for xorg http://hansdegoede.livejournal.com/16976.html however as the graphics corruption is early in boot, I'm struggling to see how this would apply.

---

Related issues:

A sensible point seems to be to ascertain whether it is all i5 540m intel HD integrated graphics that have this problem with 4.x kernels, or just those on my hardware HP Elitebook 2540p. Unfortunately I am not in a position to obtain further hardware for testing. Do any developers retain anything ancient enough in their junk piles?

Given that I can boot into the 4.x series kernel in text only mode, are there any relevant log lines or actions to try that may further illuminate the issue?

[rtiangha]

I'm curious: Did the 4.1 kernel ever work while that was available?

[rtiangha]

I'm curious: Did the 4.1 kernel ever work while that was available?

[vincentadultman]

No, I don't believe so. If memory serves I began having the issue with Qubes 3.1 (I think that's when 4.x kernels began for Qubes?) and was somewhat surprised to find the upgrade to 3.2 didn't break things completely or remove the 3.x series kernel (as I assumed the kernel and non-kernel components would have diverged too much by that point). It has crossed my mind that perhaps a module isn't blacklisted (intel modesetting drivers?) that should be for the newer kernels to work, but I don't know the ins and outs of how graphics works from the kernel up well enough to check. There is no rpmnew file in /usr/lib/modprobe.d/ for dist-blacklist.conf

Obviously the primary concern here for me given the isolated dom0 and lack of updates for the 3.x kernel is the xsa kernel patches I'm not getting, although I'd imagine there's also a secondary issue of people attempting new installs on such hardware (which runs Qubes completely adequately for "desktop" use), which would probably also be an issue for me should I ever need to reinstall. This is exactly the sort of laptop that is being retired from large corporate fleets and distributed to friends and colleagues for "projects of interest" such as trying Qubes. I'll stop proselytizing about my problem now though!

[vincentadultman]

No, I don't believe so. If memory serves I began having the issue with Qubes 3.1 (I think that's when 4.x kernels began for Qubes?) and was somewhat surprised to find the upgrade to 3.2 didn't break things completely or remove the 3.x series kernel (as I assumed the kernel and non-kernel components would have diverged too much by that point). It has crossed my mind that perhaps a module isn't blacklisted (intel modesetting drivers?) that should be for the newer kernels to work, but I don't know the ins and outs of how graphics works from the kernel up well enough to check. There is no rpmnew file in /usr/lib/modprobe.d/ for dist-blacklist.conf

Obviously the primary concern here for me given the isolated dom0 and lack of updates for the 3.x kernel is the xsa kernel patches I'm not getting, although I'd imagine there's also a secondary issue of people attempting new installs on such hardware (which runs Qubes completely adequately for "desktop" use), which would probably also be an issue for me should I ever need to reinstall. This is exactly the sort of laptop that is being retired from large corporate fleets and distributed to friends and colleagues for "projects of interest" such as trying Qubes. I'll stop proselytizing about my problem now though!

[vincentadultman]

Typical. I give in and submit a bug and find what may be a solution couple of days later.

TLDR= add to xen commandline iommu=no-igfx

It looks like there is a xen quirk that deals with the issue, my google fu failed in this instance simply because I didn't know what it was I was looking for and "screen corruption" is so generic, coupled with the fact intel graphics iommu was fine with the earlier kernel.

https://bugs.freedesktop.org/show_bug.cgi?id=90037
https://lists.gt.net/xen/devel/393647

@marmarek are there any security implications to this? I'm guessing it's going to cause problems when / if the move to a graphics vm occurs? I'm thinking we can probably go whistle for this being fixed in the intel driver without effort ourselves but perhaps that's cynical of me. If there are no negative security implications, how do I make this permanent?

@andrewdavidwong is this an issue for the documentation? my igp is ironlake(?) as discussed in the xen thread, but the cpu is arrandale and the igp family isn't named in the ark page in a way that let me find a quick solution. Happy to write something and submit if you can tell me where it should sit.

Thanks

[vincentadultman]

Typical. I give in and submit a bug and find what may be a solution couple of days later.

TLDR= add to xen commandline iommu=no-igfx

It looks like there is a xen quirk that deals with the issue, my google fu failed in this instance simply because I didn't know what it was I was looking for and "screen corruption" is so generic, coupled with the fact intel graphics iommu was fine with the earlier kernel.

https://bugs.freedesktop.org/show_bug.cgi?id=90037
https://lists.gt.net/xen/devel/393647

@marmarek are there any security implications to this? I'm guessing it's going to cause problems when / if the move to a graphics vm occurs? I'm thinking we can probably go whistle for this being fixed in the intel driver without effort ourselves but perhaps that's cynical of me. If there are no negative security implications, how do I make this permanent?

@andrewdavidwong is this an issue for the documentation? my igp is ironlake(?) as discussed in the xen thread, but the cpu is arrandale and the igp family isn't named in the ark page in a way that let me find a quick solution. Happy to write something and submit if you can tell me where it should sit.

Thanks

[marmarek]

@marmarek are there any security implications to this? I'm guessing it's going to cause problems when / if the move to a graphics vm occurs? I'm thinking we can probably go whistle for this being fixed in the intel driver without effort ourselves but perhaps that's cynical of me. If there are no negative security implications, how do I make this permanent?

Yes, your understanding is correct. See also here: #2836 (comment) As for making it permanent - use /boot/efi/EFI/qubes/xen.cfg or /etc/default/grub (depending on using UEFI or legacy).

[marmarek]

@marmarek are there any security implications to this? I'm guessing it's going to cause problems when / if the move to a graphics vm occurs? I'm thinking we can probably go whistle for this being fixed in the intel driver without effort ourselves but perhaps that's cynical of me. If there are no negative security implications, how do I make this permanent?

Yes, your understanding is correct. See also here: #2836 (comment) As for making it permanent - use /boot/efi/EFI/qubes/xen.cfg or /etc/default/grub (depending on using UEFI or legacy).

[andrewdavidwong]

@andrewdavidwong is this an issue for the documentation? my igp is ironlake(?) as discussed in the xen thread, but the cpu is arrandale and the igp family isn't named in the ark page in a way that let me find a quick solution. Happy to write something and submit if you can tell me where it should sit.

We would be grateful for documentation on this, perhaps as a page in the Troubleshooting section. Please see here for information about how to contribute:
https://www.qubes-os.org/doc/doc-guidelines/

[andrewdavidwong]

@andrewdavidwong is this an issue for the documentation? my igp is ironlake(?) as discussed in the xen thread, but the cpu is arrandale and the igp family isn't named in the ark page in a way that let me find a quick solution. Happy to write something and submit if you can tell me where it should sit.

We would be grateful for documentation on this, perhaps as a page in the Troubleshooting section. Please see here for information about how to contribute:
https://www.qubes-os.org/doc/doc-guidelines/

[vincentadultman]

Thanks @andrewdavidwong I've submitted a draft page
QubesOS/qubes-doc#460

Per the notes can someone please check the UEFI section as I'm unsure if that needs "committing" or not as a grub change would.

I've not put in a section for now about new installs of 3.2. Are we also going to change the installer for 3.2? Should users disable vt-d in bios entirely when installing, reneabling after (I like this somehow less but I think it exists elsewhere in docs). Should they edit installer boot command? etc

[vincentadultman]

Thanks @andrewdavidwong I've submitted a draft page
QubesOS/qubes-doc#460

Per the notes can someone please check the UEFI section as I'm unsure if that needs "committing" or not as a grub change would.

I've not put in a section for now about new installs of 3.2. Are we also going to change the installer for 3.2? Should users disable vt-d in bios entirely when installing, reneabling after (I like this somehow less but I think it exists elsewhere in docs). Should they edit installer boot command? etc