Re: snapshot boot fails with error "entry point at 0x1001000"
Hi all, For the record, Mark Kettenis' patch below fixed the boot stuck problem on my Intel NUC Kit NUC7PJYH mini server, see the following email thread: https://marc.info/?l=openbsd-misc=160391516603159 Thanks a lot for this. Cheers. Fabian > Hi Mark, > > on my Lenovo V130 the patch works. Now I'm able to boot the current > kernel again, without the need to remove the radeon and amdgpu driver > (https://marc.info/?l=openbsd-misc=159276382718317=2) > > Thanks and best regards, > Sven > > On 10/27/20 1:40 PM, Mark Kettenis wrote: > > Hi Kastus, > > > > Please don't have technical discussions on misc@; some developers, > > like me, only read it sporadically. The tech@ list is a much better > > place. > > > > The problem with your approach is that you allocate memory at a fixed > > address, and we can't be sure that memory is available. We may have > > to extend the amount of memory we allocate such that larger kernels > > fit. The diff below bumps it from 32MB to 64MB. Does this work for > > you? > > > > > > Index: arch/amd64/stand/efiboot/efiboot.c > > === > > RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v > > retrieving revision 1.35 > > diff -u -p -r1.35 efiboot.c > > --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - > > 1.35 > > +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - > > @@ -39,7 +39,7 @@ > > #include "eficall.h" > > #include "run_i386.h" > > > > -#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024) > > +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) > > > > EFI_SYSTEM_TABLE *ST; > > EFI_BOOT_SERVICES *BS;
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi Mark, on my Lenovo V130 the patch works. Now I'm able to boot the current kernel again, without the need to remove the radeon and amdgpu driver (https://marc.info/?l=openbsd-misc=159276382718317=2) Thanks and best regards, Sven On 10/27/20 1:40 PM, Mark Kettenis wrote: Hi Kastus, Please don't have technical discussions on misc@; some developers, like me, only read it sporadically. The tech@ list is a much better place. The problem with your approach is that you allocate memory at a fixed address, and we can't be sure that memory is available. We may have to extend the amount of memory we allocate such that larger kernels fit. The diff below bumps it from 32MB to 64MB. Does this work for you? Index: arch/amd64/stand/efiboot/efiboot.c === RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v retrieving revision 1.35 diff -u -p -r1.35 efiboot.c --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - 1.35 +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - @@ -39,7 +39,7 @@ #include "eficall.h" #include "run_i386.h" -#define KERN_LOADSPACE_SIZE (32 * 1024 * 1024) +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) EFI_SYSTEM_TABLE *ST; EFI_BOOT_SERVICES *BS;
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi Kastus, Please don't have technical discussions on misc@; some developers, like me, only read it sporadically. The tech@ list is a much better place. The problem with your approach is that you allocate memory at a fixed address, and we can't be sure that memory is available. We may have to extend the amount of memory we allocate such that larger kernels fit. The diff below bumps it from 32MB to 64MB. Does this work for you? Index: arch/amd64/stand/efiboot/efiboot.c === RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v retrieving revision 1.35 diff -u -p -r1.35 efiboot.c --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - 1.35 +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - @@ -39,7 +39,7 @@ #include "eficall.h" #include "run_i386.h" -#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024) +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) EFI_SYSTEM_TABLE *ST; EFI_BOOT_SERVICES *BS;
Re: snapshot boot fails with error "entry point at 0x1001000"
On Sun, Jul 05, 2020 at 09:32:47PM -0700, Kastus Shchuka wrote:
> On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> > Kastus Shchuka wrote:
> > “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able
> > to boot it.
> > Boot stops at the line
> >
> > entry point at 0x1001000
> >
> > If I try bsd.rd kernel, it boots just fine. After this failure with
> > snapshot I
> > installed 6.7-release, and it boots without any issues.”
> >
> >
> > I've experienced something similar, including the sensitivity to kernel
> > size. As best I can observe, the EFI bootloader is being handed a different
> > block of RAM than where the kernel is actually loaded (which is at a fixed
> > address defined in boot.c). Which block of memory gets returned, and
> > whether boot fails, seems to be dependent on the particular UEFI
> > ROM/chipset. In my case, debugging over serial, I observe a page fault
> > while the kernel is still being loaded into RAM.
> > “Are there any other solutions than compiling a custom smaller kernel?”
> >
> >
> > Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it
> > for me:
> > --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> > +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> > @@ -303,9 +303,9 @@ efi_memprobe(void)
> > bios_memmap_t *bm;
> > EFI_STATUS status;
> > EFI_PHYSICAL_ADDRESS
> > -addr = 0x1000ULL; /* Below 256MB */
> > +addr = 0x100;
> >
> > - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> > EfiLoaderData,
> > + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> > EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> > if (status != EFI_SUCCESS)
> > panic("BS->AllocatePages()");
> > Let me know if that helps. I can't guarantee that this is actually what is
> > causing your issue but it worked for me.
>
> I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
> recompiled BOOTX64.EFI.
> It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
>
> I wonder what would it take for the patch to be accepted in -current?
>
As Mike Larkin pointed in
https://marc.info/?l=openbsd-misc=160377179930502=2, "mach mem"
output may shed some light on the problem.
So, for the ASRock J4105M motherboard, the output is this:
>> OpenBSD/amd64 BOOTX64 3.50
boot> mach mem
Region 0: type 1 at 0x0 for 248KB
Region 1: type 2 at 0x3e000 for 8KB
Region 2: type 1 at 0x4 for 376KB
Region 3: type 2 at 0x9e000 for 392KB
Region 4: type 1 at 0x10 for 261120KB
Region 5: type 1 at 0x12151000 for 1454584KB
Region 6: type 2 at 0x6adcf000 for 41480KB
Region 7: type 1 at 0x6d651000 for 324KB
Region 8: type 4 at 0x6d6a2000 for 160KB
Region 9: type 2 at 0x6d6ca000 for 3916KB
Region 10: type 1 at 0x6da9d000 for 10388KB
Region 11: type 2 at 0x6e4c2000 for 688KB
Region 12: type 1 at 0x6e56e000 for 6728KB
Region 13: type 1 at 0x1 for 6291456KB
Region 14: type 2 at 0x1000 for 34116KB
Region 15: type 2 at 0x6ec0 for 282624KB
Region 16: type 2 at 0xd000 for 16384KB
Region 17: type 2 at 0xd3709000 for 4KB
Region 18: type 2 at 0xe000 for 262144KB
Region 19: type 2 at 0xfe042000 for 12KB
Region 20: type 2 at 0xfe90 for 12KB
Region 21: type 2 at 0xfec0 for 4KB
Region 22: type 2 at 0xfed01000 for 4KB
Region 23: type 2 at 0xfee0 for 4KB
Region 24: type 2 at 0xff00 for 16384KB
Low ram: 1024KB High ram: 295236KB
With the patch, kernel is loaded in region 14 and it fits there.
Without patch, memory is allocated down from 0x1, and large kernel
overlaps with something and fails to boot.
There were reports on -misc that the patch does not help on some systems.
I wonder what can be tried differently to make it work on all systems?
Thanks,
Kastus
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi,
In my case replacing bootx64.efi with new one compiled with
aforementioned patch took off.
ODROID-H2 could boot kernel from latest snapshot.
Part of dmesg:
boot> boot bsd
booting hd0a:bsd: 14464328+3175440+344096+0+872448
[963989+128+1137408+860372]=0x14d15f0
entry point at 0x1001000
[ using 2962928 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.7-current (GENERIC.MP) #336: Tue Jul 7 22:27:36 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8385654784 (7997MB)
avail mem = 8116477952 (7740MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x79856000 (60 entries)
bios0: vendor American Megatrends Inc. version "5.13" date 04/27/2020
bios0: HARDKERNEL ODROID-H2
...
thanks Kastus
On 07.07.2020 20:55, Sven Wolf wrote:
Hi guys,
with the patch the kernel loads and doesn't stop at "entry point at
0x1001000". But the kernel stops with a "Stopped at
gfx_v9_0_wait_reg_mem+0x307: int $3"
So for my machine the patch is the right direction but not the
solution :( I've tried the boot with the current snapshot kernel.
Thanks and best regards,
Sven
On 7/6/20 6:32 AM, Kastus Shchuka wrote:
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
Kastus Shchuka wrote:
“I installed 2020-07-03 snapshot on ASRock J4105M system and I am
not able to boot it.
Boot stops at the line
entry point at 0x1001000
If I try bsd.rd kernel, it boots just fine. After this failure with
snapshot I
installed 6.7-release, and it boots without any issues.”
I've experienced something similar, including the sensitivity to
kernel size. As best I can observe, the EFI bootloader is being
handed a different block of RAM than where the kernel is actually
loaded (which is at a fixed address defined in boot.c). Which block
of memory gets returned, and whether boot fails, seems to be
dependent on the particular UEFI ROM/chipset. In my case, debugging
over serial, I observe a page fault while the kernel is still being
loaded into RAM.
“Are there any other solutions than compiling a custom smaller kernel?”
Patching efiboot.c as follows and recompiling bootia32/bootx64
resolved it for me:
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -303,9 +303,9 @@ efi_memprobe(void)
bios_memmap_t *bm;
EFI_STATUS status;
EFI_PHYSICAL_ADDRESS
- addr = 0x1000ULL; /* Below 256MB */
+ addr = 0x100;
- status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
EfiLoaderData,
+ status = EFI_CALL(BS->AllocatePages, AllocateAddress,
EfiLoaderData,
EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
if (status != EFI_SUCCESS)
panic("BS->AllocatePages()");
Let me know if that helps. I can't guarantee that this is actually
what is causing your issue but it worked for me.
I tried this patch and was able to boot kernel from snapshot
2007-07-03 with recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M
motherboard.
I wonder what would it take for the patch to be accepted in -current?
Thanks,
Kastus
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi guys,
with the patch the kernel loads and doesn't stop at "entry point at
0x1001000". But the kernel stops with a "Stopped at
gfx_v9_0_wait_reg_mem+0x307: int $3"
So for my machine the patch is the right direction but not the solution
:( I've tried the boot with the current snapshot kernel.
Thanks and best regards,
Sven
On 7/6/20 6:32 AM, Kastus Shchuka wrote:
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
Kastus Shchuka wrote:
“I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to
boot it.
Boot stops at the line
entry point at 0x1001000
If I try bsd.rd kernel, it boots just fine. After this failure with snapshot I
installed 6.7-release, and it boots without any issues.”
I've experienced something similar, including the sensitivity to kernel size.
As best I can observe, the EFI bootloader is being handed a different block of
RAM than where the kernel is actually loaded (which is at a fixed address
defined in boot.c). Which block of memory gets returned, and whether boot
fails, seems to be dependent on the particular UEFI ROM/chipset. In my case,
debugging over serial, I observe a page fault while the kernel is still being
loaded into RAM.
“Are there any other solutions than compiling a custom smaller kernel?”
Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it for
me:
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -303,9 +303,9 @@ efi_memprobe(void)
bios_memmap_t *bm;
EFI_STATUS status;
EFI_PHYSICAL_ADDRESS
-addr = 0x1000ULL; /* Below 256MB */
+addr = 0x100;
- status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData,
+ status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
if (status != EFI_SUCCESS)
panic("BS->AllocatePages()");
Let me know if that helps. I can't guarantee that this is actually what is
causing your issue but it worked for me.
I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
I wonder what would it take for the patch to be accepted in -current?
Thanks,
Kastus
Re: snapshot boot fails with error "entry point at 0x1001000"
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> Kastus Shchuka wrote:
> “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to
> boot it.
> Boot stops at the line
>
> entry point at 0x1001000
>
> If I try bsd.rd kernel, it boots just fine. After this failure with snapshot
> I
> installed 6.7-release, and it boots without any issues.”
>
>
> I've experienced something similar, including the sensitivity to kernel size.
> As best I can observe, the EFI bootloader is being handed a different block
> of RAM than where the kernel is actually loaded (which is at a fixed address
> defined in boot.c). Which block of memory gets returned, and whether boot
> fails, seems to be dependent on the particular UEFI ROM/chipset. In my case,
> debugging over serial, I observe a page fault while the kernel is still being
> loaded into RAM.
> “Are there any other solutions than compiling a custom smaller kernel?”
>
>
> Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it
> for me:
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -303,9 +303,9 @@ efi_memprobe(void)
> bios_memmap_t *bm;
> EFI_STATUS status;
> EFI_PHYSICAL_ADDRESS
> -addr = 0x1000ULL; /* Below 256MB */
> +addr = 0x100;
>
> - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> EfiLoaderData,
> + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> if (status != EFI_SUCCESS)
> panic("BS->AllocatePages()");
> Let me know if that helps. I can't guarantee that this is actually what is
> causing your issue but it worked for me.
I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
I wonder what would it take for the patch to be accepted in -current?
Thanks,
Kastus
snapshot boot fails with error "entry point at 0x1001000"
Hi, I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to boot it. Boot stops at the line entry point at 0x1001000 If I try bsd.rd kernel, it boots just fine. After this failure with snapshot I installed 6.7-release, and it boots without any issues. I suspect I am hitting the same problem as in https://marc.info/?l=openbsd-misc=159325874410286=2. Disk is partitioned with GPT, and system boots through EFI. There were other reports about BOOTX86.EFI supposedely causing this problem, as in https://marc.info/?l=openbsd-misc=159147446008114=2. I tried to boot snapshot kernel on 6.7-release system to make use of older BOOTX86.EFI, but it stopped at the same line "entry point at 0x1001000" I could be wrong, but I doubt that efi is the problem. It seems that kernel size is. If kernel is smaller than 20MB, it boots. If it is larger, it doesn't. Are there any other solutions than compiling a custom smaller kernel? I cannot produce dmesg from snapshot, but here is dmesg from 6.7-release: OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8201129984 (7821MB) avail mem = 7939952640 (7572MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6d946000 (18 entries) bios0: vendor American Megatrends Inc. version "P1.30" date 05/04/2018 bios0: ASRock J4105M acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BGRT WDAT WSMT acpi0: wakeup devices SIO1(S3) PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1496.53 MHz, 06-7a-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.87 MHz, 06-7a-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP03) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP05) acpiprt4 at acpi0: bus 4 (RP06) acpiec0 at acpi0: not present acpipwrres0 at acpi0: DRST
