Date: Mon, 22 Sep 2025 16:12:06 +0000 From: Jonathan Vasquez <jon@xyinn.org> To: "virtualization@freebsd.org" <virtualization@freebsd.org> Subject: Re: GPU Passthrough on FreeBSD 14.3 (AMD Radeon RX 6900 XT and Windows 10 Pro) Message-ID: <l8EqFTkrrLvYOUcKLKIRbCxHHRDMjM--eRHlFwVyC0oHzp58cXM9bP9uLrbMe3wree4k9tI4ERHgFiBt3s9KB7htgR7FXaNNwmub7bq7K14=@xyinn.org> In-Reply-To: <21e892ba-bea5-4e65-91cf-409e5e927f67@FreeBSD.org> References: <6CV-OY6BcErrWRit9jSpi6fWsYBG3E_Z3u6eTLPcz6foPAZV1gQpZYaZTR7JA_1ot5RQVqrWQaLxJFySXjspIhSbBJGxmckcDQyzxhALNus=@xyinn.org> <CAFYkXjmmsNb1dNoq3ebm%2BVVTgVFyoDB7LHBaCKTq-VduYxp4=w@mail.gmail.com> <7YJWddCC_SUuB_mwDmHL3xecft8_rMou1xosTzBIK1UP_Fw-B786LWZX6CQ8XG6smJQRlxbfJbCq8fmTI15RouBn8GN73IfJvPOg7k6jr-s=@xyinn.org> <CAFYkXjnKjx5VeLujE%2BQ1toz6W4rvX%2Bv6iKbA4212XV_=kYkwOA@mail.gmail.com> <bnYK-9ZTxo-Xo7yaZPfiesz2zJHt6HVKDRN9pZHOSZt8bYRIAVok5rHT6fp7mFyXLJi1hRsvFpwN3dwTLw_skWH6nPXiVsEIWz4OOT16zms=@xyinn.org> <Ags2LfZGkLKZGcRQuyphkcg9wsf5q-HB1cIcphC2Eujdm0EtRkTJdHq-UHj6QLLsT53dLsfLeOib25LpGSIA-4IIqCBMMlXcfNsfCcobRJs=@xyinn.org> <MVEz5qPYM1pdpKQkFxy-FMucy9_MNUG5kn7cQGs0Czl6bU68vITWeEomJxHNqnK-qBrxo8qsdNYVD-B41qnVVz4D_QZP9E4QB75bkG5bu_s=@xyinn.org> <CAFDf7ULvsf0W8iGSYu-PWGWPgzrOC%2BoshOH1c2tDqLtkgbcw1w@mail.gmail.com> <ceec94aac0998e388eee720ad04c0e481cfc601b.camel@FreeBSD.org> <21e892ba-bea5-4e65-91cf-409e5e927f67@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
The machine ran for 22+ hours with no issues. I decided today to do a fresh restart of the host and the vm to continue testing the "deterministic stability" of the setup. A few minutes after it started, the= VM exited with a 0x88. This is a new error code that I haven't seen before. I then rebooted the host/vm again and so far it's be= en running fine for the past 1h27m on idle. So the stability still seems to be MUCH better than when I was using the multi-functional de= vice on 18/0/0 for the USB controller. Using the 13/0/0 USB controller (th= at isn't multi-functional) has massively increased stability. I'm not expecting the VM to be perfectly stable for 365 days 24/= 7 given that even regular "real" machines also act weird / have issues ever= y once in a while. I've uploaded some of the crashes I got back when I had = the 18/0/0 setup which was giving me more frequent crashes with error 0x60,= and I've also posted the one I got today after the reboot with 0x88. I'm n= ot sure if this is enough because it's hard to get debug information from t= he console output that bhyve is displaying. Usually when the VM crashes I j= ust see my console say: exited with NDELAY mode or something like that. Which is the same message I= see when I do a regular shut down. So not very helpful. You can find the output of "bhyvectl --vm=3D<name> --get-all" (which includ= es --get-exit-reason) here: https://xyinn.org/freebsd/files/gpu_pass/bhyve_= crashes/ also, does anyone know how I can send the ACPI shutdown signal to my bhyve = VM? I looked at the source code for vm-bhyve, and I just see it does a regu= lar 'kill'. I also saw some people online recommending to do a "pkill bhyve= ", but regardless of what I do, doing a kill/pkill on the PID running my bh= yve vm doesn't actually do anything. The VM still continues functioning per= fectly fine. I would like to be able to shutdown the machine from the host = so I can do a graceful shutdown. I can easily run my start up script by add= ing: @reboot root /path/to/gaming/script.sh in /etc/crontab, and that works fine, but I can't get it a signal from the = host to the vm so I can automate the shutdown counterpart. Thank you!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l8EqFTkrrLvYOUcKLKIRbCxHHRDMjM--eRHlFwVyC0oHzp58cXM9bP9uLrbMe3wree4k9tI4ERHgFiBt3s9KB7htgR7FXaNNwmub7bq7K14=>