Resolved (was: Re: Problem (re)building graphics/drm-61-kmod via PORTS_MODULES+=)
After the ports update main-n684003-baeefdddb6ed: commit baeefdddb6ed74573128353fac7d9b7805fa1a30 Author: Emmanuel Vadot AuthorDate: Sat Oct 26 08:38:11 2024 +0200 Commit: Emmanuel Vadot CommitDate: Sat Oct 26 09:10:02 2024 +0200 graphics/drm-61-kmod: Update to drm_v6.1.92_2 This fixes (again) the build with LLVM 19 Sponsored by: Beckhoff Automation GmbH & Co. LG I had no issues updating head from main-n273225-3df1abdfd9c3 to main-n273250-9d585fc395c3 (or for updating stable/14 from stable/14-n269307-b45cf7181e5b to stable/14-n269310-bbd018d0aaaf) using PORTS_MODULES+=graphics/drm-61-kmod in /etc/src.conf. Peace, david -- David H. Wolfskill da...@catwhisker.org It has been said that history repeats itself. This is perhaps not quite correct; it merely rhymes. -- Theodor Reik See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: bhyve regression (head): windows VMs failing with error 0xc000021a
On Fri, Oct 25, 2024 at 11:12:48PM +0200, Guido Falsi wrote: > On 25/10/24 22:49, Mark Johnston wrote: > > On Fri, Oct 25, 2024 at 09:24:13PM +0200, Guido Falsi wrote: > > > Hi, > > > > > > I've recently updated my current machines to git commit > > > 525a177c165740fc697df3de5b92e58b3b41477c (Sun Oct 20 22:43:41 2024 -0800) > > > and just have Windows 10 VMs fail to start in bhyve with the error in the > > > subject. > > > > > > I've been unable to recover them with usual tricks (automatic recovery, > > > chkdsk, and other tools provided by the OS). Looks like the machine fails > > > to > > > read C: after boot. > > > > > > These machines were working fine before the update, so my suspect is that > > > some recent change in bhyve is causing the issue and the VMs would be > > > otherwise fine. > > > > > > The VMs have their filesystems in compressed zvols. > > > > > > Anyone has an idea or can point to some change I can test reverting? > > > > Just a guess, but you might try adding "-o pci.enable_bars=true" to the > > bhyve command line arguments > > Tried but it looks like it made no difference. > > > > > > I an also try bisecting, I'd guess the issue is quite recent. > > > > Which revision did you update from? > > I updated from git commit 450a6690f557493bd33d8f3666b22ddc5150703b (Thu Sep > 19 11:49:40 2024 -0500) > > In the while I noticed some commits to TPM emulation/passthorugh, maybe > they're related? It might be, but I don't see any TPM devices configured in the invocation below. There was a number of changes to usr.sbin/bhyve in that window, so reverting them one by one would probably turn up the culprit. Or, you need to pick up commit 8c8ebbb045185396083cd3e4d333fe1851930ee7, given that you're using AHCI emulation. > > > > > Thanks in advance for any advice. > > > > > > Obviously if any further info is needed just ask. > > > > What command line arguments are passed to bhyve? What boot firmware are > > you using? > > I'm using vm-bhyve, from its log the options should have been: > > -c 4,sockets=1,cores=2,threads=2 -m 4G -AHPw -l > bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -o pci.enable_bars=true > -U xxx -s 0,hostbridge -s 31,lpc -s > 4:0,ahci,hd:/dev/zvol/zroot/bhyve/W64/disk0 -s 5:0,virtio-net,tap1,mac=xxx > -s 6:0,fbuf,tcp=127.0.0.1:5900,w=1600,h=900 -s 7:0,xhci,tablet -s > 8:0,hda,play=/dev/dsp1 -l com1,stdio > > (replaced MAC and UUID with xxx) > > for firmware I'm using bhyve-firmware-1.0_2 from sysutils/bhyve-firmware
Re: bhyve regression (head): windows VMs failing with error 0xc000021a
On 26/10/24 15:28, Mark Johnston wrote: On Fri, Oct 25, 2024 at 11:12:48PM +0200, Guido Falsi wrote: On 25/10/24 22:49, Mark Johnston wrote: On Fri, Oct 25, 2024 at 09:24:13PM +0200, Guido Falsi wrote: Hi, I've recently updated my current machines to git commit 525a177c165740fc697df3de5b92e58b3b41477c (Sun Oct 20 22:43:41 2024 -0800) and just have Windows 10 VMs fail to start in bhyve with the error in the subject. I've been unable to recover them with usual tricks (automatic recovery, chkdsk, and other tools provided by the OS). Looks like the machine fails to read C: after boot. These machines were working fine before the update, so my suspect is that some recent change in bhyve is causing the issue and the VMs would be otherwise fine. The VMs have their filesystems in compressed zvols. Anyone has an idea or can point to some change I can test reverting? Just a guess, but you might try adding "-o pci.enable_bars=true" to the bhyve command line arguments Tried but it looks like it made no difference. I an also try bisecting, I'd guess the issue is quite recent. Which revision did you update from? I updated from git commit 450a6690f557493bd33d8f3666b22ddc5150703b (Thu Sep 19 11:49:40 2024 -0500) In the while I noticed some commits to TPM emulation/passthorugh, maybe they're related? It might be, but I don't see any TPM devices configured in the invocation below. There was a number of changes to usr.sbin/bhyve in that window, so reverting them one by one would probably turn up the culprit. Or, you need to pick up commit 8c8ebbb045185396083cd3e4d333fe1851930ee7, given that you're using AHCI emulation. Thanks for the suggestions. I'm using AHCI since it is suggested for windows guests. (BTW I'm trying to get rid of windows guests, but I still need them from time to time) I'll try updating again including the commit you suggest first. I'll report back if that fixes the issue. -- Guido Falsi
