Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Mike Larkin]

On Sat, Feb 20, 2016 at 10:42:02PM +0100, Mark Kettenis wrote:
> > Date: Sat, 20 Feb 2016 11:32:15 -0800
> > From: Mike Larkin 
> > 
> > On Sat, Feb 20, 2016 at 10:04:28AM +0100, Mark Kettenis wrote:
> > > > From: Noth 
> > > > Date: Sat, 20 Feb 2016 07:22:56 +0100
> > > > 
> > > > On 02/20/16 06:46, Theo de Raadt wrote:
> > > > >> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> > > > >> immediately.  I have a diff to avoid this wakeup.  Unhibernation 
> > > > >> works
> > > > >> fine.
> > > > >>
> > > > >> The diff seems very bad. :)
> > > > >>
> > > > >> Index: sys/dev/acpi/acpi.c
> > > > >> ===
> > > > >> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> > > > >> retrieving revision 1.303
> > > > >> diff -u -p -r1.303 acpi.c
> > > > >> --- sys/dev/acpi/acpi.c  14 Jan 2016 21:37:18 -  1.303
> > > > >> +++ sys/dev/acpi/acpi.c  21 Jan 2016 08:25:59 -
> > > > >> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
> > > > >>   {
> > > > >>  struct acpi_wakeq *wentry;
> > > > >>   
> > > > >> +return;
> > > > >>  SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
> > > > >>  dnprintf(10, "%.4s(S%d) gpe %.2x\n", 
> > > > >> wentry->q_node->name,
> > > > >>  wentry->q_state,
> > > > > That is a very interesting diff.  Mike will probably remember this.
> > > > > Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
> > > > > was doing something wrong.
> > > > >
> > > > > That will assuredly break most thinkpads :)
> > > > >
> > > > >
> > > > 
> > > > That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
> > > > pretty well on this little laptop :)
> > > 
> > > Next step in the debugging process would be to find out which of the
> > > wake GPEs is actually responsible.
> > > 
> > 
> > I have a few reports of these sorts of things failing (eg, resuming
> > immediately) in my inbox from the past. Every time I've tried to
> > debug these, even when disabling all the GPEs, the machine still
> > woke.
> > 
> > Do you have a better idea?
> 
> In this case disabling the GPEs definitely does help.

Cleaning up old email threads ...

So the next step is to hack up that diff to selectively disable GPEs until
you find the one that is causing the instant wake. It's a simple matter 
(usually)
to then find the device responsible, at which point we can make further 
progress.

Short of having physical access to the hardware, this is all I can recommend.

-ml

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

On 02/20/16 22:42, Mark Kettenis wrote:

Date: Sat, 20 Feb 2016 11:32:15 -0800
From: Mike Larkin 

On Sat, Feb 20, 2016 at 10:04:28AM +0100, Mark Kettenis wrote:

From: Noth 
Date: Sat, 20 Feb 2016 07:22:56 +0100

On 02/20/16 06:46, Theo de Raadt wrote:

I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
immediately.  I have a diff to avoid this wakeup.  Unhibernation works
fine.

The diff seems very bad. :)

Index: sys/dev/acpi/acpi.c
===
RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.303
diff -u -p -r1.303 acpi.c
--- sys/dev/acpi/acpi.c 14 Jan 2016 21:37:18 -  1.303
+++ sys/dev/acpi/acpi.c 21 Jan 2016 08:25:59 -
@@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
   {
struct acpi_wakeq *wentry;
   
+return;

SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
wentry->q_state,

That is a very interesting diff.  Mike will probably remember this.
Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
was doing something wrong.

That will assuredly break most thinkpads :)



That patch works for me, thank you Masahiko. Looks like OpenBSD runs
pretty well on this little laptop :)

Next step in the debugging process would be to find out which of the
wake GPEs is actually responsible.


I have a few reports of these sorts of things failing (eg, resuming
immediately) in my inbox from the past. Every time I've tried to
debug these, even when disabling all the GPEs, the machine still
woke.

Do you have a better idea?

In this case disabling the GPEs definitely does help.

Well is their anything further I can do to help the debugging ? I did 
notice the processors were running close to 100% system after a wake up 
when using the patch from Yasuoka. Remember if I disable xhci using UKC 
suspend works anyway.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Mark Kettenis]

> Date: Sat, 20 Feb 2016 11:32:15 -0800
> From: Mike Larkin 
> 
> On Sat, Feb 20, 2016 at 10:04:28AM +0100, Mark Kettenis wrote:
> > > From: Noth 
> > > Date: Sat, 20 Feb 2016 07:22:56 +0100
> > > 
> > > On 02/20/16 06:46, Theo de Raadt wrote:
> > > >> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> > > >> immediately.  I have a diff to avoid this wakeup.  Unhibernation works
> > > >> fine.
> > > >>
> > > >> The diff seems very bad. :)
> > > >>
> > > >> Index: sys/dev/acpi/acpi.c
> > > >> ===
> > > >> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> > > >> retrieving revision 1.303
> > > >> diff -u -p -r1.303 acpi.c
> > > >> --- sys/dev/acpi/acpi.c14 Jan 2016 21:37:18 -  1.303
> > > >> +++ sys/dev/acpi/acpi.c21 Jan 2016 08:25:59 -
> > > >> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
> > > >>   {
> > > >>struct acpi_wakeq *wentry;
> > > >>   
> > > >> +return;
> > > >>SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
> > > >>dnprintf(10, "%.4s(S%d) gpe %.2x\n", 
> > > >> wentry->q_node->name,
> > > >>wentry->q_state,
> > > > That is a very interesting diff.  Mike will probably remember this.
> > > > Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
> > > > was doing something wrong.
> > > >
> > > > That will assuredly break most thinkpads :)
> > > >
> > > >
> > > 
> > > That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
> > > pretty well on this little laptop :)
> > 
> > Next step in the debugging process would be to find out which of the
> > wake GPEs is actually responsible.
> > 
> 
> I have a few reports of these sorts of things failing (eg, resuming
> immediately) in my inbox from the past. Every time I've tried to
> debug these, even when disabling all the GPEs, the machine still
> woke.
> 
> Do you have a better idea?

In this case disabling the GPEs definitely does help.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Mike Larkin]

On Fri, Feb 19, 2016 at 10:46:30PM -0700, Theo de Raadt wrote:
> > I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> > immediately.  I have a diff to avoid this wakeup.  Unhibernation works
> > fine.
> > 
> > The diff seems very bad. :)
> > 
> > Index: sys/dev/acpi/acpi.c
> > ===
> > RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> > retrieving revision 1.303
> > diff -u -p -r1.303 acpi.c
> > --- sys/dev/acpi/acpi.c 14 Jan 2016 21:37:18 -  1.303
> > +++ sys/dev/acpi/acpi.c 21 Jan 2016 08:25:59 -
> > @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
> >  {
> > struct acpi_wakeq *wentry;
> >  
> > +return;
> > SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
> > dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
> > wentry->q_state,
> 
> That is a very interesting diff.  Mike will probably remember this.
> Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
> was doing something wrong.
> 

sebastia@'s problem was on a Fujitsu Siemens laptop where the GPE fired
continually, causing 100% cpu load and 15 minute boots. Probably unrelated.

At least this is what I recall from the Berlin mini hackathon.


> That will assuredly break most thinkpads :)
> 
> 

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Mike Larkin]

On Sat, Feb 20, 2016 at 10:04:28AM +0100, Mark Kettenis wrote:
> > From: Noth 
> > Date: Sat, 20 Feb 2016 07:22:56 +0100
> > 
> > On 02/20/16 06:46, Theo de Raadt wrote:
> > >> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> > >> immediately.  I have a diff to avoid this wakeup.  Unhibernation works
> > >> fine.
> > >>
> > >> The diff seems very bad. :)
> > >>
> > >> Index: sys/dev/acpi/acpi.c
> > >> ===
> > >> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> > >> retrieving revision 1.303
> > >> diff -u -p -r1.303 acpi.c
> > >> --- sys/dev/acpi/acpi.c  14 Jan 2016 21:37:18 -  1.303
> > >> +++ sys/dev/acpi/acpi.c  21 Jan 2016 08:25:59 -
> > >> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
> > >>   {
> > >>  struct acpi_wakeq *wentry;
> > >>   
> > >> +return;
> > >>  SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
> > >>  dnprintf(10, "%.4s(S%d) gpe %.2x\n", 
> > >> wentry->q_node->name,
> > >>  wentry->q_state,
> > > That is a very interesting diff.  Mike will probably remember this.
> > > Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
> > > was doing something wrong.
> > >
> > > That will assuredly break most thinkpads :)
> > >
> > >
> > 
> > That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
> > pretty well on this little laptop :)
> 
> Next step in the debugging process would be to find out which of the
> wake GPEs is actually responsible.
> 

I have a few reports of these sorts of things failing (eg, resuming immediately)
in my inbox from the past. Every time I've tried to debug these, even when 
disabling
all the GPEs, the machine still woke.

Do you have a better idea?

-ml

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Mark Kettenis]

> From: Noth 
> Date: Sat, 20 Feb 2016 07:22:56 +0100
> 
> On 02/20/16 06:46, Theo de Raadt wrote:
> >> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> >> immediately.  I have a diff to avoid this wakeup.  Unhibernation works
> >> fine.
> >>
> >> The diff seems very bad. :)
> >>
> >> Index: sys/dev/acpi/acpi.c
> >> ===
> >> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> >> retrieving revision 1.303
> >> diff -u -p -r1.303 acpi.c
> >> --- sys/dev/acpi/acpi.c14 Jan 2016 21:37:18 -  1.303
> >> +++ sys/dev/acpi/acpi.c21 Jan 2016 08:25:59 -
> >> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
> >>   {
> >>struct acpi_wakeq *wentry;
> >>   
> >> +return;
> >>SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
> >>dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
> >>wentry->q_state,
> > That is a very interesting diff.  Mike will probably remember this.
> > Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
> > was doing something wrong.
> >
> > That will assuredly break most thinkpads :)
> >
> >
> 
> That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
> pretty well on this little laptop :)

Next step in the debugging process would be to find out which of the
wake GPEs is actually responsible.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

On 02/20/16 06:46, Theo de Raadt wrote:

I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
immediately.  I have a diff to avoid this wakeup.  Unhibernation works
fine.

The diff seems very bad. :)

Index: sys/dev/acpi/acpi.c
===
RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.303
diff -u -p -r1.303 acpi.c
--- sys/dev/acpi/acpi.c 14 Jan 2016 21:37:18 -  1.303
+++ sys/dev/acpi/acpi.c 21 Jan 2016 08:25:59 -
@@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
  {
struct acpi_wakeq *wentry;
  
+return;

SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
wentry->q_state,

That is a very interesting diff.  Mike will probably remember this.
Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
was doing something wrong.

That will assuredly break most thinkpads :)




That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
pretty well on this little laptop :)

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Theo de Raadt]

> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> immediately.  I have a diff to avoid this wakeup.  Unhibernation works
> fine.
> 
> The diff seems very bad. :)
> 
> Index: sys/dev/acpi/acpi.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.303
> diff -u -p -r1.303 acpi.c
> --- sys/dev/acpi/acpi.c   14 Jan 2016 21:37:18 -  1.303
> +++ sys/dev/acpi/acpi.c   21 Jan 2016 08:25:59 -
> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
>  {
>   struct acpi_wakeq *wentry;
>  
> +return;
>   SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
>   dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
>   wentry->q_state,

That is a very interesting diff.  Mike will probably remember this.
Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
was doing something wrong.

That will assuredly break most thinkpads :)

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[YASUOKA Masahiko]

On Sat, 20 Feb 2016 04:17:05 +0100
Noth  wrote:
>   I installed -CURRENT on my laptop today, so far so good on the UEFI
>   boot, crypto disk and wifi with .11n. Unfortunately the suspend to ram
>   and hibernate options don't work... Suspend goes to suspend but wakes
>   back immediately and freezes, hibernate goes to a black screen and
>   freezes. I've got apmd running with -C.  I've included the acpidump
>   and hope it will help with any debugging.

I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
immediately.  I have a diff to avoid this wakeup.  Unhibernation works
fine.

The diff seems very bad. :)

Index: sys/dev/acpi/acpi.c
===
RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.303
diff -u -p -r1.303 acpi.c
--- sys/dev/acpi/acpi.c 14 Jan 2016 21:37:18 -  1.303
+++ sys/dev/acpi/acpi.c 21 Jan 2016 08:25:59 -
@@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
 {
struct acpi_wakeq *wentry;
 
+return;
SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
wentry->q_state,

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

Hello again

On 02/20/16 06:23, Jack J. Woehr wrote:

Theo de Raadt wrote:


That's not very helpful.
My apologies. If you follow the thread 
https://marc.info/?l=openbsd-misc=144761680226242=2 you'll see 
that I reported
a similar problem on my own VAIO and was given a workaround that 
amounted to the same answer I gave, except that I gave my
answer wittily, I thought at the time, and offhand after a 12-hour day 
of work.


Long live OpenBSD.



Ok, if I disable xhci in UKC, suspend works. Hibernate doesn't but then 
that doesn't matter too much to me. Thanks for the suggestion Theo!


Noth

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Jack J. Woehr]

Theo de Raadt wrote:


That's not very helpful.

My apologies. If you follow the thread 
https://marc.info/?l=openbsd-misc=144761680226242=2 you'll see that I 
reported
a similar problem on my own VAIO and was given a workaround that amounted to 
the same answer I gave, except that I gave my
answer wittily, I thought at the time, and offhand after a 12-hour day of work.

Long live OpenBSD.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Theo de Raadt]

> On Fri, Feb 19, 2016 at 09:41:59PM -0700, Jack J. Woehr wrote:
> > Noth wrote:
> > >Unfortunately the suspend to ram and hibernate options don't work
> > They don't. Proprietary undocumented hardware. "Doctor, it hurts when I do 
> > this." "Don't do that."
> 
> That's not very helpful.

Indeed, it is becoming quite depressing that some people who act like
our fan club can so quickly attack new users who submit good bug
reports in their very first email, for hardware they happen to have.
For hardware which we do struggle to support, if only we had such
reports on a regular basis.

Jack, consider taking a break from the list if that is your approach.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Bryan Steele]

On Fri, Feb 19, 2016 at 09:41:59PM -0700, Jack J. Woehr wrote:
> Noth wrote:
> >Unfortunately the suspend to ram and hibernate options don't work
> They don't. Proprietary undocumented hardware. "Doctor, it hurts when I do 
> this." "Don't do that."

That's not very helpful.

> Noth wrote:
> >Unfortunately the suspend to ram and hibernate options don't work

At least on some systems, disabling TPM and related security features in
the BIOS options may fix some suspend/hibernate issues.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Jack J. Woehr]

Noth wrote:

Unfortunately the suspend to ram and hibernate options don't work

They don't. Proprietary undocumented hardware. "Doctor, it hurts when I do this." 
"Don't do that."

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

Hi tech@

  I installed -CURRENT on my laptop today, so far so good on the UEFI 
boot, crypto disk and wifi with .11n. Unfortunately the suspend to ram 
and hibernate options don't work... Suspend goes to suspend but wakes 
back immediately and freezes, hibernate goes to a black screen and 
freezes. I've got apmd running with -C.  I've included the acpidump and 
hope it will help with any debugging.


Cheers,

Noth

OpenBSD 5.9 (GENERIC.MP) #1870: Mon Feb  8 17:34:23 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8475893760 (8083MB)
avail mem = 8214822912 (7834MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdbeb3018 (20 entries)
bios0: vendor American Megatrends Inc. version "R1044V7" date 03/24/2014
bios0: Sony Corporation SVP112190X
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT TCPA MSDM MCFG HPET SSDT SSDT PCCT 
SSDT SSDT SSDT SSDT SSDT SLIC ECDT BGRT SSDT
acpi0: wakeup devices PXSX(S4) RP05(S4) PXSX(S4) RP01(S4) PXSX(S4) 
RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) EHC1(S3) XHC_(S3) HDEF(S4) 
PWRB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2694.27 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu0: 256KB 64b/line 8-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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2693.77 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2693.77 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2693.77 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 97 degC
acpibat0 at acpi0: BAT0 type LiOn oem "Sony Corp."
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 2694 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 
1400, 1300, 1200, 1100, 1000, 900, 800 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0