Date: Fri, 14 Feb 2025 17:15:21 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD virtualization <freebsd-virtualization@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, Warner Losh <imp@bsdimp.com>, John Baldwin <jhb@FreeBSD.org> Subject: Re: A way to have a console (aarch64) under macOS Parallels: build the kernel with nodevice virtio_gpu; any way with an official kernel build? Message-ID: <67D0FCFF-54FC-4121-91F6-EC48B437991A@FreeBSD.org> In-Reply-To: <EA92D7D4-5ACB-40E3-82F0-F342ED382C5D@yahoo.com> References: <EA92D7D4-5ACB-40E3-82F0-F342ED382C5D.ref@yahoo.com> <EA92D7D4-5ACB-40E3-82F0-F342ED382C5D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 14, 2025, at 6:39 AM, Mark Millard <marklmi@yahoo.com> wrote: >=20 > 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. >=20 > After (from a demsg -a from a verbose boot): >=20 > . . . > 000.000078 [ 452] vtnet_netmap_attach vtnet attached txq=3D1, = txd=3D128 rxq=3D1, rxd=3D128 > 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". >=20 > 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. >=20 > Turns out that if I'm building, installing, and booting > my own kernel, there is a way around that replacement > of efifb by using: >=20 > nodevice virtio_gpu >=20 > in the kernel configuration, so that the boot ends up > using efifb (no replacement). >=20 > If course, this does not help with kernels from official > FreeBSD builds. >=20 > Is there a way to disable virtio_gpu for something that > runs an official kernel build (where virtio_gpu is > built into the kernel)? May you try with device.hints(5) ? It can mark a device disabled ( no driver loaded ) when probing, so you = can avoid `VT: Replacing driver "efifb" with new "virtio_gpu"` and should have the = same effect with `nodevice virtio_gpu`. Best regards, Zhenlei >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67D0FCFF-54FC-4121-91F6-EC48B437991A>