ERROR GT0: IOV: Unable to confirm version 1.4 #186
Comments
|
The firmware version in the code has recently been bumped to 1.9 since 1.4 is quite old. But my experience is that the dkms module seems to "work" even if the firmware version does not match. Still I'm wondering why Proxmox VE is not providing you the latest firmware. Guess the package Is this the same for you and do also have pve-firmware version 3.12-1 installed (check with If you want to test the previously allowed guc firmware minor version 4 instead of the updated minor version 9. You could just run the following in the root of your the i915-sriov-dkms repo: This will change Just for testing it would be enough to run just following: But this would not survive system updates in the future. |
I just update by |
|
The file list seems similar but the exact version is not shown. What is the version of your installed |
|
I encounter the same error, and my desktop on the host does not post. Will try setting GUCFIRMWARE_MINOR later. |
|
I also get the error, these are my listed huc, guc and dmc firmwares - what version numbers should these have to avoid the error? |
edit |
|
umm maybe i am a numbnuts.... but is the issue the format? I.E. its looking for 1.4 but it got 0.1.4.1 - i don't think that's older than 1.4 - i think it is newer and now is prepended with a 0. ? |
|
So do I understand this correctly: I don't remember having the issue before updating just today (kernel 6.8.12-2) or I did not notice it. Is there a solution to this? [ 5.534849] i915 0000:00:02.1: [drm] ERROR GT0: IOV: Unable to confirm version 1.13 (0000000000000000) Thats the whole log: https://pastebin.com/Ra9C5HUD |
|
I don't think that's the issue, the number mismatch issue is the same for different versions. My thesis is 1.13 and 0.1.13.4 are the same, and the error likely indicates a bug in assessing the number format for some reason. Given this is a non blocking bug, ignore it for now. |
|
Confirmed all that is needed is the firmware version command, this is also need if you have version 1.13.4 (with number 13 instead of 4_ this isn't about the driver not being there, just the difference in version strings i think? So this fixed it for me:
As i was getting a looking for 1.4 found 0.1.4.1 ---Edit--- copying the latest firmwares made ZERO difference to the interface version reported in the error, even after copying firmware from kernel.org using going one step further, the difference between 0.1.4.1 and 0.1.13.4 is whether your machine loads As such i would argue the notion that 1.4 has been superseded by 1.9 or 1.13 is wrong, they are all valid and that is why upgrading to later version of promox firmwares / pulling from intel's github repo / pulling from kernel.org doesn't help. |
|
@MacharaStormwin: Have you tried to use |
|
Is this a purely cosmetic thing? I used to see a similar error in my logs, but on boot with PVE 8.2.3 and kernel 6.8.8.4, I’m not seeing it.
```
***@***.***:~# dmesg -T | grep -i GT0
[Mon Sep 23 18:29:35 2024] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 70.20.0
[Mon Sep 23 18:29:35 2024] i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3
[Mon Sep 23 18:29:35 2024] i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads!
[Mon Sep 23 18:29:35 2024] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[Mon Sep 23 18:29:35 2024] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.1: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.1: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.2: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.2: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.3: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.3: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.4: [drm] GT0: GUC: interface version 0.1.9.0
[Mon Sep 23 18:29:37 2024] i915 0000:00:02.4: [drm] GT0: GUC: interface version 0.1.9.0
```
PVE Version:
```
pve-manager/8.2.3/b4648c690591095f (running kernel: 6.8.8-4-pve)
pve-firmware: 3.13-1
```
DKMS:
```
# dkms status
i915-sriov-dkms/2024.08.09, 6.8.8-4-pve, x86_64: installed
```
For reference, I only have 4 VFs enabled. The iGPU on an i7-12700T can probably only barely support that, to be honest.
… On Sep 22, 2024, at 6:24 PM, scyto ***@***.***> wrote:
Confirmed all that is needed is the firmware version command.
So this fixed it for me:
GUCFIRMWARE_MINOR=4 dkms install -m i915-sriov-dkms -v 2024.08.09 --force --kernelsourcedir /usr/src/linux-headers-6.8.12-2-pve/
that said, no reason not to be on latest firmwwares either :-)
—
Reply to this email directly, view it on GitHub <#186 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI5CYUOQRHXVMC3LHZYKJTZX5GUHAVCNFSM6AAAAABLSX4B5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGAYTKMRYGE>.
You are receiving this because you are subscribed to this thread.
|
I run into the same issue. Tried: `GUCFIRMWARE_MINOR=13 dkms install -m i915-sriov-dkms -v $(cat VERSION) --force i915.ko:
i915.ko:
But still: [ 10.214385] i915 0000:00:02.3: [drm] ERROR GT0: IOV: Unable to confirm version 1.13 (0000000000000000) |
Did you did both uninstall and remove before creating the new one? for reference this was my command for the error with 1.4
I needed to do the explicit kernel source path, not sure why |
|
Here are some more findings:
The GuC firmware can be retrieved from For Proxmox VE and pve-firmware this probably means the following from comparing the submodule update dates:
Please note that calling e.g. I've modified the Result with latest firmware: |
In fact, intel's upstream repo only compares the MAJOR version, so we can maybe safely remove the check.
Porting this dkms module to the most recent 6.6 kernel branch means that we need to remove support for kernels before 6.6 and rebuild the 6.8~6.11 (Intel's lts kernel seems to be backported based on 6.8) adaptation code. I may try that when I have time. EDIT: The i915 driver in the linux-intel-lts 6.6 branch depends on a backport from a newer version of the kernel. Migrating to the 6.6 branch is difficult. |
|
I guess there is still enough hope the new xe driver will support SR-IOV at some point. At the moment I'm running stable on my i9-14900K (GPU id a780) But I see some errors on my N100 (GPU id 46d1) with the latest firmware: But still both 3D acceleration and video encoding/decoding seems to work ok-ish for the N100 via remote desktop (despite the errors above): I agree that the removing the |
|
On Oct 5, 2024, at 1:57 PM, pasbec ***@***.***> wrote:
I guess there is still enough hope the new xe driver will support SR-IOV at some point.
Looks like we’re almost there. Xe is the default driver in Linux 6.12. However, the Xe driver has not been updated to know which iGPUs support SR-IOV, so right now, it’s treating none of them as having SR-IOV support.
But it looks like this is something that can eventually be toggled on by changing a build (?) flag?
See: intel/linux-intel-lts#33 (comment)
|
Done. Anyone interested in it can try PR #207 . |
|
Fedora 40 running on i7-14700k confirmed working with the following setup: sed -i 's/GUCFIRMWARE_MINOR:-9/GUCFIRMWARE_MINOR:-13/' Makefile
dkms remove i915-sriov-dkms/2024.09.21 --all
dkms install -m i915-sriov-dkms -v $(cat VERSION) -k $(uname -r) --forceAdd the following to kernel cmdline: Reboot and then: On the host:
Latest I got error code 43 on windows guest at first. After I did the steps below it works smoothly:
On the windows guest: |
This is what I see on the N100 (Alder Lake) also, with the latest Promox 8.3 kernel (6.8.12-4) and pve-firmware (3.14-1); In a linux guest I see non-stop timeout errors |
|
I have the same issue. My device info as blew: pveversion: CPU: Enabled 3 VFs: dmesg message info: I'm not sure if this is correct.. |
For which linux kernel version do you use, please. |
Fedora Workstation 40. Kernel 6.10.12-200.fc40.x86_64 |
|
@hmoffatt @pasbec But at the same time, when starting Plex or Windows VM, the load status does not change, all the time at 0, I am sure that the video core is not loading correctly. Do you have any progress in solving this problem "hwconfig table: -ENOENT", "GUC: mmio request 0x4100: failure 201/0" ? |
kernel: 6.8.8-3-pve
cpu: i5-12600T (UHD Graphics 770)
I noticed that my system log has the following output, however it looks like 3 virtualized graphics cards were created, I'm not sure if this is correct..
The text was updated successfully, but these errors were encountered: