I am getting HDMI with i915. How?

33 replies [Last post]
edgar
Offline
Joined: 03/03/2024

Hello.

I have this system:

https://labs.parabola.nu/attachments/1587

(Intel Corporation Alder Lake-P Integrated Graphics Controller).

I am able to boot Trisquel with video and HDMI (which sounds great), but the same system with linux-libre 6.7 from FSFLA (https://linux-libre.fsfla.org/pub/linux-libre/freesh/pool/main/f/freesh-archive-keyring/freesh-archive-keyring_1.1_all.deb) stops half-way into the init process (after GRUB).

When using the kernel from Trisquel's repository, lspci shows:

Kernel driver in use: i915
Kernel modules: i915

Now, I am wondering what is going on. Why is the kernel from FSFLA not doing the same thing?

Other_Cody
Offline
Joined: 12/20/2023

I think Trisquel uses a deblobbed Ubuntu kernel

https://trisquel.info/en/wiki/how-trisquel-made

Trisquel does not include the vanilla Linux kernel you can find at the project servers, but a cleaned up version of the Ubuntu's version. Both upstream versions include non-free binary-only firmware files, and binary blobs hidden in .c and .h files in the form of huge sequences of numbers. To provide our users with a fully free kernel we use a set of scripts based in the ones from the Linux-libre project by the FSFLA, with some modifications of our own.

even though

https://trisquel.info/en/wiki/documentation

shows

Trisquel GNU/Linux is a distribution of the GNU operating system, with the kernel Linux-libre.

I do not know much more information about your issue yet. Though maybe it is because of Trisquel maybe does not use Linux-libre, but a deblobbed Ubuntu based kernel.

jxself
Offline
Joined: 09/13/2010

Thank you for sharing your experience with transitioning to the linux-libre kernel on your system. The situation you've encountered could stem from a variety of reasons, including differences in kernel configuration, differences or regressions introduced in later kernel versions by upstream, or even module loading behaviors or maybe something else entirely. Unfortunately, without more detailed information such as logs of your boot process it's challenging to provide a precise diagnosis.

andyprough
Offline
Joined: 02/12/2015

Hi jxself, attached is a phone pic of the error messages I got trying to initialize linux-libre-6.7 today on an Alder Lake cpu. As I noted below, linux-libre-6.6 gave the same errors, but linux-libre-6.1 booted up to the desktop successfully and seems to work as intended.

As you can see, it's a bunch of "Duplicate GuC blobs" errors noting that those blobs had been de-blobbed. Just as it hits the 'VT-d active for gfx access" line the system freezes.

Linux-libre-6.7_Init_Error_msgs_Trisquel11_ii.jpg
jxself
Offline
Joined: 09/13/2010

Interesting that it seems to stop at the DRM section, and that 6.1 was the last version to work. Although I wonder if 6.2 works too. There were some DRM changes in 6.3 for i915: https://www.phoronix.com/news/Linux-6.3-DRM Maybe there is a connection? I could try to build some custom kernels to try narrowing it down if anyone with that hardware is interested to try them.

andyprough
Offline
Joined: 02/12/2015

I'll try them if you build some custom kernels. I think this would be important to track down because 6.8 is coming out soon and it is supposed to have some new libre licensed support for the Intel Xe graphics that I want to try.

jxself
Offline
Joined: 09/13/2010

Please read and understand everything first:

This appears that it may have started back in version 6.5. I have compiled two kernel versions incorporating a modification from Alexandre Oliva. These kernels are identified as version 2.0 of 6.7.8-gnu and 6.6.20-gnu. Please test both versions. If you already have 6.7.8-gnu and/or 6.6.20-gnu already installed, even if not running, please remove it first with a command like sudo apt purge linux-image-6.7.8-gnu adjusting the version as needed. The testing kernels can be found at https://jxself.org/i915/. You will also locate the complete corresponding source code there. The files also have a detached GPG signatures that can be used for verification in the usual way.

You probably only need the linux-image .deb file, not the headers.

The testing .deb can be installed with something like sudo dpkg -i /path/to/linux-image-6.7.8-gnu_6.7.8-gnu-2.0_amd64.deb.

Once testing is completed, you can uninstall the testing kernels if desired with that same apt purge command of sudo apt purge linux-image-6.7.8-gnu adjusting the version as needed and also proceed to reinstall the original versions if you want to do that with sudo apt install linux-image-6.7.8-gnu which should then then fetch the version from the Freesh repository.

If you're ever not sure which you're running, one way to tell the difference between them is that with the testing ones, the output of "uname -a" command should display a recent date instead of the customary 1983 easter egg.

andyprough
Offline
Joined: 02/12/2015

Hi jxself, that was great, that removed nearly all of the error messages except the final one where it still gets stuck during init on both the 6.6.20 and 6.7.20 kernels. I've attached pictures for both of them, "i915 ... [drm] VT-d active for gfx access" was the error each time.

I then restarted each one with the 'i915.enable_guc=0' boot parameter and each one was able to boot all the way up and go into the desktop with HDMI working on a second monitor.

But it looks like you are at least halfway there! Thank you and thank Andre for jumping on this so fast, let me know if you have more kernels you want me to try.

linux-image-6.6.20-error-msgii.jpg linux-image-6.7.20-error-msgii.jpg
jxself
Offline
Joined: 09/13/2010

Thank you. Further investigation is necessary. For those affected, please keep using the temporary workaround provided. That should work for version 6.8 too.

The messages that disappeared were were misleading. Alexandre Oliva believed addressing them would solve the issue but unfortunately did not. The final line does not contain an error. It seems the error is completely silent, complicating its identification.

More kernels will come in time, after more work.

jxself
Offline
Joined: 09/13/2010

More information is needed. There is another kernel package in the same place at https://jxself.org/i915. The same thing applies: Please remove the same kernel version if you already have it installed. This doesn't have that one-line change suggested by Alexandre Oliva. It does have additional debugging turned on via DRM_I915_DEBUG_GUC=y. Hopefully that will be more revealing. It would be helpful to capture the entire boot log instead of the last few messages on the display, although having those is probably useful too. Is the machine completely frozen or only the display? Like, can you SSH in and then get the entire log?

edgar
Offline
Joined: 03/03/2024

The system is encrypted, and I don't know if the decryption went ok (because the screen is frozen).

1. Downloaded 6.7.9 from the link above (jxself.org/i915).
2. dpkg -i linux-image-6.7.9-gnu_6.7.9-gnu-3.0_amd64.deb
3. restart and choose that kernel
4. wait a bit to type-in the password to decrypt drive
5. forcefully shut down
6. restart
7. choose 6.7.6 and add i915.enable_guc=0
8. continue with a graphical interface to write this
9. (stumble a bit, and get this done)

journalctl --no-hostname -k -b 0 > current_boot
journalctl --no-hostname -k -b 1 > previous_boot
gpg --encrypt --armor -r name at domain current_boot
gpg --encrypt --armor -r name at domain previous_boot

If you need more, let me know :) . Thanks!

AttachmentSize
current_boot.asc_.gz 18.85 KB
previous_boot.asc_.gz 19.19 KB
jxself
Offline
Joined: 09/13/2010

I need a log from the test version; the ones here are from versions 6.7.6-gnu and Trisquel's own 5.15. (You'll find the kernel version number at the beginning of the file.) It's not necessary to encrypt them. The more eyeballs there are to study this situation, instead of just me, the better.

edgar
Offline
Joined: 03/03/2024

It seems that it's not booting with 6.7.9. I guess that it does not get to the part of asking for the password. As mentioned before, the screen freezes, and there is no way to know how far it gets. I was blindly typing the password. Please, tell me how you want me to boot. I am assuming that the journalctl commands kindly provided [1] do what they are supposed to be doing, but I'm pretty darn sure that I used the kernel from Trisquel more recently than January.

Again: I choose 6.7.9, wait a moment, type the password, shut down and restart with 6.7.6 i915.enable_guc=0.

[1] https://trisquel.info/en/forum/i-am-getting-hdmi-i915-how#comment-175712

jxself
Offline
Joined: 09/13/2010

I'm curious about how andyprough succeeded in obtaining screenshots. It's perplexing that simply enabling some debugging output would make things unbootable.

Adding disk encryption into the mix seems to add an extra layer into this.

I really only have questions:
> I choose 6.7.9, wait a moment, type the password
Are you waiting long enough the the password prompt would have appeared?

> I choose 6.7.9, wait a moment, type the password, shut down
The timing of this is not clear to me. Are you shutting down immediately after entering the password? That might explain why there is no log if the boot process does not have time to finish. Also, my original question seems to be still outstanding: Is the machine completely frozen or only the display? Like, can you SSH in? If you do not have SSH installed this might be a time to do that and try to access the machine remotely.

edgar
Offline
Joined: 03/03/2024

> It's perplexing that simply enabling some debugging output would make things unbootable.

I was not expecting that either.

> Are you waiting long enough the the password prompt would have appeared?

I think so. I can try again, but if journalctl is still showing a kernel from 1.5 months ago, and I already tried several times...

> The timing of this is not clear to me...

I have waited what I think is long enough to type-in the window-manager password

> Is the machine completely frozen or only the display?

It seems from the results of these tests that it does not even get to the decryption part, which may indicate that it is freezing entirely.

> Like, can you SSH in? If you do not have SSH installed this might be a time to do that and try to access the machine remotely.

How would I "SSH in" or access the machine remotely? (this is my only computer)

I have these commands:

ssh          ssh-agent    ssh-copy-id  ssh-keyscan  ssh-add      ssh-argv0    ssh-keygen

and packages

libssh-4     libssh-gcrypt-4    openssh-client
jxself
Offline
Joined: 09/13/2010

If you have a single computer, it inherently means you cannot access it remotely. This leaves the question unresolved until/unless someone can.

edgar
Offline
Joined: 03/03/2024

Ok. For what is worth, I did try again with the same result. I waited like 4 times the amount that it usually takes for the decryption prompt. Also, using the i915.enable_guc=0 works with:

$ uname -r
6.7.9-gnu

(it's what I am using right now). I will check the forum again in some days in case that you need something from me :) . Thanks for linux-libre.

edgar
Offline
Joined: 03/03/2024

Could any of this be tested with a virtual machine (like QEMU)?

edgar
Offline
Joined: 03/03/2024

With this

journalctl --no-hostname --lines=10000

and a lot of cleaning in between (number of partitions, UUID, MAC, IP ranges and what not; I liked this one: dbus-daemon[769]: dbus[769]: Unknown username "whoopsie" in message bus configuration file; not so much how NetworkManager and SystemD change my hostname without letting me know)

the attachment shows the information for the booting process with 6.7.9 and without i915.enable_guc=0

AttachmentSize
previous_boot_filtered.gz 25.5 KB
andyprough
Offline
Joined: 02/12/2015

Here's my 6.7.9 "boot log" if you want to call it that - journalctl does not recognize it as a boot for some reason and so passing the '-k -b 1' option didn't get me anything, so I just ran a 'journalctl --no-hostname --lines=10000' and copied everything that occurred during the 6.7.9 boot attempt.

You appear to be right in your earlier comment @jxself - it may just be that the display is frozen, as it appears there's a lot more activity after the freeze that occurs at the '[drm] VT-d active for gfx access' line (line #877 in the text file).

AttachmentSize
3-9-24 Linux-libre 6.7.9 jounalctl messages ii.txt 183.62 KB
jxself
Offline
Joined: 09/13/2010

Hi Andy - Could you please send me an email? I don't seem to have yours. I'd like to try some more kernel things but a less public way.

andyprough
Offline
Joined: 02/12/2015

OK sent to you.

edgar
Offline
Joined: 03/03/2024

Hi. Has there been any progress on this? Thank you for your update.

jxself
Offline
Joined: 09/13/2010

There is no ETA. Please continue using the workaround, as that should still work. Alexandre Oliva says that all of the necessary information has been gathered. Now he needs time to work out a method to allow the driver to operate without the firmware, as it used to.

andyprough
Offline
Joined: 02/12/2015

>"Now he needs time to work out a method to allow the driver to operate without the firmware, as it used to."

This is sooooo exciting...

edgar
Offline
Joined: 03/03/2024

Hi. Thank you for your answer. Just tell me what information you need (and how to get it), and it's yours :) .

[EDIT]
It may take me some days before I can reply.

eric23
Offline
Joined: 06/30/2017

After booting each kernel, open a terminal use this command and upload the file generated from it. Modify the name of the file for each boot. It should just give a log of the kernel boot and nothing personal.

You do not have to be root but you must use an account that is in the adm group.

# journalctl --no-hostname -k > current_boot.txt

[Edit-- it might give the hostname]

Magic Banana

I am a member!

I am a translator!

Offline
Joined: 07/24/2010

Depending on what is happening, the log may be large and it might be worth compressing it, here with XZ:
$ journalctl --no-hostname -k | xz > current_boot.xz
less can directly read XZ-compressed text files.

eric23
Offline
Joined: 06/30/2017

I apologize; I did not think of that. If the user does two boots in sequence it might be worth to save them using two different files using the -b switch. I think they solved the problem though with the kernel option.

$ journalctl --no-hostname -k -b 0 | xz > current_boot.xz

$ journalctl --no-hostname -k -b 1 | xz > previous_boot.xz

andyprough
Offline
Joined: 02/12/2015

@edgar >"but the same system with linux-libre 6.7 from FSFLA (https://linux-libre.fsfla.org/pub/linux-libre/freesh/pool/main/f/freesh-archive-keyring/freesh-archive-keyring_1.1_all.deb) stops half-way into the init process (after GRUB)"

I get the same inability to complete the init process with linux-libre-6.7 and linux-libre-6.6 from FSFLA on an Alder Lake laptop from NovaCustom, but linux-libre-6.1 boots to the desktop and works with HDMI. Have you tried that version? I also get good performance and HDMI from the Trisquel 5.15 kernel.

Adrian Malacoda

I am a member!

Offline
Joined: 12/26/2010

Hi,

I have a similar system running GNU Guix with Linux-libre 6.7 and I have i915 working. I had to pass in "i915.enable_guc=0" to the kernel command line to make it load. I can't answer why Trisquel works out of the box, though.

andyprough
Offline
Joined: 02/12/2015

That kernel parameter worked for me on the linux-libre-6.7 kernel. HDMI worked. I assume it will also work on linux-libre-6.6.

edgar
Offline
Joined: 03/03/2024

I can confirm that i915.enable_guc=0 does give HDMI. I will report back to the other comments ASAP. Thank you all.

edgar
Offline
Joined: 03/03/2024

[EDIT] (relocate under reply to jxself)

[EDIT 2] (why is this post down-voted? I don't think that it goes against the guidelines)