> On Feb 13, 2025, at 14:55, Warner Losh <i...@bsdimp.com> wrote: > >> On Thu, Feb 13, 2025, 3:40 PM Mark Millard <mark...@yahoo.com> wrote: >> I've been testing using FreeBSD under Parallels on a MacBook Pro M4 MAX, >> although the issue below and its handling may not be specific to aarch64 >> contexts. >> >> After (from a demsg -a from a verbose boot): >> >> . . . >> 000.000078 [ 452] vtnet_netmap_attach vtnet attached txq=1, txd=128 >> rxq=1, rxd=128 >> pci0: <unknown> at device 9.0 (no driver attached) >> virtio_pci1: <VirtIO PCI (modern) GPU adapter> mem >> 0x10000000-0x17ffffff,0x18008000-0x18008fff,0x18000000-0x18003fff at device >> 10.0 on pci0 >> vtgpu0: <VirtIO GPU> on virtio_pci1 >> virtio_pci1: host features: 0x100000000 <Version1> >> virtio_pci1: negotiated features: 0x100000000 <Version1> >> virtio_pci1: attempting to allocate 1 MSI-X vectors (2 supported) >> virtio_pci1: attempting to allocate 2 MSI-X vectors (2 supported) >> pcib0: matched entry for 0.10.INTA >> pcib0: slot 10 INTA hardwired to IRQ 39 >> virtio_pci1: using legacy interrupt >> VT: Replacing driver "efifb" with new "virtio_gpu". >> >> I end have no console. I ended up in a state where it >> turned out booting went to stand-alone mode for a manual >> fsck. So: no ssh access or any other access. I ended up >> using the Windows Dev Kit 2023 with the boot device in >> order figure out what was going on and to the the needed >> fsck. >> >> Turns out that if I'm building, installing, and booting >> my own kernel, there is a way around that replacement >> of efifb by using: >> >> nodevice virtio_gpu >> >> in the kernel configuration, so that the boot ends up >> using efifb (no replacement). >> >> If course, this does not help with kernels from official >> FreeBSD builds. >> >> Is there a way to disable virtio_gpu for something that >> runs an official kernel build (where virtio_gpu is >> built into the kernel)? > > > boot_serial=no > > In loader.conf?
How would that lead to not doing: VT: Replacing driver "efifb" with new "virtio_gpu". ? Using the menu, all 4 combinations stopped in the same place and way until I built and used a kernel that did not have virtio_gpu at all, if I remember right. Both efifb and virtio_gpu seem to be for the video side of the alternatives. (It seems that something more is needed for virtio_gpu to end up providing a console, if it can. May be the Parallels Toolbox for an actual Linux provides what is missing for that kind of context? I'm not after X11 or such, just having an operational console for seeing information and dealing with problems when ssh can not be used.) I've no clue if the issue is specific to just Parallels or not: I've really only used Hyper-V (only getting it working for FreeBSD as a guest OS on amd64) and Parallels (aarch64 currently). So I do not know if it would be worth a tunable to, say, set the vd_priority offset from VD_PRIORITY_GENERIC, such that it could end up not replacing efifb. (I looked in the source code a little bit for this message.) === Mark Millard marklmi at yahoo.com
