Hi smokehydration,
I guess your VM config file has something like "viridian = 1" or
"viridian_enlightenment=xxx".
With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't be 100%
Hyper-V.
BTW, I know at least KVM can have the same behavior.
We have to find a reliable way to
> From: Konstantin Belousov [mailto:kostik...@gmail.com]
> Sent: Friday, April 8, 2016 22:02
> To: Dexuan Cui <de...@microsoft.com>
> Cc: Sepherosa Ziehau <se...@freebsd.org>; smokehydrat...@tutanota.com;
> freebsd-current@freebsd.org
> Subject: Re: Revision
to have your
confirmation.
Thanks,
-- Dexuan
> -Original Message-
> From: Dexuan Cui
> Sent: Friday, April 8, 2016 19:04
> To: 'Sepherosa Ziehau' <se...@freebsd.org>; smokehydrat...@tutanota.com
> Cc: freebsd-current@freebsd.org
> Subject: RE: Revision 29717
This failure should already been fixed by
r308799 | dexuan | 2016-11-18 16:15:45 +0800 (Fri, 18 Nov 2016) | 9 lines
fix share/man/man4/Makefile for hv_ata_pci_disengage.4
Sorry for the trouble!
Thanks,
-- Dexuan
> -Original Message-
> From: jenkins-ad...@freebsd.org
The ACPI firmware of Hyper-V UEFI VM has a Module Device whose Hardware
ID is "ACPI0004". The module device has a _CRS object defining some MMIO
ranges, which are needed when physical PCIe devices are passed through
to the VM.
Currently it looks FreeBSD doesn't make use of the ACPI module device
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Thursday, April 20, 2017 02:34
> > Can we add the support of "ACPI0004" with the below one-line change?
> >
> > acpi_sysres_probe(device_t dev)
> > {
> > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > +static char
e, though it's potentially unsafe.
I think in the loader we can use CPUID to tell if we're running on Hyper-V or
not.
Thanks,
-- Dexuan
> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Sent:
of the screen and send it to me, if it’s too big.
Thanks,
-- Dexuan
From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Thursday, March 9, 2017 10:34
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot
31491
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Toomas Soome
>
> IMO there are multiple issues around this problem and workaround.
>
> First of all, to control UEFI memory allocation, the AllocatePages() has
> options:
>
> AllocateAnyPages,
>
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Pete Wright
> Sent: Thursday, March 9, 2017 14:04
> To: freebsd-current@freebsd.org
> Subject: Re: input/output error @boot
> On 3/8/17 10:00 PM, Dexuan Cui wrote:
> > For
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Hi Chris,
> Thank you very much for the screenshots!!!
>
> On the host there is a 1MB LoaderData memory range, which splits
> the big Conventional Memory range i
r/obj/root/bsd.git/sys/boot/efi/loader/loader.efi /boot/loader.efi
Thanks,
-- Dexuan
From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Monday, March 6, 2017 20:33
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: inpu
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
>
> Please let me know in case this can't solve the issue.
Sorry, r314770 has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
>
> Please let me know in case this can't solve the issue.
Sorry, r314770 has a bug, so I had to commit r314828 for this:
https://svnweb.freebs
> From: Alex Deiter
> Sent: Sunday, March 5, 2017 03:32
>
> Hello,
>
> Screenshot: boot with patched loader:
> Video: boot with patched loader:
Hi Alex,
Thanks for the info!
Unluckily it looks the delay() in my patch didn't work here somehow, so the
screen
scrolled up so quickly that we're
> From: Chris H [mailto:bsd-li...@bsdforge.com]
> OK copying the boot.efi from the install DVD will only
> hose the system (EFI).
Do you mean copying the boot.efi from the install DVD doesn't work?
If so we need to build a good boot.efi with the CURRENT code + reverting
the offending commit.
> So
> From: Chris H [mailto:bsd-li...@bsdforge.com]
> Sent: Monday, March 6, 2017 09:57
> > Thanks! I'm eager to see your screenshots.
> > The line whose "Physical" address contains 2MB is the most interesting to
> > me.
> > And please at least post the other lines around the line.
> OK. Her you go.
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Hi Chris,
> Thank you very much for the screenshots!!!
>
> On the host there is a 1MB LoaderData memory range, which splits
> the big Conventional Memory range i
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Roberto Rodriguez Jr
> Sent: Monday, March 6, 2017 04:05
> To: freebsd-current@freebsd.org
> Subject: Re: input/output error @boot
>
> When I get to the house I'll try to patch it and see if I get
> From: Dexuan Cui
> Sent: Monday, March 6, 2017 14:35
> To: 'Roberto Rodriguez Jr' <rob.rodz@gmail.com>; freebsd-
> curr...@freebsd.org
> Subject: RE: input/output error @boot
>
> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr.
> From: Dexuan Cui
> Sent: Monday, March 6, 2017 13:10
> Can you please try the below patch?
> https://reviews.freebsd.org/D9904
> You can find the URL of the "Download Raw Diff" in the page and
> 'wget' the patch and then apply it.
>
> It should be able
> From: Chris H [mailto:bsd-li...@bsdforge.com]
> > Hi Alex,
> > Thanks for the info!
> > Unluckily it looks the delay() in my patch didn't work here somehow, so the
> > screen scrolled up so quickly that we're unable to see the output clearly...
> > :-(
> >
> > Luckily we can use this new method:
> From: Alex Deiter
> Sent: Friday, March 3, 2017 17:22
>
> Hello,
> The same issue with FreeBSD 12.0-CURRENT-r314563:
> elf64_loadimage: could not read symbols - skipped!
>
> I suspect regression after:
>
> Revision 314547 - Directory Listing
> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54
> From: Dexuan Cui
> Sent: Friday, March 3, 2017 19:50
> > From: Alex Deiter
> > Sent: Friday, March 3, 2017 17:22
> > Hello,
> > The same issue with FreeBSD 12.0-CURRENT-r314563:
> > elf64_loadimage: could not read symbols - skipped!
> >
> > I s
> From: Michael Tuexen
> Sent: Friday, March 3, 2017 21:30
> > BTW, I understand it's really annoying to boot the host first...
> > I'm really sorry for this.
> >
> > I suppose you're able to build or find a good 'loader.efi' binary on
> > another host,
> > and then manage to replace the bad
> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Hello Dexuan,
> This issue reproduced at least for 4 different HW platform
> How can I help you resolve this issue ?
>
> The same result for r314862:
Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix
the off-by-one
: Tuesday, March 7, 2017 21:27
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot
I will test tonight. Thank you very much for your time
On Mar 6, 2017 11:52 PM, "Dexuan Cui"
<de...@microsoft.com&l
> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Sent: Wednesday, March 8, 2017 09:39
> To: Dexuan Cui <de...@microsoft.com>; freebsd-current curr...@freebsd.org>
> Cc: Chris H <bsd-li...@bsdforge.com>; AN <a...@neu.net>; Ngie Cooper
> (yaneurabeya) <
> From: John Baldwin
> Sent: Thursday, April 27, 2017 00:14
> On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> > On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> > > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrot
29 matches
Mail list logo
