Thanks for sending me your memmap and this is a temporary workaround
patch for you:
I put the memmap info here for people who're interested:
We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
loader.efi just writes into this range by force -- this is unsafe anyway!
To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
that would require a lot of complicated long term work:
For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's potentially unsafe.
I think in the loader we can use CPUID to tell if we're running on Hyper-V or
> -----Original Message-----
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Sent: Thursday, March 9, 2017 10:44
> To: Roberto Rodriguez Jr <rob.rodz....@gmail.com>
> Cc: FreeBSD Current <email@example.com>
> Subject: RE: input/output error @boot
> [This sender failed our fraud detection checks and may not be who they appear
> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> Hmm, Alex did report 314891 worked.
> Can you please post the full boot log of the loader?
> Especially, when you see the “OK” prompt, can you please run the “memmap”
> command like this link ...
> You can take a photo of the screen and send it to me, if it’s too big.
> -- Dexuan
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"