Switched from Nvidia to Intel integrated with some errors

[mi_unixbird]

What I want to know is what causes these errors in the Xorg log and whether it's normal because picom right now is so slow that I have to turn it off so I'd also like an answer to this.

Code: Select all

[    12.817] (WW) Warning, couldn't open module intel
[    12.817] (EE) Failed to load module "intel" (module does not exist, 0)
[    12.817] (II) LoadModule: "modesetting"
[    12.817] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[    12.819] (II) Module modesetting: vendor="X.Org Foundation"
[    12.819] 	compiled for 1.21.1.18, module version = 1.21.1
[    12.819] 	Module class: X.Org Video Driver
[    12.819] 	ABI class: X.Org Video Driver, version 25.2
[    12.819] (II) LoadModule: "fbdev"
[    12.819] (WW) Warning, couldn't open module fbdev
[    12.819] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    12.819] (II) LoadModule: "vesa"
[    12.819] (WW) Warning, couldn't open module vesa
[    12.819] (EE) Failed to load module "vesa" (module does not exist, 0)
[    12.819] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

I tried switching picom between xrendr and glx backends which makes no difference. Also glxinfo contains “accelerated: no” which seems to imply hardware acceleration isn't working at all for graphics but I'm not sure how to fix it.

Also, by “switched” I mean pretty much transplanted my root filesystem onto another motherboard and processor.

Full Xorg log is here: https://pastebin.com/qcLZHKkZ

“glxinfo -B” output: https://pastebin.com/p61zCZTa

Full linux configuration: https://pastebin.com/9E6VmTAv

Also, I have a raptor lake “Intel(R) Core(TM) i7-14700K”.

[NeddySeagoon]

mi_unixbird,
Your log says

Code: Select all

[    12.817] (==) Matched intel as autoconfigured driver 0
[    12.817] (==) Matched modesetting as autoconfigured driver 1
[    12.817] (==) Matched fbdev as autoconfigured driver 2
[    12.817] (==) Matched vesa as autoconfigured driver 3

That's a list of the preferred drivers for your Intel GPU.

The errors say that some of them cannot be loaded.
Don't worry about vesa and fbdev. You don't want them. They are both slower than what you have now.
Fix your VIDEO_CARDS. It needs to include intel, then rebuild xorg-drivers and mesa.
That should get you some acceleration.
Be aware that the Intel driver is on life support. modesetting and mesa is preferred for most chip sets today.

--edit--

you may want to make i915 a loadable module in your kernel.
I suspect it tries to load fimware and can't as root is not mounted.
dmesg will have someting to say about it.

[mi_unixbird]

mi_unixbird,
Your log says

Code: Select all

[    12.817] (==) Matched intel as autoconfigured driver 0
[    12.817] (==) Matched modesetting as autoconfigured driver 1
[    12.817] (==) Matched fbdev as autoconfigured driver 2
[    12.817] (==) Matched vesa as autoconfigured driver 3

That's a list of the preferred drivers for your Intel GPU.

The errors say that some of them cannot be loaded.
Don't worry about vesa and fbdev. You don't want them. They are both slower than what you have now.
Fix your VIDEO_CARDS. It needs to include intel, then rebuild xorg-drivers and mesa.
That should get you some acceleration.
Be aware that the Intel driver is on life support. modesetting and mesa is preferred for most chip sets today.

--edit--

you may want to make i915 a loadable module in your kernel.
I suspect it tries to load fimware and can't as root is not mounted.
dmesg will have someting to say about it.

VIDEO_CARDS already includes intel and that's the only thing in it, however, this dmsg output suggests that the issue is far earlier in boot than that:

Code: Select all

$ dmesg | grep i915
[    0.233763] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    0.233764] i915 0000:00:02.0: vgaarb: deactivate vga console
[    0.233784] i915 0000:00:02.0: [drm] Transparent Hugepage support is recommended for optimal performance on this platform!
[    0.234333] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    0.234350] i915 0000:00:02.0: Direct firmware load for i915/adls_dmc_ver2_01.bin failed with error -2
[    0.234351] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/adls_dmc_ver2_01.bin. Disabling runtime power management.
[    0.234352] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    0.234789] i915 0000:00:02.0: [drm] *ERROR* GT0: GuC firmware i915/tgl_guc_70.bin: fetch failed -2
[    0.234792] i915 0000:00:02.0: [drm] GT0: GuC firmware(s) can be downloaded from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    0.235294] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 0.0.0
[    0.235366] i915 0000:00:02.0: [drm] *ERROR* GT0: GuC initialization failed -2
[    0.235367] i915 0000:00:02.0: [drm] *ERROR* GT0: Enabling uc failed (-5)
[    0.235368] i915 0000:00:02.0: [drm] *ERROR* GT0: Failed to initialize GPU, declaring it wedged!
[    0.235752] i915 0000:00:02.0: [drm:add_taint_for_CI] CI tainted:0x9 by intel_gt_init+0xa9/0x330
[    0.284887] [drm] Initialized i915 1.6.0 20230929 for 0000:00:02.0 on minor 0
[    0.285355] i915 display info: display version: 12
[    0.285355] i915 display info: cursor_needs_physical: no
[    0.285356] i915 display info: has_cdclk_crawl: no
[    0.285356] i915 display info: has_cdclk_squash: no
[    0.285356] i915 display info: has_ddi: yes
[    0.285357] i915 display info: has_dp_mst: yes
[    0.285357] i915 display info: has_dsb: yes
[    0.285357] i915 display info: has_fpga_dbg: yes
[    0.285357] i915 display info: has_gmch: no
[    0.285358] i915 display info: has_hotplug: yes
[    0.285358] i915 display info: has_hti: yes
[    0.285358] i915 display info: has_ipc: yes
[    0.285358] i915 display info: has_overlay: no
[    0.285359] i915 display info: has_psr: yes
[    0.285359] i915 display info: has_psr_hw_tracking: no
[    0.285359] i915 display info: overlay_needs_physical: no
[    0.285360] i915 display info: supports_tv: no
[    0.285360] i915 display info: has_hdcp: yes
[    0.285360] i915 display info: has_dmc: yes
[    0.285360] i915 display info: has_dsc: yes
[    0.316098] fbcon: i915drmfb (fb0) is primary device
[    0.386267] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

I of course have the linux-firmware package installed though I haven't remerged it after switching to the new machine, maybe that will fix it.

[NeddySeagoon]

mi_unixbird,

You have the i915 kernel driver built into the kernel and the required firmware on the root filesystem.
That fails by design.

All the bits of kernel drivers must be available when the code initalises.
Either i915 must be a module or the firmware must be included in the kernel binary.
It's easier to make i915 a module and more future proof for when firmware changes.
However, both ways work. With the other combinations, the bits miss one another at initalisation, so firmware loading fails.

[mi_unixbird]

Okay, I fixed it now by building the i915/tgl_guc_70.bin microcode directly into Linux but surely this shouldn't be necsesary? The issue was that this thing didn't load but surely it should not be required to build it into the kernel for that? Is there some more elegant way to force it to load without having to resolve to that?

[NeddySeagoon]

mi_unixbird,

It looks like we posted at the same time. Read my post above.
I think it explains it.

[pietinger]

Code: Select all

[    0.234350] i915 0000:00:02.0: Direct firmware load for i915/adls_dmc_ver2_01.bin failed with error -2

Okay, I fixed it now by building the i915/tgl_guc_70.bin microcode directly into Linux but surely this shouldn't be necsesary? [...]

Yes, it is necessary. See more here: https://wiki.gentoo.org/wiki/User:Pieti ... s_Firmware

BTW: ->

Code: Select all

[    0.233784] i915 0000:00:02.0: [drm] Transparent Hugepage support is recommended for optimal performance on this platform!

I suggest to enable it ->
https://wiki.gentoo.org/wiki/User:Pieti ... nt_options

[mi_unixbird]

mi_unixbird,

It looks like we posted at the same time. Read my post above.
I think it explains it.

Indeed, I replied without seeing it and I also read the other post and feel I understand the issue now. It feels kind of strange that Linux cannot just wait initializing it after it has access to the root filesystem though even for built in things.

Code: Select all

[    0.234350] i915 0000:00:02.0: Direct firmware load for i915/adls_dmc_ver2_01.bin failed with error -2

Okay, I fixed it now by building the i915/tgl_guc_70.bin microcode directly into Linux but surely this shouldn't be necsesary? [...]

Yes, it is necessary. See more here: https://wiki.gentoo.org/wiki/User:Pieti ... s_Firmware

BTW: ->

Code: Select all

[    0.233784] i915 0000:00:02.0: [drm] Transparent Hugepage support is recommended for optimal performance on this platform!

I suggest to enable it ->
https://wiki.gentoo.org/wiki/User:Pieti ... nt_options

Any reason madvise is better than always?

[dmpogo]

[quote="mi_unixbird"]
Indeed, I replied without seeing it and I also read the other post and feel I understand the issue now. It feels kind of strange that Linux cannot just wait initializing it after it has access to the root filesystem though even for built in things.

/quote]

Well, Linux solution is to have hardware kernel drivers that need firmware to be built as modules that are loaded later when / is available.

[Hu]

The kernel code is simpler if it can assume that firmware is available when it is needed. If the driver is built-in, it initializes early, and needs built-in firmware because that is the only source of firmware during early initialization. To support the behavior you want would require that the kernel somehow detect later in the boot process that it has gained access to an additional source of firmware, and retry the device initialization at that point.

[mi_unixbird]

Indeed, I replied without seeing it and I also read the other post and feel I understand the issue now. It feels kind of strange that Linux cannot just wait initializing it after it has access to the root filesystem though even for built in things.

Well, Linux solution is to have hardware kernel drivers that need firmware to be built as modules that are loaded later when / is available.

Feels a bit strange though that it can't simply just wait for when the filesystem because available for built in parts. There are all sorts of reasons I feel why one wouldn't want to have it as a module and people even build it without loadable module support which shouldn't have to rely on building it straight into the kernel then I feel but it is what it is.

The kernel code is simpler if it can assume that firmware is available when it is needed. If the driver is built-in, it initializes early, and needs built-in firmware because that is the only source of firmware during early initialization. To support the behavior you want would require that the kernel somehow detect later in the boot process that it has gained access to an additional source of firmware, and retry the device initialization at that point.

Wouldn't that just be “after the root filesystem is mounted” which doesn't seem like advanced detection to me though. But maybe the problem is more complex than I imagine it to be. It's not like it doesn't work but making something a module just to get it to initialize later rather than something that is conditionally needed seems like a big hack to me.

[dmpogo]

Feels a bit strange though that it can't simply just wait for when the filesystem because available for built in parts. There are all sorts of reasons I feel why one wouldn't want to have it as a module and people even build it without loadable module support which shouldn't have to rely on building it straight into the kernel then I feel but it is what it is.

I know what yoo want to say, but think of it

Kernel loads, hardware driver is build it and starts talking to hardware, attempting to initialize it. At this moment kernel does not know whether it will even have a firmware to wait for.
Hardware replies, driver tries to get through initialization, and then stops because there is no firmware. Waiting for something that may not even exist.

Now firmware becomes available. Most often it means that driver has to repeat initialization from the beginning. Why did it do it the first time ?

It is much more elegant to postpone running the driver that needs firmware until the latter is available. The part of the kernel that can be run later, after the main kernel is loaded (which is loaded only once), is called a module, which can be loaded as needed at a later time.

[NeddySeagoon]

It happens that by default, firmware is in /lib/firmware, which is on the root filesystem.
It could be on a USB stick in my pocket. How long do you wait for firmware to be available and how is it detected?

In the case of missing GPU firmware, you may not have a console display.

[grknight]

I have seen certain ethernet drivers retry firmware loading later.

However, it is rather trivial to have such a driver keep its own state and recheck on an "up" request.
Most networking requests would assume there is a root file system available (except maybe root on NFS).

[mi_unixbird]

Feels a bit strange though that it can't simply just wait for when the filesystem because available for built in parts. There are all sorts of reasons I feel why one wouldn't want to have it as a module and people even build it without loadable module support which shouldn't have to rely on building it straight into the kernel then I feel but it is what it is.

I know what yoo want to say, but think of it

Kernel loads, hardware driver is build it and starts talking to hardware, attempting to initialize it. At this moment kernel does not know whether it will even have a firmware to wait for.
Hardware replies, driver tries to get through initialization, and then stops because there is no firmware. Waiting for something that may not even exist.

Now firmware becomes available. Most often it means that driver has to repeat initialization from the beginning. Why did it do it the first time ?

It is much more elegant to postpone running the driver that needs firmware until the latter is available. The part of the kernel that can be run later, after the main kernel is loaded (which is loaded only once), is called a module, which can be loaded as needed at a later time.

I guess I feel that at that point a concept of a “built in module” would be better. I'm not so much suggesting that the kernel try again, but that I feel that keeping the module outside of the kernel binary on the filesystem for the purpose of delaying the initialization is kind of hackey and there is probably some use case where the code needs to be initialized later, but loading modules is also turned off, maybe for security reasons or whatever. So I feel maybe there should be “quadstate” as in “built in, but only initialize when modules are initially loaded”.

It happens that by default, firmware is in /lib/firmware, which is on the root filesystem.
It could be on a USB stick in my pocket. How long do you wait for firmware to be available and how is it detected?

In the case of missing GPU firmware, you may not have a console display.

Yeah, this is a fair way to look at it I guess, at this point the logic to initialize should probably be in userspace anyway as in some kind of trigger that decides when to load the module.

[Hu]

Yes, making it a module is a workaround based on existing features. If you want this to work today, and the driver will be built-in, then the firmware should be built-in, too. This is well-supported. It costs a bit more space, and reduces flexibility since a kernel rebuild is required to swap out firmware, but it does enable building a no-modules kernel that also uses firmware.

Yes, in theory, the kernel could have this delayed initialization quadstate. However, as I wrote above, the kernel code is simpler if the driver can assume firmware is available. As a corollary, the general initialization code is simpler if it can assume that every built-in driver can be initialized in-order, before root is mounted. Supporting this delayed initialization would require the kernel to keep another table of "late" drivers, which it walks after it believes firmware has become available. As Neddy notes, mounting root is usually, but not always, the way to make more firmware available. Maybe someone keeps their firmware on NFS, and relies on initscripts from a local root filesystem to mount NFS before using any devices that require firmware. Delayed initialization would also mean that some kernel drivers may have completed their first round initialization, but are not truly usable yet, and so any code that needs to use them also needs to be delayed.