Sorry to keep pinging this one. If you install OPENBSD_6_3 in KVM/QEMU and run syspatch and apply the LFENCE patch the machine redeems unable to boot. I think that this should be another patch to fix the problem, anyone using a OpenBSD virtual server with that config will ruin the boot process with the patches.
Cheers. Elias. 2018-08-04 16:47 GMT-03:00 Elias M. Mariani <[email protected]>: > Hi Mike, > I saw the changes in source about this from Bryan. > This also hit OPENBSD_63 from a patch. > Shouldn't be a another patch or something ? > > Cheers. > Elias. > > 2018-08-01 13:23 GMT-03:00 Mike Larkin <[email protected]>: >> On Wed, Aug 01, 2018 at 12:04:55AM -0300, Elias M. Mariani wrote: >>> (sorry, I forgot to add the list) >>> Here you go. >>> Cheers. >>> >>> 2018-07-31 20:47 GMT-03:00 Mike Larkin <[email protected]>: >>> > On Tue, Jul 31, 2018 at 04:43:22PM -0700, Mike Larkin wrote: >>> >> On Tue, Jul 31, 2018 at 04:59:54PM -0300, Elias M. Mariani wrote: >>> >> > And segmentation fault after applying the patches on OPENBSD_63. >>> >> > Maybe is just a coincidence, according to the data: >>> >> > HOST: ubuntu >>> >> > QEMU: Running OPENBSD_63 + patches >>> >> > (was working OK until patched). >>> >> > >>> >> > Cheers. >>> >> > Elias. >>> >> > >>> >> > 2018-07-31 16:36 GMT-03:00 Elias M. Mariani <[email protected]>: >>> >> > > Trying to boot in QEMU from snapshots/amd64/cd63.iso or from >>> >> > > snapshots/amd64/bsd.rd from the current disk: >>> >> > > The booting starts but the machine gets rebooted almost immediately. >>> >> > > >>> >> > > I'm reporting this pretty bad. But is because I'm using 6.3 in that >>> >> > > cloud server and just wanted to test if the snapshot was booting >>> >> > > correctly. QEMU is running in godsknowswhat. >>> >> > > I have never used QEMU myself, could someone try to reproduce ? >>> >> > > using cd63.iso from OPENBSD_63 gives no problems. >>> >> > > >>> >> > > Cheers. >>> >> > > Elias. >>> >> >>> >> >>> >> This may be related to the recent speculation/lfence fix that went in >>> >> a week or so ago. It reads an MSR that should be present on that CPU (and >>> >> if it isn't, we won't read it). >>> >> >>> >> I have one of those same Opterons here, I'll update it to -current and >>> >> see >>> >> if I can repro this on real hardware. My guess is that kvm is failing the >>> >> RDMSR because the knowledge of it post-dates the time that kvm was built. >>> >> >>> >> -ml >>> >> >>> > >>> > PS, "show registers" at ddb> prompt would confirm that is indeed this fix, >>> > if you could do that and report the output it would be appreciated. >>> > >> >> Yes, this is related to the change I thought. I still haven't had a chance to >> check on real hardware yet, though.
