Re: libc getaddrinfo() bug

[Kyle Amon]

On Wed, 16 Dec 2015 11:10:58 -0800
Serguey Parkhomovsky  wrote:

> On Tue, Dec 15, 2015 at 01:08:22AM -0800, am...@backwatcher.com wrote:
> > >Synopsis:  getaddrinfo() fails 32bit decimal IP addresses (i.e. no octets)
> > >Category:  library
> > >Environment:
> > System  : OpenBSD 5.8
> > Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > Please reference NetBSD PR #50552 for a thorough description.
> > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50552
> > >How-To-Repeat:
> > OpenBSD doesn't have the getaddrinfo(1) utility (see above referenced
> > NetBSD PR), so it's a little less easy to exhibit the issue on OpenBSD,
> > but basically just pass a 32bit decimal IP address (e.g. 1755800511) to
> > getaddrinfo(3) via any expeditions means.
> > >Fix:
> > The fix is well covered in the foregoing reference.
> > 
> 
> This seems to have been fixed in -current. Verified by running:
> 
>   openbsd:~ sparkhom$ getent hosts 1755800511
>   104.167.99.19   11755800511

Cool, but it should be 104.167.99.191.  Maybe a cut and paste omission?

-- 
US 727-510-2772   http://backwatcher.com

GPG F36E1CAB / CF001165F36E1CAB
6050 05B7 9FF1 CC21 3F00  CEBB CF00 1165 F36E 1CAB

OTR 1B8CA85B 9696C3E0 CDE79B77 52D5F7E6 5492DBE2 : jabber/backwatcher.org
5CF381C0 5F74307B 082E63E9 9EC509FA 85486180 : jabber/riseup.net
3614B012 C81F85FD 71FC48A4 75D88B91 A0203B51 : jabber/jabber.ru
DC446975 0D1CC62D 092E633C 2E3D3D82 B4CE1C47 : freenode
B4B825A3 086F0716 2CA55061 A0F521EB 54C0AB2F : oftc
744D942C D581087C ADDB11D2 E8E9FF59 B46481F3 : efnet
4443188D 5CA26B63 6327F9CD 3349C795 7743110D : facebook
4FB85A74 B2E1BBE3 20CD282E 8E8DD9B3 30EDAAC3 : google
B0C46C9E DD3685C8 81182D51 B2D14BE9 A43CFE09 : icq
41D60F67 7441ACFF 32CC2BF7 4EE70B17 08DA044F : aim
30CD13B4 A25DAC7A 863F638A 9EE95FBB 15D320A9 : yahoo
9FE919C7 7FD23FCB 5FF12636 A1F571B9 104AE5C1 : skype



pgp8W4qUdVtJP.pgp
Description: OpenPGP digital signature

Re: ntpd crashes at startup with constraints when an ipv6 is configured

[Dimitris Papastamos]

On Wed, Dec 16, 2015 at 09:01:20AM +, Dimitris Papastamos wrote:
> Hi,
> 
> I see the same problem on my router.  I also lost IPv6 functionality.
> I am using a tunnel through Hurricane Electric.  If I tcpdump on the
> external interface and ping6 an external host, I can see the
> encapsulated echo requests reaching the tunnel but no replies are
> coming through.

Ignore the IPv6 issue, it was a problem on my end.  I do experience
the ntpd crash however.

Re: libc getaddrinfo() bug

[Serguey Parkhomovsky]

On Tue, Dec 15, 2015 at 01:08:22AM -0800, am...@backwatcher.com wrote:
> >Synopsis:getaddrinfo() fails 32bit decimal IP addresses (i.e. no octets)
> >Category:library
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> Please reference NetBSD PR #50552 for a thorough description.
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50552
> >How-To-Repeat:
> OpenBSD doesn't have the getaddrinfo(1) utility (see above referenced
> NetBSD PR), so it's a little less easy to exhibit the issue on OpenBSD,
> but basically just pass a 32bit decimal IP address (e.g. 1755800511) to
> getaddrinfo(3) via any expeditions means.
> >Fix:
> The fix is well covered in the foregoing reference.
> 

This seems to have been fixed in -current. Verified by running:

openbsd:~ sparkhom$ getent hosts 1755800511
104.167.99.19   11755800511

Re: libc getaddrinfo() bug

[Serguey Parkhomovsky]

On Wed, Dec 16, 2015 at 04:17:53PM -0500, Ted Unangst wrote:
> > 
> > This seems to have been fixed in -current. Verified by running:
> > 
> > openbsd:~ sparkhom$ getent hosts 1755800511
> > 104.167.99.19   11755800511
> 
> that doesn't call getaddrinfo().

Are you sure? In hostsaddrinfo():

if (getaddrinfo(name, NULL, , ) == 0) {

Which gets called in hosts() after both inet_pton calls return 0:

if (inet_pton(AF_INET6, argv[i], (void *)addr) > 0)
he = gethostbyaddr(addr, IN6ADDRSZ, AF_INET6);
else if (inet_pton(AF_INET, argv[i], (void *)addr) > 0)
he = gethostbyaddr(addr, INADDRSZ, AF_INET);
if (he != NULL)
hostsprint(he);
else if ((rv = hostsaddrinfo(argv[i])) == RV_NOTFOUND)
break; 

5.7 Digi serial Neo-8 PCIe dropping characters - revisited

[Martin van den Nieuwelaar]

Hi everyone,

I'd like to follow up a post I made to bugs last year entitled "5.4 with 
Digi serial board drops characters (silo overflow)".  Link 
http://openbsd-archive.7691.n7.nabble.com/5-4-with-Digi-serial-board-drops-characters-silo-overflow-td244124.html


I have since had a chance to re-visit the issue under OpenBSD 5.7 (I 
suspect 5.8 still has the same issue) and made some progress wrt what's 
going on.  It would appear that it's simply a matter of the serial FIFO 
buffer length being zero when it should be much larger. Here is a 
snippet of relevant dmesg output:


com4 at puc0 port 0 apic 8 int 16: ns16550a, 16 byte fifo
com4: probed fifo depth: 0 bytes

Now there are a number of problems as I see it.  The first line shows a 
16550a and a 16 byte FIFO.  The Digi we are using is the 8 port Neo 
PCIe.  It claims to be 16C850 compatible from which we can infer a 128 
byte FIFO.  So first thing is the correct chip isn't being detected.  
Still, I'm guessing the Digi chip is 16550a backwards compatible so in 
any case this should still work.


The second line shows the probed FIFO depth being zero.  Looking through 
the kernel code (/usr/src/sys/dev/ic/com.c - I'm actually looking at 5.7 
but from a quick look it appears that 5.8 might be identical) if the 
probed depth (zero) is less than the 16 byte above value the shorter of 
the two is used, ie. zero.


/* For safety, always use the smaller value. */
if (sc->sc_fifolen > len) {
printf("%s: probed fifo depth: %d bytes\n",
sc->sc_dev.dv_xname, len);
sc->sc_fifolen = len;
}

A 'zero' FIFO explains why I'm getting dropped characters when I run a 
couple of ports up at speeds of 19k2 or more.


Looking through the com.c file there is mention of the 16850 chip, but 
that code appears to be commented out with the comment /* until com 
works with large FIFOs */  Hmm...  Google shows the OpenBSD 2.3 release 
changes including "Add support for the XR16850 serial chip (128 byte 
fifos)".  So I guess something has happened between OpenBSD 2.3 and 
OpenBSD 5.7 to warrant its removal.


Assuming for now that we can make do with just 16 byte FIFOs I thought 
I'd try a hack to see if I could get it to work.  Here is my hack:


/* For safety, always use the smaller value. */
if (sc->sc_fifolen > len) {
printf("%s: probed fifo depth: %d bytes\n",
sc->sc_dev.dv_xname, len);

/* MJV modification 17-Dec-2015 */
/* Probe doesn't work on Digi Neo 8 PCIe so */
/* don't rely on it */

if (len == 0)
printf("%s: override, using %d byte FIFO\n",
sc->sc_dev.dv_xname, sc->sc_fifolen);
else
sc->sc_fifolen = len;
}

Well I tried it out and it works; no more missing serial characters.  
Unfortunately this code change is a real hack and would potentially mess 
up your system if you had other serial boards that don't have a FIFO 
(but are somehow detected as having a FIFO).


I would think a better fix would be to fix the 16850 sections (and make 
large FIFOs work???) but this sounds like a potential can of worms 
otherwise I would have tried it.


So maybe this hack is useful to anyone out there with the same Digi 
Neo-8 PCIe card and who is also having problems with dropped characters.


If anyone is maintaining the serial code, and wishes to fix it properly 
I'm happy to test out the changes on the card here.


Also thoughts for a more elegant hack would be welcome.

Regards,

-Martin


--
R A Ward Ltd. | We take the privacy of our customers seriously.
Christchurch  | All sensitive E-Mail attachments MUST be encrypted.
New Zealand

Re: screen brightness resets

[Ted Unangst]

Mark Kettenis wrote:
> > From: "Ted Unangst" 
> > Date: Wed, 09 Dec 2015 06:49:42 -0500
> > 
> > Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not 
> > sure
> > when it was introduced. I have lidsuspend=0. When I close the lid and open 
> > it
> > again, the screen comes back at 100% brightness. As in, far too bright.
> > 
> > Previously, the screen would always open back up at the same brightness 
> > level
> > I closed it at. kettenis mentioned that the keyboard brightness keys work
> > (they do) but that's a recent addition. For many months, they did not. I
> > wonder if the changes are correlated.
> 
> They probably are.  And probably the weird behaviour of the brightness
> keys is related as well.  See my rants about ACPI being fucked because
> we claim to support both Windows 7 and Windows 8.  My suggestion would
> be to comment out most of the Windows versions in the "aml_valid_osi"
> array and see how the behaviour changes if you only enable the
> "Windows 2012", "Windows 2009" or "Windows 2006" entry.

It took a while to get around to it, but I'm now running with the diff below
and things seem much more sensible. The brightness controls still work, but
things don't reset every time I add or remove power.


Index: acpi/dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.218
diff -u -p -r1.218 dsdt.c
--- acpi/dsdt.c 20 Aug 2015 20:50:10 -  1.218
+++ acpi/dsdt.c 9 Dec 2015 14:06:50 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: dsdt.c,v 1.218 2015/08/20 20:50:10 kettenis Exp $ */
+/* $OpenBSD: dsdt.c,v 1.217 2015/05/04 10:42:06 jmatthew Exp $ */
 /*
  * Copyright (c) 2005 Jordan Hargrave 
  *
@@ -1476,18 +1476,7 @@ struct aml_defval {
  * We return True for Windows to fake out nasty bad AML
  */
 char *aml_valid_osi[] = {
-   "Windows 2000",
-   "Windows 2001",
-   "Windows 2001.1",
-   "Windows 2001 SP0",
-   "Windows 2001 SP1",
-   "Windows 2001 SP2",
-   "Windows 2001 SP3",
-   "Windows 2001 SP4",
-   "Windows 2006",
"Windows 2009",
-   "Windows 2012",
-   "Windows 2013",
NULL
 };
 

Re: screen brightness resets

[Remi Locherer]

On Wed, Dec 16, 2015 at 09:32:14PM -0500, Ted Unangst wrote:
> Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Wed, 09 Dec 2015 06:49:42 -0500
> > > 
> > > Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not 
> > > sure
> > > when it was introduced. I have lidsuspend=0. When I close the lid and 
> > > open it
> > > again, the screen comes back at 100% brightness. As in, far too bright.
> > > 
> > > Previously, the screen would always open back up at the same brightness 
> > > level
> > > I closed it at. kettenis mentioned that the keyboard brightness keys work
> > > (they do) but that's a recent addition. For many months, they did not. I
> > > wonder if the changes are correlated.
> > 
> > They probably are.  And probably the weird behaviour of the brightness
> > keys is related as well.  See my rants about ACPI being fucked because
> > we claim to support both Windows 7 and Windows 8.  My suggestion would
> > be to comment out most of the Windows versions in the "aml_valid_osi"
> > array and see how the behaviour changes if you only enable the
> > "Windows 2012", "Windows 2009" or "Windows 2006" entry.
> 
> It took a while to get around to it, but I'm now running with the diff below
> and things seem much more sensible. The brightness controls still work, but
> things don't reset every time I add or remove power.
> 
> 
> Index: acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.218
> diff -u -p -r1.218 dsdt.c
> --- acpi/dsdt.c   20 Aug 2015 20:50:10 -  1.218
> +++ acpi/dsdt.c   9 Dec 2015 14:06:50 -
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: dsdt.c,v 1.218 2015/08/20 20:50:10 kettenis Exp $ */
> +/* $OpenBSD: dsdt.c,v 1.217 2015/05/04 10:42:06 jmatthew Exp $ */
>  /*
>   * Copyright (c) 2005 Jordan Hargrave 
>   *
> @@ -1476,18 +1476,7 @@ struct aml_defval {
>   * We return True for Windows to fake out nasty bad AML
>   */
>  char *aml_valid_osi[] = {
> - "Windows 2000",
> - "Windows 2001",
> - "Windows 2001.1",
> - "Windows 2001 SP0",
> - "Windows 2001 SP1",
> - "Windows 2001 SP2",
> - "Windows 2001 SP3",
> - "Windows 2001 SP4",
> - "Windows 2006",
>   "Windows 2009",
> - "Windows 2012",
> - "Windows 2013",
>   NULL
>  };
>  

With this patch the brightnes keys on Dell XPS 13 9343 work. Also
audio works with this patch.

Before I had a different patch applied to make audio work on this notebook.
See https://marc.info/?l=openbsd-misc=144277570223298=2

Remi


OpenBSD 5.8-current (GENERIC.MP) #18: Thu Dec 17 07:49:38 CET 2015
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8168812544 (7790MB)
avail mem = 7917084672 (7550MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
bios0: vendor Dell Inc. version "A07" date 11/11/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT 
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(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) i5-5200U CPU @ 2.20GHz, 2494.61 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,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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) i5-5200U CPU @ 2.20GHz, 2494.23 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,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,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) i5-5200U CPU @ 2.20GHz, 2494.23 MHz
cpu2: 

Re: syslogd: no --MARK-- when started with -m and mark.info enabled in syslog.conf

[Alexander Bluhm]

On Fri, Dec 11, 2015 at 12:37:40AM +0100, Einfach Jemand wrote:
> Below is a patch against the -current version of syslogd.c that makes 
> syslogd -m functional again.

Thanks for the fix, I have commited it.

> I ran the regression tests for syslogd with the patch and found no 
> differences so far to an unpatched syslogd.

Unfortunately I cannot write a test for the mark feature.  The
minimum timeout is 1 minute and that would be too long for a fast
regress run.

bluhm

ntpd crashes at startup with constraints when an ipv6 is configured

[Landry Breuil]

Hi,

i have an ipv6 configured on my external if, and with this config:

listen on 10.246.200.1
servers pool.ntp.org
sensor *
constraints from "https://www.google.com;

i get an ipv6 resolution for www.google.com
$host www.google.com
www.google.com has address 216.58.208.228
www.google.com has IPv6 address 2a00:1450:4007:80e::2004

but no ping for it (dont ask me why):
$ping6 www.google.com
PING6 www.google.com (2a00:1450:4007:80e::2004): 24 data bytes
^C--- www.google.com ping6 statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss

and ntpd crashes at startup (-current, macppc)

ntpd[1932]: listening on 10.246.200.1 
ntpd[1932]: ntp engine ready
ntpd[1932]: constraint reply from 216.58.208.228: offset -0.413616
ntpd[16978]: fatal: constraint 2a00:1450:4007:80e::2004, signal 15
ntpd[1932]: ntp_dispatch_imsg in ntp engine: pipe closed
ntpd[1932]: ntp_dispatch_imsg_dns in ntp engine: pipe closed
ntpd[1932]: ntp engine exiting

Of course if i disable the constraints, it starts fine.

ntpd[4086]: listening on 10.246.200.1 
ntpd[4086]: ntp engine ready
ntpd[4086]: peer 78.192.65.63 now valid
ntpd[4086]: peer 178.33.227.201 now valid
ntpd[4086]: peer 176.31.127.215 now valid
ntpd[4086]: peer 212.83.131.33 now valid

I dunno what ntpd should do in that case, but it shouldnt crash..

Landry

Re: ntpd crashes at startup with constraints when an ipv6 is configured

[Dimitris Papastamos]

Hi,

I see the same problem on my router.  I also lost IPv6 functionality.
I am using a tunnel through Hurricane Electric.  If I tcpdump on the
external interface and ping6 an external host, I can see the
encapsulated echo requests reaching the tunnel but no replies are
coming through.

I am sure the code from the 6th of December was working fine.  I think
maybe the code from the 13th of December was working as well.

Let me know if you need more information.

OpenBSD 5.8-current (GENERIC.MP) #75: Sun Dec  6 12:46:21 GMT 2015
r...@sun.2f30.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7450062848 (7104MB)
avail mem = 7220146176 (6885MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec1e0 (76 entries)
bios0: vendor American Megatrends Inc. version "1.03" date 06/18/2014
bios0: Shuttle Inc. XH81V
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC SSDT SSDT MCFG HPET SSDT SSDT
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) 
PXSX(S4) RP08(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) i3-4360 CPU @ 3.70GHz, 3691.91 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, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.45 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) i3-4360 CPU @ 3.70GHz, 3691.45 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) i3-4360 CPU @ 3.70GHz, 3691.45 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 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP03)
acpiprt3 at acpi0: bus 3 (RP04)
acpiprt4 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3691 MHz: speeds: 3700, 3500, 3300, 3100, 2900, 2700, 
2500, 2300, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
drm0 at inteldrm0
inteldrm0: