I am getting HDMI with i915. How?
- Login o registrati per inviare commenti
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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!
| Allegato | Dimensione |
|---|---|
| current_boot.asc_.gz | 18.85 KB |
| previous_boot.asc_.gz | 19.19 KB |
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.
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
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.
> 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
If you have a single computer, it inherently means you cannot access it remotely. This leaves the question unresolved until/unless someone can.
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.
Could any of this be tested with a virtual machine (like QEMU)?
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
| Allegato | Dimensione |
|---|---|
| previous_boot_filtered.gz | 25.5 KB |
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).
| Allegato | Dimensione |
|---|---|
| 3-9-24 Linux-libre 6.7.9 jounalctl messages ii.txt | 183.62 KB |
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.
OK sent to you.
Hi. Has there been any progress on this? Thank you for your update.
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.
>"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...
Hi there. Could you please try out 6.9-rc5 and share your feedback?
I'm getting an error:
$ sudo dpkg -i ./linux-image-6.9.0-rc5-gnu_6.9-rc5-gnu-1.0_amd64.deb
Selecting previously unselected package linux-image-6.9.0-rc5-gnu.
(Reading database ... 315797 files and directories currently installed.)
Preparing to unpack .../linux-image-6.9.0-rc5-gnu_6.9-rc5-gnu-1.0_amd64.deb ...
Unpacking linux-image-6.9.0-rc5-gnu (6.9-rc5-gnu-1.0) ...
Setting up linux-image-6.9.0-rc5-gnu (6.9-rc5-gnu-1.0) ...
Usage: /usr/bin/linux-update-symlinks {install|upgrade|remove} VERSION IMAGE-PATH
This command is intended to be called from the postinst and postrm
maintainer scripts of Linux kernel packages. The postinst script must
pass the first argument 'install' or 'upgrade' depending on whether a
fresh installation or an upgrade has taken place.
The VERSION argument must be the kernel version string as shown by
'uname -r' and used in filenames.
The IMAGE-PATH argument must be the absolute filename of the kernel
image.
dpkg: error processing package linux-image-6.9.0-rc5-gnu (--install):
installed linux-image-6.9.0-rc5-gnu package post-installation script subprocess returned error exit status 2
Errors were encountered while processing:
linux-image-6.9.0-rc5-gnu
Fixed dpkg with
sudo mv /var/lib/dpkg/info/linux-image-6.9* /tmp/
sudo dpkg --remove --force-remove-reinstreq linux-image-6.9.0-rc5-gnu
cd /boot/
sudo rm System.map-6.9.0-rc5-gnu vmlinuz-6.9.0-rc5-gnu config-6.9.0-rc5-gnu
I don't think I can install this package without some further hints.
Thank you. I have made a kernel package revision 2.0 to address that.
Also, Alexandre Oliva explains what's going on:
http://www.fsfla.org/pipermail/linux-libre/2024-April/003539.html
OK, that one worked, booted into the Mate desktop, and worked very impressively too.
Big difference with this new kernel. Here's my glxinfo data while running the 5.15 kernel (notice that llvmpipe is doing the rendering), and I noticed that with the 5.15 kernel the CPU runs at about 3X higher amount when playing a video than it runs with the new 6.9 kernel:
$ glxinfo | grep render
direct rendering: Yes
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
GLX_MESA_query_renderer, GLX_OML_swap_method, GLX_SGIS_multisample,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_copy_image,
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image,
GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB_write_control,
GL_NV_conditional_render, GL_NV_draw_buffers, GL_NV_fbo_color_attachments,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
Now, look at the glxinfo for the 6.9 kernel - it's showing the Intel graphics doing the rendering, and as I said it's running with 3X less cpu work when playing a video:
$ glxinfo | grep render
direct rendering: Yes
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa Intel(R) Graphics (ADL GT2)
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_IBM_multimode_draw_arrays, GL_INTEL_blackhole_render,
GL_NV_compute_shader_derivatives, GL_NV_conditional_render,
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_INGR_blend_func_separate, GL_INTEL_blackhole_render,
GL_NV_conditional_render, GL_NV_copy_image, GL_NV_depth_clamp,
GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB_write_control,
GL_EXT_unpack_subimage, GL_INTEL_blackhole_render,
GL_NV_conditional_render, GL_NV_draw_buffers, GL_NV_fbo_color_attachments,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
This is just amazing!!!
I'll email you a boot log.
And to be sure, you're booting without the workaround, i915.enable_guc=0?
Correct, "i915.enable_guc=0" was not used.
I just emailed you a new boot log with a different parameter disabled, "pci=noaer" which was being used to quiet some correctible ath9k errors from being logged. Booting with and without "pci=noaer" gave the same results of glxinfo reporting an OpenGL renderer string of "Mesa Intel(R) Graphics (ADL GT2)" and with 3X reduced cpu usage when playing videos compared to the 5.15 kernel.
Just to keep things current, it's been updated to 6.9-rc6.
>"Just to keep things current, it's been updated to 6.9-rc6."
That installed fine, seems to be working well like the 6.9-rc5.
Now it's updated to 6.9-rc7.
6.9-rc7 installs and works the same as far as I can see.
$ uname -a
Linux NS51PU 6.9.0-rc7-gnu #1.0 SMP PREEMPT_DYNAMIC Mon May 6 16:04:06 PDT 2024 x86_64 x86_64 x86_64 GNU/Linux
$ glxinfo | grep render
direct rendering: Yes
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa Intel(R) Graphics (ADL GT2)
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_IBM_multimode_draw_arrays, GL_INTEL_blackhole_render,
GL_NV_compute_shader_derivatives, GL_NV_conditional_render,
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_INGR_blend_func_separate, GL_INTEL_blackhole_render,
GL_NV_conditional_render, GL_NV_copy_image, GL_NV_depth_clamp,
GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB_write_control,
GL_EXT_unpack_subimage, GL_INTEL_blackhole_render,
GL_NV_conditional_render, GL_NV_draw_buffers, GL_NV_fbo_color_attachments,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
Thanks. Now we can begin to take bets on whether this Sunday will be the release of 6.9 or if it'll instead be 6.9-rc8.
As long as Torvalds doesn't revert whatever is now working better with those Intel Xe graphics, I'll be happy either way.
The GNU Linux-libre 6.9-gnu version is now available. The Freesh APT repository has been updated and will be accessible across all mirrors within the next 24 hours. Consequently, I have removed the i915 testing area. Thank you all for your assistance. We now return to your regularly scheduled programming. :)
I am a translator!
Great, thanks!
Would it be possible to also have a patch usable with linux libre versions in parabola repositories? (either linux-libre or linux-libre-lts)? I am asking because it seems there is no resource now to make new kernel packages for parabola and none of the kernels currently in parabola repository is usable with i915 (I tried with the disable option at boot, it boots but after opening a session, everything freezes as soon as a new window is opened (black screen, not even possible to switch to a terminal).
I don't have direct control over the packaging for Parabola, but I expect that they will update their repositories with the Linux-libre 6.9-gnu at some point. It's best to keep an eye on Parabola's package updates or reach out to their maintainer team for specific timelines and patch availability.
I am a translator!
I told Bill Auger I would wait but he said the maintainer had been skipping most versions in recent years and advised me to ask for a patch from linux libre, but I am not sure what to ask for exactly. Anyway, I have another computer working ok with parabola.
If the Parabola folk need to update the deblobbing script, diffing these two shows the changes made for 6.6.
https://linux-libre.fsfla.org/pub/linux-libre/releases/6.6.30-gnu/deblob-6.6
https://linux-libre.fsfla.org/pub/linux-libre/releases/6.6.31-gnu/deblob-6.6
I am a translator!
Many thanks ! I don't have much time to look at this or contact people now, but I will look at this more next week.
Thanks. I built and packaged the kernel to use it with Parabola (thanks also for compiling it yourself). I can report the same as andyprough (no i915.enable_guc=0):
direct rendering: Yes
GLX_MESA_copy_sub_buffer, GLX_MESA_gl_interop, GLX_MESA_query_renderer,
GLX_MESA_copy_sub_buffer, GLX_MESA_gl_interop, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa Intel(R) Graphics (ADL GT2)
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_IBM_multimode_draw_arrays, GL_INTEL_blackhole_render,
GL_NV_conditional_render, GL_NV_copy_image, GL_NV_depth_clamp,
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_INGR_blend_func_separate, GL_INTEL_blackhole_render,
GL_NV_compute_shader_derivatives, GL_NV_conditional_render,
GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB_write_control,
GL_EXT_unpack_subimage, GL_INTEL_blackhole_render,
GL_NV_conditional_render, GL_NV_draw_buffers, GL_NV_fbo_color_attachments,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
# BEGIN EDIT
vainfo
https://wiki.archlinux.org/title/Hardware_video_acceleration
Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.21 (libva 2.21.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.1.3 ()
vainfo: Supported profile and entrypoints
VAProfileNone : VAEntrypointVideoProc
VAProfileNone : VAEntrypointStats
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSliceLP
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSliceLP
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile1 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileVP9Profile3 : VAEntrypointVLD
VAProfileHEVCMain12 : VAEntrypointVLD
VAProfileHEVCMain422_10 : VAEntrypointVLD
VAProfileHEVCMain422_12 : VAEntrypointVLD
VAProfileHEVCMain444 : VAEntrypointVLD
VAProfileHEVCMain444 : VAEntrypointEncSliceLP
VAProfileHEVCMain444_10 : VAEntrypointVLD
VAProfileHEVCMain444_10 : VAEntrypointEncSliceLP
VAProfileHEVCMain444_12 : VAEntrypointVLD
VAProfileHEVCSccMain : VAEntrypointVLD
VAProfileHEVCSccMain : VAEntrypointEncSliceLP
VAProfileHEVCSccMain10 : VAEntrypointVLD
VAProfileHEVCSccMain10 : VAEntrypointEncSliceLP
VAProfileHEVCSccMain444 : VAEntrypointVLD
VAProfileHEVCSccMain444 : VAEntrypointEncSliceLP
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileHEVCSccMain444_10 : VAEntrypointVLD
VAProfileHEVCSccMain444_10 : VAEntrypointEncSliceLP
# END EDIT
THANK YOU VERY MUCH !!! (to you and all the free software community). I hope that it gets soon to the official repo over here :) .
Thanks! I will do in one or 2 weeks.
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.
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]
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.
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
@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.
I am a member!
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.
- Login o registrati per inviare commenti