> 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 *s
On Wednesday, April 19, 2017 12:26:51 PM Dexuan Cui wrote:
> 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.
>
>
On Sunday, April 09, 2017 06:08:04 PM Jeffrey Bouquet wrote:
> i386_set_ldt: start=-1 num=1 descs=0x38449fac
This message is a harmless debug printf. Somehow you compiled
sys/i386/i386/sys_machdep.c with 'DEBUG' defined to enable it
though. (The message is not enabled by default.)
> Tons of th
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
I'm currently rebuilding world and kernel on a just completed SVN checkout.
Note that the normal sendmail daemon which listens for incoming traffic
does NOT loop.
The sendmail instance which tries local delivery (echo Hi | mail root) or
the msp_queue instance is looping.
It might be an arm64 spe
