bug installing OpenVPN

2016-02-08 Thread Феликс Фролов
OpenBSD 5.8 GENERIC.MP#1098 i386
easy-rsa-2.2.0p0
openssl-1.0.1pp1
openvpn-2.3.7

# ./build-ca
error on line 37 of /usr/local/share/easy-rsa/openssl.cnf
68958:error:0E065068:configuration file routines:STR_COPY:variable
has no 
value:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/conf/conf_def.c:573:line
37

-- 

Felix Frolov
+7 (965) 6600015
felix.fro...@gmail.com
EOF



Re: bug installing OpenVPN

2016-02-08 Thread Stuart Henderson
On 2016/02/08 15:29, Феликс Фролов wrote:
> OpenBSD 5.8 GENERIC.MP#1098 i386
> easy-rsa-2.2.0p0
> openssl-1.0.1pp1
> openvpn-2.3.7
> 
> # ./build-ca
> error on line 37 of /usr/local/share/easy-rsa/openssl.cnf
> 68958:error:0E065068:configuration file routines:STR_COPY:variable
> has no 
> value:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/conf/conf_def.c:573:line
> 37
> 
> -- 
> 
> Felix Frolov
> +7 (965) 6600015
> felix.fro...@gmail.com
> EOF
> 

Update easy-rsa from -stable ports. Assuming you have already got a copy
of the ports tree:

cd /usr/ports/security/easy-rsa
cvs up -r OPENBSD_5_8
make clean && make update

Or pre-built -stable packages are available from stable.mtier.org.



AM1 CPU temparature not detected correctly

2016-02-08 Thread hiroshi-n
>Synopsis:  "sysctl hw.sensros" shows (probably) incorrect values.
>Category:  kernel
>Environment:
System  : OpenBSD 5.8
Details : OpenBSD 5.8-stable (GENERIC.MP) #0: Mon Feb  8 21:06:34 
JST 2016
 
nakamoto@pivot.f0.borndigital:/data/usr/nakamoto/58/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
"sysctl hw.sensors" shows the values below, but km0 value is 
unexpectedly low.
hw.sensors.km0.temp0=14.62 degC
hw.sensors.lm1.temp0=41.00 degC
hw.sensors.lm1.temp1=43.50 degC
hw.sensors.lm1.temp2=51.00 degC

>How-To-Repeat:
sysctl hw.sensors
>Fix:
unknown


dmesg:
OpenBSD 5.8-stable (GENERIC.MP) #0: Mon Feb  8 21:06:34 JST 2016

nakamoto@pivot.f0.borndigital:/data/usr/nakamoto/58/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7968804864 (7599MB)
avail mem = 7723401216 (7365MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe60 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.00" date 02/19/2014
bios0: ASRock AM1H-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET AAFT SSDT SSDT CRAT SSDT SSDT
acpi0: wakeup devices PEB1(S4) GPP1(S4) LOM_(S4) GPP2(S4) GPP3(S4) SBAZ(S4) 
PS2K(S4) PS2M(S4) UAR1(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) 
EHC3(S4) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Sempron(tm) 3850 APU with Radeon(tm) R3, 1297.73 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Sempron(tm) 3850 APU with Radeon(tm) R3, 1297.57 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Sempron(tm) 3850 APU with Radeon(tm) R3, 1297.57 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Sempron(tm) 3850 APU with Radeon(tm) R3, 1297.57 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEB1)
acpiprt2 at acpi0: bus 2 (GPP0)
acpiprt3 at acpi0: bus 3 (GPP1)
acpiprt4 at acpi0: bus 4 (GPP2)
acpiprt5 at acpi0: bus -1 (GPP3)
acpicpu0 at acpi0: !C2(0@400 io@0x414), C1(@1 halt!), PSS
acpicpu1 at acpi0: !C2(0@400 io@0x414), C1(@1 halt!), PSS
acpicpu2 at acpi0: !C2(0@400 io@0x414), 

Re: alignment fault on armv7 when using carp(4)

2016-02-08 Thread David Gwynne
On Sat, Feb 06, 2016 at 04:43:28PM -0500, Anthony Eden wrote:
> >Synopsis:  
> >Category:  arm
> >Environment:
> System  : OpenBSD 5.9
> Details : OpenBSD 5.9 (DBGGENERIC) #0: Sat Feb  6 12:22:27 EST 2016
>  r...@beagle2.mit.edu:/usr/src/sys/arch/armv7/compile/DBGGENERIC
> 
> Architecture: OpenBSD.armv7
> Machine : armv7
> >Description:
> With two beaglebone black's running -current, an alignment fault is
> encountered at ip_input.c:262 in ipv4_input() when they are
> configured to use carp(4) to share the same IP address.
> 
> Source context from ip_input.c (alignment fault occurs when
> ip->ip_dst.s_addr is loaded at line 262):
> 
> 258:ip = mtod(m, struct ip *);
> 259:}
> 260:
> 261:/* 127/8 must not appear on wire - RFC1122 */
> 262:if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET 
> ||
> 263:   (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) {
> 264:if ((ifp->if_flags & IFF_LOOPBACK) == 0) {
> 265:ipstat.ips_badaddr++;
> 266:goto bad;
> 
> ddb(4) output:
> 
> $ Fatal kernel mode data abort: 'Alignment Fault 1'
> trapframe: 0xcb2d8e40
> DFSR=0001, DFAR=c4cb401e, spsr=8013
> r0 =c924d400, r1 =0003, r2 =0045, r3 =0038
> r4 =c4cb400e, r5 =c06f2ca4, r6 =0014, r7 =c4d65800
> r8 =c0710e50, r9 =c069294c, r10=c0692918, r11=cb2d8eb8
> r12=6093, ssp=cb2d8e8c, slr=c040bc88, pc =c04616ec
> 
> Stopped at  ipv4_input+0x9c:ldrls   r3, [r4, #0x010]
> ddb> trace
> ipv4_input+0xc
> scp=0xc046165c rlv=0xc0461ab4 (ipintr+0x24)
> rsp=0xcb2d8ebc rfp=0xcb2d8ecc
> r10=0xc0692918 r8=0xc0710e50 r7=0xc06edd88 r6=0xc06edd88
> r5=0x r4=0x0004
> ipintr+0xc
> scp=0xc0461a9c rlv=0xc041b290 (netintr+0xa0)
> rsp=0xcb2d8ed0 rfp=0xcb2d8ef0
> netintr+0xc
> scp=0xc041b1fc rlv=0xc053f3d0 (softintr_dispatch+0x84)
> rsp=0xcb2d8ef4 rfp=0xcb2d8f10
> r7=0x r6=0xc0710eb4 r5=0xc0710ec0 r4=0xc89e13a0
> softintr_dispatch+0x18
> scp=0xc053f364 rlv=0xc053eef8 (arm_do_pending_intr+0x110)
> rsp=0xcb2d8f14 rfp=0xcb2d8f40
> r6=0xc0710190 r5=0x2013 r4=0x0004
> arm_do_pending_intr+0x10
> scp=0xc053edf8 rlv=0xc040d9a8 (if_input_process+0xcc)
> rsp=0xcb2d8f44 rfp=0xcb2d8f78
> r10=0xc0692918 r9=0x r8=0x r7=0xcb2d8f44
> r6=0x r5=0xc4d65800 r4=0xc4d57480
> if_input_process+0xc
> scp=0xc040d8e8 rlv=0xc03b5c2c (taskq_thread+0x90)
> rsp=0xcb2d8f7c rfp=0xcb2d8fb0
> r10=0xc06e643c r8=0xc06e65d8 r7=0xcb2d8f7c r6=0x0001
> r5=0xc89e2040 r4=0xc03b5b04
> taskq_thread+0xc
> scp=0xc03b5ba8 rlv=0xc0536c10 (proc_trampoline+0x18)
> rsp=0xcb2d8fb4 rfp=0xc07f3edc
> r7=0x r6=0x r5=0xc89e2040 r4=0xc03b5b9c
> Bad frame pointer: 0xc07f3edc
> 
> this problem has also been encountered with both BB's running -stable.
> 
> >How-To-Repeat:
> Install either -current or -stable on two beaglebone black's, with names
> beagle1 and beagle2. On a LAN 192.168.123.0/24 with default
> gateway 192.168.123.2, set /etc/mygate to 192.168.123.2 on beagle1 and
> beagle2, then set /etc/hostname.cpsw0 on beagle1 to be
> 
> inet 192.168.123.201 255.255.255.0 NONE
> 
> and on beagle2
> 
> inet 192.168.123.202 255.255.255.0 NONE
> 
> then run the following commands on both to use carp(4):
> 
> doas ifconfig carp0 create
> doas ifconfig carp0 vhid 1 pass tyrell carpdev cpsw0 192.168.123.222
> netmask 255.255.255.0
> 
> shortly thereafter a beaglebone will encounter an alignment fault.
> 
> >Fix:
> The cause of this problem is unknown to me. I would speculate that the
> issue lies in m_pullup mishandling alignment, given that netowkring on
> the beaglebone black usually functions normally, and that there are
> branches prior to the crash in which m_pullup is used in deriving a
> pointer to ip, which when using carp(4) apparently misaligned.
> 
> In investigating this issue further, I replaced offending 32-bit loads
> in the kernel with calls to get_unaligned_le32(), defined as (from
> linux/unaligned/packed_struct.h):
> 
> struct __una_u32 { u32 x; } __packed;
> static inline u32 get_unaligned_le32(const void *p) {
> const struct __una_u32 *ptr = (const struct __una_u32 *)p;
> return ptr->x;
> }
> 
> Other than replacements in ip_input.c, udp_usrreq.c was also changed as
> well as the macros IN6_IS_ADDR_UNSPECIFIED, IN6_IS_ADDR_LOOPBACK,
> IN6_IS_ADDR_V4COMPAT, and IN6_IS_ADDR_V4MAPPED in in6.h.
> 
> This resulted in carp(4) appearing to function normally, but beagle1
> and beagle2 repeatedly lost networking temporarily and recurrent
> 'device timeout's appeared in dmesg (as well as carp(4) messages
> informing state changes from master to 

pax(1) problem + fix for archiving 101-char pathnames in ustar format

2016-02-08 Thread Peter Fokker
Hello bugs@openbsd.org,

Today I discovered a problem with pax(1), running on OpenBSD 5.8 (amd64).
Below you find
 - a description of the problem,
 - an instruction on how to reproduce, and
 - a suggestion for a patch.


DESCRIPTION

I tried to add a file to an archive in ustar-format using pax(1) and I got this 
error:

pax: File name too long for ustar
/usr/include/g++/ext/pb_ds/detail/cc_hash_table_map_/constructor_destructor_no_store_hash_fn_imps.hpp

The filename part is only 48 chars, well within the 100-char limit of the ustar 
name field.
The path part is 52 chars, well within the 155-char limit of the ustar prefix 
field. Taking
into account the extra slash between path and filename the total length is 
exactly 52 + 1 + 48
= 101 chars.

This particular pathname could and should easily be split into two pieces, eg. 
"/usr" (4
chars) and
"include/g++/ext/pb_ds/detail/cc_hash_table_map_/constructor_destructor_no_store_hash_fn_imps.hpp"
(96 chars) or "/usr/include/g++/ext/pb_ds/detail/cc_hash_table_map_" (52 chars) 
and
"constructor_destructor_no_store_hash_fn_imps.hpp" (48 chars), but instead I 
get the error
message.

After some experiments and also studying the code I discovered that this error 
only happens
with an absolute path of exactly 101 chars. The routine responsible for 
splitting the name
into two parts (name_split()) erroneously tries to split at the first (leading) 
slash. That
eventually yields a perfect 100-char long name (good) but an invalid empty 
prefix (not good).

Note: there is no problem with a relative path of 101 chars because in that 
case name_split()
does not try to split at the very first character of the name.


HOW TO REPRODUCE

I created this little script in Puffy's home directory (/home/puffy).
It generates a few files with filename lengths between 86 and 102 characters. 
Together with
the length of the path "/home/puffy" (11 chars) and the slash between path and 
filename (1
char), I can test with pathname lengths between 11 + 1 + 86 = 98 chars and 11 + 
1 + 102 = 114
chars.


#!/bin/sh
XO=.X.O
XO=$XO$XO$XO$XO$XO
for x in 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102; do
  filename=$(printf "file-%04d%s\n" $x $XO | cut -c1-$x)
  echo -n $filename > /home/puffy/$filename
  echo /home/puffy/$filename | /bin/pax -w >pax-old-$x.tar
done


The script creates separate ustar-files and the output to stderr is as follows 
(filenames
pruned for readability):

pax: File name too long for ustar /home/puffy/file-0089.[...snip...]
pax: File name too long for ustar /home/puffy/file-0101.[...snip...]
pax: File name too long for ustar /home/puffy/file-0102.[...snip...]

Note that file-0089,* yields an error, but not file-0088.* nor file-0090.*.

The other two errors are to be expected because filenames of more than 100 
chars won't fit in
the ustar name field because they cannot be split at a slash. However, 
file-0100.* and
file-0099.* and all the others are archived without a problem.


PROPOSED PATCH

I have patched src/bin/pax/tar.c and with the patched version adding 
file-0089.* to a ustar
archive no longer yields the error. The errors for file-0101.* and file-0102.* 
remain, which
is expected behaviour. Here is the diff:

--- src/bin/pax/tar.c-orig  Tue Mar 17 04:23:17 2015
+++ src/bin/pax/tar.c   Mon Feb  8 16:36:14 2016
@@ -1159,6 +1159,15 @@
 * include the slash between the two parts that gets thrown away)
 */
start = name + len - TNMSZ - 1;
+
+   /*
+* If name is an absolute path of exactly TNMSZ+1 characters we
+* start looking for the second / (if any) instead of splitting
+* at the initial / which yields an unacceptable empty prefix.
+*/
+   if ((start == name) && (*start == '/'))
+   ++start;
+
while ((*start != '\0') && (*start != '/'))
++start;

@@ -1170,13 +1179,7 @@
return(NULL);
len = start - name;

-   /*
-* NOTE: /str where the length of str == TNMSZ can not be stored under
-* the p1003.1-1990 spec for ustar. We could force a prefix of / and
-* the file would then expand on extract to //str. The len == 0 below
-* makes this special case follow the spec to the letter.
-*/
-   if ((len > TPFSZ) || (len == 0))
+   if (len > TPFSZ)
return(NULL);

/*

I have also attached this diff, retaining the tab-characters in the code.
It would be very nice if you would consider this patch for a future release.
If you need more information I am more than happy to provide it.

Kind regards from The Netherlands,

--Peter Fokker

PS. Please, be gentle with me, this is my first patch to the OpenBSD project...


src-bin-pax-tar.c-patch
Description: Binary data


Re: alignment fault on armv7 when using carp(4)

2016-02-08 Thread Anthony Eden
Thanks for the quick response. Indeed, the patch makes the alignment
faults go away. But the 'device timeout' messages coming from cpsw(4)
remain.

To elaborate a bit, I set up three terminals pinging 192.168.123.201,
192.168.123.202, and 192.168.123.222 (the shared IP). After ~1min I
get no answers from 192.168.123.201 and 192.168.123.201 (although the
times differ). For a few minutes the hosts remain unreachable. dmesg
output looks like

carp0: state transition: BACKUP -> MASTER
carp0: state transition: MASTER -> BACKUP
carp0: state transition: BACKUP -> MASTER
cpsw0: device timeout
carp0: state transition: MASTER -> BACKUP
carp0: state transition: BACKUP -> MASTER
cpsw0: device timeout
...

This bug seems unrelated to the alignment faults issue. I would
investigate given some pointers in the right direction.

If this is under the purview of cpsw(4), would it be advisable to
submit a new bug report?



T450s ceased crypt boot sd0 after I386 install on sd1

2016-02-08 Thread Gerald Hanuer
 Hello bugs@,

Boot of softraid encrypted sd0/sr0
is no longer working after I386
install on softraid encrypted sd1/sr1.

Prior to the I386 install on sd1/sr1.
Both sd0 and sd1 had AMD64 encrypted softraid.
Which was installed from the same 8-20-15 snapshot.
After the install both tracked current.

On 1-28-16 sd1/sr1 was zeroed with dd(1).
A 1-25-16 I386 snapshot was installed
on sd1/sr1 softraid encrypted.
After the install current was tracked.
The tree was built about 6 times.
Boot worked as expected.

I attempt to boot sd0/sr0 AMD64
for the first time 2-6-16
approximately, and get this at boot.

Using drive 0, partition 3.
Loading.
probing: pc0 mem[628k 255M 2053M 56000M a20=on]
disk: hd0+ hd1+ sr0* sr1
 >> OpenBSD/amd64 BOOT 3.29
open(hd0a:/etc/boot.conf): Invalid argument
boot>
cannot open hd0a:/etc/random.seed: Invalid argument
booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
 failed(22). will try /bsd
boot>
cannot open hd0a:/etc/random.seed: Invalid argument
booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
 failed(22). will try /bsd
Turning timeout off.
boot>

I reboot into sd1/sr1 I386 and make sure
sd0/sr0 AMD64 still decrypts, it does.

Postulating the MBR may be damaged,
I boot a 2-7-16 AMD64 snapshot and run
/sbin/fdisk -u sd0
and reboot to the same error as above.

My assumption is sd0/sr0 is damaged in a
very subtle way so as decryption from
bioctl(8) is not effected.

If there is no easy fix I am over looking,
how can this be diagnose further.

I386 dmesg.boot follows.

  Regards,
  Gerald Hanuer

OpenBSD 5.9 (GENERIC.MP) #5: Sun Feb  7 09:19:50 UTC 2016
r...@e8z41g.my.domain:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz ("GenuineIntel"
686-class) 2.50 GHz
cpu0: 
FPU,V86,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,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
real mem  = 2421678080 (2309MB)
avail mem = 2362728448 (2253MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 05/20/08, BIOS32 rev. 0 @ 0xfc200, SMBIOS rev.
2.7 @ 0x9cbfd000 (66 entries)
bios0: vendor LENOVO version "JBET50WW (1.15 )" date 06/10/2015
bios0: LENOVO 20BXCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
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 1 (application processor)
cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz ("GenuineIntel"
686-class) 2.60 GHz
cpu1: 
FPU,V86,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,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz ("GenuineIntel"
686-class) 2.60 GHz
cpu2: 
FPU,V86,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,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz ("GenuineIntel"
686-class) 2.60 GHz
cpu3: 
FPU,V86,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,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40),