Solved Trying to understand why only some kind of vmm.ko module allows to passthru my nvidia GPU to a WIndows 11 vm

cracauer@ said:
Here are the commits approximately for the right timeframe in 14-stable in directory sys/amd64/vmm/

Code: 
commit 025a5f6b2540682c69ac63f7754ce74b43441034
commit a0f02252c4175b5336c215cc7774c3ea08873476
commit 14e782708d375f19a8e19a4c7a42c5032f9997ee
commit 98b822fccd8350f59eb2deb842c52c35b145c2cb
commit b879ddc755b7eb36e1cd2468f9b55ddb3088c850
commit 8da9183dcdd328c54df527e90f50dc41aafd9c33
commit 3613a28066674aead5487d67952d50c6b228578b
commit 6d80d20a64a414782ab2e06ec0603bb40ecfbf41
commit 266eefe7f465cf99d592a47a1905f7ecd9f7e9bd
commit f27c8ff817a6f6b00ba37a6794e5b9f5d8db31b1
commit e9251d68b206d4ea4be4413c17e008c76dd49e79
commit 6ed6db3206ea96c68ffd2a952a5d0188c73b1260
commit 9e48b627aed346bf5e950134a581218d3097eb7c

Do you know how to do a binary search on them?

You start testing the first and the last to verify that one works and the other one does not.[/code]
Click to expand...

from which starting date to what ending date have you extrapolated these commits ?

Can you make a new list,including the keyword bhyve ? very thanks.
 
cracauer@ said:
If that is accurate that opens the question how PCI passthrough could have become broken without anybody else noticing and opening a big report.
Click to expand...
I am experiencing issues with PCI passthru but I can't say whether it's a FreeBSD problem: https://forums.freebsd.org/threads/bhyve-vm-stuck-when-passthru-enabled.92854/#post-648828

After updating to a recent stable/14 a few days ago I tested again and I'm still observing the same behavior.

The current assumption is that the problem is related specifically to Windows 11 as per bileslav suggestion. Whether it's a bhyve issue, an EDK issue or an "issue" inside of Windows itself is yet to be investigated.
 
jbo@ said:
I am experiencing issues with PCI passthru but I can't say whether it's a FreeBSD problem: https://forums.freebsd.org/threads/bhyve-vm-stuck-when-passthru-enabled.92854/#post-648828

The current assumption is that the problem is related specifically to Windows 11 as per bileslav suggestion. Whether it's a bhyve issue, an EDK issue or an "issue" inside of Windows itself is yet to be understood.
Click to expand...

I'm here to understand. I'm doing a big work of research for the regression,because for me it works on 14.0,but it does not for the 14.1. So,some patch introduced from the starting of 14.1 broke the correct working of my passthru.

Note : I don't have the problem that bileslav suggested for Windows 11.

so,ok,I will look for all the patches keyworded with bhyve,ed2k and vmm : I will find the guilty.
 
ziomario said:
from which starting date to what ending date have you extrapolated these commits ?

Can you make a new list,including the keyword bhyve ? very thanks.
Click to expand...

release/14.0.0 f9716eee8ab45ad906d9b5c5233ca20c10226ca7 Thu Nov 9 18:38:09 2023
==> 2f3f9c9d54bb274dfb5de40f4ce7ca944d4e05a5 on stable/14
release/14.1.0 10e31f0946d820d53adc58b7d013b969e4a9a8ed

No. This is the list for modifications of sys/amd64/vmm/, which really should be your first search. You should only widen it if this doesn't find the issue. But even if so, you do not lose the data of which commits were working or not working, so your expanded search starts much narrower.
 
ziomario said:
I'm here to understand. I'm doing a big work of research for the regression,because for me it works on 14.0,but it does not for the 14.1. So,some patch introduced from the starting of 14.1 broke the correct working of my passthru.
Click to expand...

No, the problem was introduced after 14.0, not after 14.1.
 
cracauer@ said:
release/14.0.0 f9716eee8ab45ad906d9b5c5233ca20c10226ca7 Thu Nov 9 18:38:09 2023
==> 2f3f9c9d54bb274dfb5de40f4ce7ca944d4e05a5 on stable/14
release/14.1.0 10e31f0946d820d53adc58b7d013b969e4a9a8ed

No. This is the list for modifications of sys/amd64/vmm/, which really should be your first search. You should only widen it if this doesn't find the issue. But even if so, you do not lose the data of which commits were working or not working, so your expanded search starts much narrower.
Click to expand...

Are you sure that your starting date is good ? because it works until the 14.0 p6,that I'm using actually and I presume that it will work for all the 14.0 branch. I think that I will start trying from the beginning of the creation of the 14.1,that's : 3 May 2024 ( = releng/14.1 branch created; future release engineering proceeds on this branch)
 
ziomario said:
Are you sure that your starting date is good ? because it works until the 14.0 p6,that I'm using actually and I presume that it will work for all the 14.0 branch. I think that I will start trying from the beginning of the creation of the 14.1,that's : 3 May 2024 ( = releng/14.1 branch created; future release engineering proceeds on this branch)
Click to expand...

No, as I said the first thing you need to do is that you need to verify that the first one is broken and the last one working.

The commits I listed are on the 14-stable branch so no problem getting out of 14.0.
 
cracauer@ said:
No, as I said the first thing you need to do is that you need to verify that the first one is broken and the last one working.

The commits I listed are on the 14-stable branch so no problem getting out of 14.0.
Click to expand...

Your list is not complete. There are some interesting keywords that should be taken in consideration,because they will bring us to a new patches. You haven't included these keywords. They are at least bhyve , ed2k , acpi.
 
ziomario said:
Your list is not complete. There are some interesting keywords that should be taken in consideration,because they will bring us to a new patches. You haven't included these keywords. They are at least bhyve , ed2k , acpi.
Click to expand...

You don't understand that even if the commit you are looking for is not on that list, you don't lose anything by doing the binary search in this list first. You still narrow down the date range of the commit in question a lot.
 
bileslav said:
Hello everyone,

I am the person about whom ziomario sometimes says that I gave him some files, and I'm happy to write my first message on this forum.

To avoid any further confusion, I'd just like to clarify that all the files I sent to ziomario were taken from the original, unmodified FreeBSD 14.0, and later 14.1, base files. Nothing I sent him contained any patches, except for one time, which is not relevant here.
Click to expand...

bileslav : I was confused and didn't remember what happened between us when we met on Reddit (19 may 2024). Please give a look at the first post that I wrote. I wrote that the vmm.ko file that I've got from the 14.0-RELEASE and dated 11/10/2023 does not work. And I can confirm this again because I made more tests. But you said that the file that you gave to me comes from 14.0-RELEASE. That's wrong. The file that you gave to me is dated 3/4/2024 (I'm talking about vmm.ko) and it works ; the file that I've got from the 14.0-RELEASE does not work for me. Something is not clear. Can you try to remember where you got that file ? I suspect that you were running 14.0-RELEASE,but the file vmm.ko came from another version of FreeBSD,more recent,maybe.

PS : Forgot that you haven't used 14.0-RELEASE,but 14.0-RELEASE p6....now things are more clear...
 
cracauer@ said:
f9716eee8ab45ad906d9b5c5233ca20c10226ca7
Click to expand...

Master cracauer,can you tell me what's the first commit of the FreeBSD (14.0-RELEASE p6) version ? This one :

FreeBSD blackbox.localdomain 14.0-RELEASE-p6 FreeBSD 14.0-RELEASE-p6 #0: Tue Mar 26 20:26:20 UTC 2024 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Click to expand...

I want to try that using your method (git checkout <commithash> / make -j12 buildworld buildkernel / make -j12 installworld installkernel) ; very thanks. The file vmm.ko that he gave to me comes from there and it is dated : 3/4/2024. At this point we should redo all the accounts...
 
Now we know that 14.0-RELEASE does not work and 14.0-RELEASE-p6 works and that 14.1-RELEASE does not work. I find interesting to check all the commits from 14.0-RELEASE-p1 to 14.0-RELEASE-p5 (to see when it started working) and since 14.0-RELEASE-p6 is the last one,the interesting commits come from the first commit of the 14.1-RELEASE until today (to see when it starts to be broken). That's right ? Is this method of generation of the commits list :

Code: 
git log origin/stable/14 -- sys/amd64/vmm/

still valid ?

Is this good ?

Code: 
git log origin/release/14 -- sys/amd64/vmm/
git log origin/release/14.1 -- sys/amd64/vmm/

or :

git log origin/stable/14.1 -- sys/amd64/vmm/
 
Code: 
# git checkout 70eb00f17b310f599b60939c1afa326c7b2c390c

became this one :

Code: 
FreeBSD marietto 14.0-RELEASE-p7 FreeBSD 14.0-RELEASE-p7 #13 n265420-70eb00f17b31: Tue Jul  9 11:18:32 CEST 2024     marietto@marietto:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

GPU passthru does not work anymore.
 
Confirmed. I've exchanged the vmm.ko module which works on p6 to p7 and it worked. But the official vmm.ko shipped with p7 does not work.
 
You must log in or register to reply here.
Back
Top