On 11/29/14 06:02, Anish Gupta wrote:
bge0@pci0:2:0:0: class=0x020000 card=0x06471025
chip=0x16b514e4 rev=0x10 hdr=0x00
sdhci_pci0@pci0:2:0:1: class=0x080501 card=0x06471025
chip=0x16bc14e4 rev=0x10 hdr=0x00
none2@pci0:2:0:2: class=0x088000 card=0x06471025
chip=0x16be14e4 rev=0x10 hdr=0x00
none3@pci0:2:0:3: class=0x088000 card=0x06471025
chip=0x16bf14e4 rev=0x10 hdr=0x00
Passthrough stub driver is part of vmm.ko and if it was present early in
boot, you should see ppt@pciD:B:S:F[Domain:Bus:Slot:Function] in
pciocnf list above. Given that bge driver claimed 2/0/0, most likely
vmm.ko failed to load or probably was not present. Do you have
vmm_load=“YES” in /boot/loader.conf as mentioned in
Yes. To make testing easier:
I removed everything from loader.conf and I removed a few drivers(bge
and a few others) that were built-in the kernel, so the host kernel
won't use them
and now I am testing with kenv and loading and unloading vmm.ko. I
always see the correct ppt devices in the dmesg when vmm.ko is loaded.
If you already have loader.conf configured correctly, you can try to
manually load vmm.ko once system is booted and see dmesg for any problem
in loading it like kernel mismatch, missing symbol[One common I usually
encounter is KTRACE define in sys/modules/vmm/Makefile but kernel config
is missing “option KTRACE”] etc.
Everything seems ok here as well, I get nothing but the ppt devices.
One thing I noticed and seems different is this:
ppt0 mem 0xb3430000-0xb343ffff,0xb3440000-0xb344ffff irq 16 at device 0.0 on
ppt1 mem 0xb3400000-0xb340ffff irq 17 at device 0.1 on pci2
ppt2 mem 0xb3410000-0xb341ffff irq 17 at device 0.2 on pci2
ppt3 mem 0xb3420000-0xb342ffff irq 17 at device 0.3 on pci2
so ppt0 (the bge device) has two mem ranges...
Another thing I should mention is that "acpidump -t | grep DMAR"
reports nothing. It is mentioned in the documentation but I didn't see
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to