Date: Thu, 13 Feb 2025 15:55:22 -0700 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: Virtualisation on FreeBSD <freebsd-virtualization@freebsd.org>, freebsd-arm <freebsd-arm@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: <CANCZdfoRUk=o6ifHa9-nX4jfjXAiBv21gwbWYQ1ovG2JTYWC%2Bw@mail.gmail.com> 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
--0000000000009a3a91062e0df4e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2025, 3:40=E2=80=AFPM Mark Millard <marklmi@yahoo.com> wrot= e: > 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=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 devi= ce > 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=3Dno In loader.conf? Warner > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --0000000000009a3a91062e0df4e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai= ner"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 13, 2025, 3:40=E2=80= =AFPM Mark Millard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.c= om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been tes= ting using FreeBSD under Parallels on a MacBook Pro M4 MAX,<br> although the issue below and its handling may not be specific to aarch64<br= > contexts.<br> <br> After (from a demsg -a from a verbose boot):<br> <br> . . .<br> 000.000078 [ 452] vtnet_netmap_attach=C2=A0 =C2=A0 =C2=A0 =C2=A0vtnet attac= hed txq=3D1, txd=3D128 rxq=3D1, rxd=3D128<br> pci0: <unknown> at device 9.0 (no driver attached)<br> virtio_pci1: <VirtIO PCI (modern) GPU adapter> mem 0x10000000-0x17fff= fff,0x18008000-0x18008fff,0x18000000-0x18003fff at device 10.0 on pci0<br> vtgpu0: <VirtIO GPU> on virtio_pci1<br> virtio_pci1: host features: 0x100000000 <Version1><br> virtio_pci1: negotiated features: 0x100000000 <Version1><br> virtio_pci1: attempting to allocate 1 MSI-X vectors (2 supported)<br> virtio_pci1: attempting to allocate 2 MSI-X vectors (2 supported)<br> pcib0: matched entry for 0.10.INTA<br> pcib0: slot 10 INTA hardwired to IRQ 39<br> virtio_pci1: using legacy interrupt<br> VT: Replacing driver "efifb" with new "virtio_gpu".<br> <br> I end have no console. I ended up in a state where it<br> turned out booting went to stand-alone mode for a manual<br> fsck. So: no ssh access or any other access. I ended up<br> using the Windows Dev Kit 2023 with the boot device in<br> order figure out what was going on and to the the needed<br> fsck.<br> <br> Turns out that if I'm building, installing, and booting<br> my own kernel, there is a way around that replacement<br> of efifb by using:<br> <br> nodevice=C2=A0 =C2=A0 =C2=A0 =C2=A0 virtio_gpu<br> <br> in the kernel configuration, so that the boot ends up<br> using efifb (no replacement).<br> <br> If course, this does not help with kernels from official<br> FreeBSD builds.<br> <br> Is there a way to disable virtio_gpu for something that<br> runs an official kernel build (where virtio_gpu is<br> built into the kernel)?<br></blockquote></div></div><div dir=3D"auto"><br><= /div><div dir=3D"auto"><br></div><div dir=3D"auto">boot_serial=3Dno</div><d= iv dir=3D"auto"><br></div><div dir=3D"auto">In loader.conf?</div><div dir= =3D"auto"><br></div><div dir=3D"auto">Warner=C2=A0</div><div dir=3D"auto"><= div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer noreferrer" targe= t=3D"_blank">yahoo.com</a><br> <br> </blockquote></div></div></div> --0000000000009a3a91062e0df4e7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoRUk=o6ifHa9-nX4jfjXAiBv21gwbWYQ1ovG2JTYWC%2Bw>