vmm_load="YES" doesn't work anymore?

Am I missing anything?
The module vmm.ko is not loaded with vmm_load="YES" in /boot/loader.conf.
I have to load it manually. This used to work for ages, not sure when it's stopped – I restart my workstation really rarely.
 
I've experience similar issue with i915kms not loading from the /boot/loader.conf. If i load it manually after the boot or put it in /etc/rc.conf it's load normal.
 
...i915kms not loading from the /boot/loader.conf
That's right, I had to put it in kld_list= in /etc/rc.conf after upgrading my ThinkPad to FreeBSD 12. I remember reading about that somewhere though. There is a useful discussion in this thread, although it doesn't give any technical explanation why it doesn't actually work.
 
This question remains open. Especially for the case of using PCI passthru devices.
I believe if I have in /boot/loader.conf e.g.:
Code:
pptdevs="5/0/0"
I must load vmm.ko/ at boot time as well (correct me if I'm wrong).

A year ago ShelLuser posted a good explanation of /boot/loader.conf usage. I think the PCI passthru is exactly the case of using vmm_load="YES" in /boot/loader.conf, but it doesn't work anymore!

Thanks for hints and ideas!
 
I have a FreeBSD-12.0-RELEASE but without security patch. vmm.ko is loaded at each reboot with vmm_load="YES". The bhyve VMs start (with passthru devices) without any problem.

Don't know if this could help.
 
Thanks for reply, Emrion , in my FreeBSD-12.0-RELEASE id doesn't work, I believe, it's stopped working after I upgraded from 11.x...
 
I'm running 12-STABLE and have vmm_load in loader.conf. Never had a problem with that, it loads normally at boot.

Code:
vmm_load="YES"
nmdm_load="YES"
pptdevs="2/0/0"
The pptdevs is for an LSI SAS card.
 
Just installed a fresh FreeBSD 12.1 in another PC - exactly the same situation, won't load vmm.ko at boot time.
Everything is loaded except vmm. Is there any way to debug it?
My /boot/loader.conf:
Code:
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
opensolaris_load="YES"
zfs_load="YES"
linux_load="YES"
linux64_load="YES"
nvidia_load="YES"
nvidia-modeset_load="YES"
fuse_load="YES"
vmm_load="YES"
nmdm_load="YES"
 
Setting this in loader.conf may help:
Code:
verbose_loading="NO"            # Set to YES for verbose loader output
 
verbose_loading="NO" # Set to YES for verbose loader output
This has no visible effect, instead boot_verbose="YES" works.

Doesn't help much though, as you can see, the vmm is simply ignored:
Code:
....
Nov  7 11:42:55 aspen kernel: VT(efifb): resolution 640x480
Nov  7 11:42:55 aspen kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff84047000.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff84051798.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff84052080.
Nov  7 11:42:55 aspen kernel: Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff84052730.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/fuse.ko" at 0xffffffff84052788.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/nmdm.ko" at 0xffffffff84053030.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/modules/nvidia-modeset.ko" at 0xffffffff84053658.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/linux_common.ko" at 0xffffffff84053c48.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff840543f8.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff84054d60.
Nov  7 11:42:55 aspen kernel: Preloaded elf obj module "/boot/kernel/linux64.ko" at 0xffffffff84055388.
Nov  7 11:42:55 aspen kernel: Table 'FACP' at 0xc2d8d260
Nov  7 11:42:55 aspen kernel: FACP: Found table at 0xc2d8d260
Nov  7 11:42:55 aspen kernel: Calibrating TSC clock ... TSC clock: 3591756800 Hz
Nov  7 11:42:55 aspen kernel: CPU: Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz (3591.76-MHz K8-class CPU)
....
 
I experienced that yeasterday, and vmm.ko is not in /boot/kernel in here. I thought that could be due to some customization I did and I would have look today, but apparently there is something wrong with the build setup.

Is you system built from source your did you use freebsd-update? If built from source, what modifications you did?

Just to be sure. :)
 
Is you system built from source your did you use freebsd-update?
As I mentioned above, I just installed a completely fresh FreeBSD 12.1 in another PC.

However, I found a work-around by using module's absolute name:
Code:
vmm_load="YES"
vmm_name="/boot/kernel/vmm.ko"

There is another option which causes panic and stops booting for the same reason of not finding the module:
Code:
vesa_load="YES"
That work-around doesn't work since it's a separate option, not one of *_load.
 
I should have written TL;DR.

I reported to -CURRENT mailling list, and I will update in here what come from there.

Thanks!
 
In some FreeBSD 13.1 machines I have the problem below,in some others I don't have it. I would like to know what the causes could be and how to fix it.

Code:
mario@marietto:/usr/home/marietto # sudo devctl detach pci0:1:0:0
devctl: Failed to detach pci0:1:0:0: Device busy

mario@marietto:/usr/home/marietto # sudo devctl detach pci0:2:0:0
devctl: Failed to detach pci0:2:0:0: Device busy

Not even it works if instead of detach them, I try to attach them directly to the ppt driver :

Code:
mario@marietto:/usr/home/marietto/bhyve/Files # sudo devctl set driver pci0:2:0:0 ppt
devctl: Failed to set pci0:2:0:0 driver to ppt: Device busy

mario@marietto:/usr/home/marietto/bhyve/Files # sudo devctl detach pci0:2:0:0
devctl: Failed to detach pci0:2:0:0: Device busy

Pci addresses 1:0:0 and 2:0:0 belong to the two GPUs that I have on my PC :

Code:
vgapci0@pci0:1:0:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1c02 subvendor=0x19da subdevice=0x2438
vgapci1@pci0:2:0:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1e04 subvendor=0x19da subdevice=0x2503

Actually I have commented this line on /boot/loader.conf, because it makes no difference if I keep it uncommented or not. It is totally ignored.
Code:
#pptdevs="1/0/0 1/0/1 2/0/0 2/0/1 2/0/2 2/0/3"
and this behavior brought me to this post,because I'm thinking that the vmm.ko could be ignored as well as the pptdevs parameter. There could be some connection between the user case that you showed here and the behavior that I see on my FreeBSD 13.1 installation. Maybe I should add this :
Code:
vmm_name="/boot/kernel/vmm.ko"
In every FreeBSD machine I load the nvidia kernel modules adding the line below to /etc/rc.conf :
Code:
kld_list="nvidia nvidia-modeset"
according with the suggestion, should it be kld_list="/boot/modules/nvidia-modeset.ko"?

I have installed the nvidia-driver package on every machine. But as I said, in some of them I see the error above, in some others I don't see it. I'm not able to isolate the dysfunctional pattern. The xorg.conf file is the same for each machine. Can someone help me to troubleshoot the error? Thanks.
 
Back
Top