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

Using FreeBSD 14.0 + Windows 11,I can use more than 1 vcpu and my RTX 2080 ti is properly detected :

Istantanea_2024-07-07_10-57-41.jpg


Since I'm trying to passthru the gpu on Windows,I don't need to use the Corvin patches,that are for Linux. Actually If I want to virtualize Linux,I use a different bhyve executable,but the same vmm.ko and it works. It means that I can run more Linux and Windows at the same time. For sure I can't use the same GPU,but If I have more GPUs,I can assign one GPU for each Linux or Windows vm. Everything works perfectly on 14.0,but something breaks all of this on 14.1.

Check the image below,I've used these parameters in bhyve,that you can replicate with vm-bhyve or without it. Infact I don't use it. It's totally not useful (in my humble opinion) :

Code: 
/usr/sbin/./bhyve-win -S -c sockets=1,cores=4,threads=1 -m 8G -w -H \

and this is what Windows sees :

Istantanea_2024-07-07_11-37-15.jpg
 
cracauer@ said:
You use `git log origin/stable/14`. You select those commits between the release dates of 14.0 and 14.1. Collect the hashes in a file.

You then use `git checkout <hash>` to test one of them. You should test the first and the last one first to make sure one is working and one is broken. Then you do a binary search on the commit hashes in between. Do you know what a binary search is?
Click to expand...

At this point,please,I need to have the full instructions,one by one, because I'm confused. Very very thanks.
 
List of versions tried with bisect :

1) FreeBSD marietto 14.0-ALPHA4 FreeBSD 14.0-ALPHA4 amd64 1400097 #5 n265058-dde83fc4d2e6 : NO
 
14.0-ALPHA is before 14.0 right ? If it work on 14.0-RELEASE and 14.1-RELEASE you should search for commit in between.

The binary search stuff can easily be done with git bisect.
 
monwarez said:
14.0-ALPHA is before 14.0 right ? If it work on 14.0-RELEASE and 14.1-RELEASE you should search for commit in between.

The binary search stuff can easily be done with git bisect.
Click to expand...

It works on 14.0p6. I've upgraded 14.0p6 to 14.1 and it stopped working (14.1 is not good). Can you tell me the correct values to assign to :

git bisect start
git bisect bad
git bisect good

thanks. Because the values that you have took for granted,these values :

Code: 
[root@marietto /usr/src]==> git bisect start 5e23806790ef
You are already on 'main'
Your branch is updated respect to 'origin/main'.
status: waiting for good commit(s), bad commit known

[root@marietto /usr/src]==> git bisect bad dcdea9e8623e
status: waiting for good commit(s), bad commit known

[root@marietto /usr/src]==> git bisect good 5e23806790ef
Bisection: a merge base must be tested

aren't good if it has built 14.0-ALPHA....
 
I would not use git bisect because of the large number of total commits. I would make a list of commits touching interesting code and manually do a binary search on that.
 
cracauer@ said:
I would not use git bisect because of the large number of total commits. I would make a list of commits touching interesting code and manually do a binary search on that.
Click to expand...


Istantanea_2024-07-07_17-04-01.jpg


I'm not able to do it wIthout full e detailed instructions. This new workflow sounds very complicated to me.
 
You use `git log origin/stable/14`. You select those commits between the release dates of 14.0 and 14.1. Collect the hashes in a file. If you want to save time you select those that have anything to do with the topic at hand.

Alternatively `git log origin/stable/14 -- sys/amd64/vmm/`. That would only cover changes to that subdirectory, which is likely but not certainly responsible for the issue.
 
monwarez : I've created this script and I reran it several times :

Code: 
#git clone https://git.FreeBSD.org/src.git /usr/src
cd /usr/src
#make clean
git checkout releng/14.1
git bisect start 5e23806790ef
git bisect bad dcdea9e8623e
git bisect good 5e23806790ef
make -j12 buildworld
make -j12 kernel

but everytime I get the same (wrong) version of FreeBSD :

Code: 
FreeBSD marietto 14.0-ALPHA4 FreeBSD 14.0-ALPHA4 amd64 1400097 #7 n265058-dde83fc4d2e6

so,there is something thats broken.
 
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]
 
Hum, commit 5e23806790ef have a FreeBSD version of 1400097, so it is coherent.
You could try the commit from cracauer@ , if at least one of them work, it will reduce the number of commit to test.
 
A job more tedious than this can't exist. You remind me the movie karate kid,when the "master" Miaghy told to "Daniel San" : give the wax take the wax away. He did it because he wanted to learn. You can call me "Mario San" ; I want to do it for a lot of reasons. Now,let's take this commit :

Code: 
commit 125a2a6b676484964661689f8a62d59d0a49fa14
Author: Warner Losh <imp@FreeBSD.org>
Date:   Sat May 11 16:35:54 2024 -0600

    MFC: linux: Make module standalone-buildable
    
    Add opt_inet.h and opt_usb.h to make linux module buildable standalone.
    
    (cherry picked from commit c5f906d32d2bc8e37f1e1911382e27af7e6240ff)

what's the hash ? thanks.
 
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?
Click to expand...

No,I don't know how to do a binary search. Teach me,master Cracauer.
 
ziomario said:
A job more tedious than this can't exist. You remind me the movie karate kid,when the "master" Miaghy told to "Daniel San" : give the wax take the wax away. He did it because he wanted to learn. You can call me "Mario San" ; I want to do it for a lot of reasons. Now,let's take this commit :

Code: 
commit 125a2a6b676484964661689f8a62d59d0a49fa14
Author: Warner Losh <imp@FreeBSD.org>
Date:   Sat May 11 16:35:54 2024 -0600

    MFC: linux: Make module standalone-buildable
   
    Add opt_inet.h and opt_usb.h to make linux module buildable standalone.
   
    (cherry picked from commit c5f906d32d2bc8e37f1e1911382e27af7e6240ff)

what's the hash ? thanks.
Click to expand...

The long mixed string after "commit". 125a2a6b676484964661689f8a62d59d0a49fa14
 
ziomario said:
No,I don't know how to do a binary search. Teach me,master Cracauer.
Click to expand...

Well, remember before you do that you need to test the first and the last commit in your set to verify that one works and the other does not, m'kay?

Binary search. Let's say you have 100 commits, sorted by date, and you want to find one that breaks things. You first test commit 50. Afterwards you know whether the broken commit is before or after 50. If it is before you next test commit 25. If the result of that is that the breakage is after you test commit 37. And so on.
 
ziomario said:
A job more tedious than this can't exist. …
Click to expand...

With Mozilla, there's the luxury of mozregression, which automates a mass of stuff for a complex application, e.g. Firefox.

The tester simply responds with one of five words (pictured), for each automated build, until things are narrowed down.

No such luxury for the complex operating system that is FreeBSD.
 

Attachments

  • 1720372950844.png
    1720372950844.png
    142.8 KB · Views: 29
To make this more concrete, here is what ziomario can do:


git checkout release/14.1.0
git bisect start
git bisect bad
git bisect good release/14.0.0
# now git will bisect this range.... and checkout something in the middle

# repeat the following until done
make buildworld kernel
reboot
# on rebooted kernel:
make installworld
etcupdate -B
# start your test and see if succeeds or fails
git bisect <good or bad> # depending on the result
# now repeat the previous steps starting with make buildworld


At the end, if all worked as expected, you should have <hash1> that succeeds and <hash2> that fails (<hash2> is just one more commit after <hash1>). Then do a diff "git diff <hash1> <hash2>".

Use "git help bisect" to understand it better.
 
bakul said:
You can use "git merge-base release/14.0.0 release/14.1.0" to find the common ancestor and replace release/14.0.0 in the above with it (assuming it is good).
Click to expand...

That has a risk of going further back than necessary.

Another `git log` between the revision found here and 14.0 would be indicated to make sure they are close.
 
You must log in or register to reply here.
Back
Top