On Tue, Oct 29, 2019 at 01:25:10PM -0700, Mike Larkin wrote: > On Tue, Oct 29, 2019 at 09:16:42PM +0100, Jurjen Oskam wrote: [...] > > uvn_flush: obj=0xfffffd813ee78298, offset=0x33f0000. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > > uvn_flush: obj=0x0, offset=0x33f0000. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > > [ repeat last two lines many times ] [...] > > nvme0 at pci19 dev 0 function 0 "VMware NVMe" rev 0x00: apic 1 int 16, NVMe > > 1.0 > > nvme0: VMware Virtual NVMe Disk, firmware 1.0, serial VMWare NVME-0000 > > Why did you assign this non-default disk type to the guest VM? > > Try assigning mpi(4) (LSI Logic SAS) instead. I've been using that with my > ESXi 6.7U3 box here without problems for weeks. > > If that works, it's either an error in our nvme(4) driver or ESXi's emulation > of the NVMe hardware.
I forgot to mention that I tried using different controller types, and nvme(4) happened to be the one I took the dmesg of. The ones I tried were LSI Logic SAS, LSI Logic Parallel and VMware Paravirtual (the latter after working around the lost first write problem). All showed the same symptom. I have been trying old snapshots (thanks to the snapshot archive at ftp.hostserver.de), and found the point where the problem started to occur: All snapshots I tried up to and including this point did not show the problem: OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 All snapshots I tried starting from this point show the problem: OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 Would it be helpful to start a binary search for the exact commit that introduced the problem? I've been looking at the commit history around that time but haven't been able to spot an obvious candidate; but that's probably because I'm not a programmer. Regards, Jurjen Oskam
