spectrwm with conky

[Edgar Pettijohn]

I'm curious if someone has a better way to display the temp with conky than 
this:

Temp:${exec sysctl hw.sensors.acpithinkpad0.temp0 | cut -d = -f 2 | cut -d . -f 
1}C

Thanks,

Edgar

Re: logging in to joyent images

[Lyndon Nerenberg]

> Another option is, when writing the JSON descriptor, to have it inject an SSH 
> key into the machine when provisioning. I've never done this myself, but I 
> know there's a few examples floating around on the web somewhere.

That was the trick, although it took some digging to find the specific 
instructions.

 
https://wiki.smartos.org/display/DOC/How+to+create+a+KVM+VM+%28+Hypervisor+virtualized+machine+%29+in+SmartOS

has the details at the bottom of the frame.  In a nutshell, add the following 
stanza to the VM definition:

"customer_metadata": {
"root_authorized_keys":
"ssh-rsa 
B3NzaC1yc2EBIwAAAQEA8aQRt2JAgq6jpQOT5nukO8gI0Vst+EmBtwBz6gnRjQ4Jw8pERLlMAsa7jxmr5yzRA7Ji8M/kxGLbMHJnINdw/TBP1mCBJ49TjDpobzztGO9icro3337oyvXo5unyPTXIv5pal4hfvl6oZrMW9ghjG3MbIFphAUztzqx8BdwCG31BHUWNBdefRgP7TykD+KyhKrBEa427kAi8VpHU0+M9VBd212mhh8Dcqurq1kC/jLtf6VZDO8tu+XalWAIJcMxN3F3002nFmMLj5qi9EwgRzicndJ3U4PtZrD43GocxlT9M5XKcIXO/rYG4zfrnzXbLKEfabctxPMezGK7iwaOY7w==
 wooyay@houpla"
  }

Create the VM and you can ssh in as root using that key.

I gather this only works with the Joyent-supplied OpenBSD VM images.

Note I also tried to VNC to the console and boot to single user mode, but the 
bootstrap redirects the console to com0 long before there's any chance of 
overriding that at the boot prompt.

--lyndon

Re: umb device, SIM has no PIN?

[Paul B. Henson]

On Fri, Nov 24, 2017 at 11:08:25AM +, Stuart Henderson wrote:

> > booted under openbsd. The umb driver doesn't support accessing the card
> > directly for debugging and diagnostics?
> 
> Correct, you can't get at those from OpenBSD atm.

That's a bummer; guess you wouldn't care too much if things were working
:), but when you're trying to sort out why they're not it sure would be
nice. Then if you're placing an external antenna the signal strength
readings are cool.

> I don't have it handy to check now, but IIRC that's similar to what I
> see on MC8805 after adding the ID for fcc auth.

Interestingly, I tried the card in an external miniPCI to USB adapter,
and it worked fine? Without any driver changes or adding the fcc auth
ID. But when the card is installed directly in the system it doesn't
work :(. But it works fine under Linux, so it's not that the system
hardware is broken or incompatible.

It's a PC Engines APU 3, maybe the OpenBSD USB drivers for this board
aren't working quite right? With the external adapter, the driver sends
the MBIM_OPEN_MSG, gets an interrupt, receives a response, parses the
response, and moves on. Installed on the board, the driver sends the
MBIM_OPEN_MSG, and then nothing happens. No interrupt, no response,
nothing.

Jul 23 18:00:35 maggie /bsd: uhub1 at usb1 configuration 1 interface 0 "AMD EHCI
 root hub" rev 2.00/1.00 addr 1
Jul 23 18:00:35 maggie /bsd: uhub2 at uhub1 port 1 configuration 1 interface 0 
" Advanced Micro Devices product 0x7900" rev 2.00/0.18 addr 2
Jul 23 18:00:35 maggie /bsd: umb0 at uhub2 port 3 configuration 1 interface 12 
" Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm\M-.  
Snapdragon? X7 LTE-A" rev 2.10/0.06 addr 3

It looks like the card is on a stacked hub or something when installed
in the box? When it's plugged in on the external adapter:

Jul 23 18:15:38 maggie /bsd: umb1 at uhub0 port 4 configuration 1 interface 12 
" Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm\M-.  
Snapdragon? X7 LTE-A" rev 2.10/0.06 addr 2

It's connected directly to a controller. They seem to init the same:

Jul 23 18:00:35 maggie /bsd: umb0: umb_attach
Jul 23 18:00:35 maggie /bsd: umb0: ctrl_len=4096, maxpktlen=1422, cap=0x20
Jul 23 18:00:35 maggie /bsd: umb0: ctrl-ifno#12: ep-ctrl=5, data-ifno#13: 
ep-rx= 4, ep-tx=3
Jul 23 18:00:35 maggie /bsd: umb0: rx/tx size 16384/16384
Jul 23 18:00:35 maggie /bsd: umb0: umb_open
Jul 23 18:00:35 maggie /bsd: umb0: umb_ctrl_msg
Jul 23 18:00:35 maggie /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1)
Jul 23 18:00:35 maggie /bsd: umb0: sent MBIM_OPEN_MSG (tid 1)
Jul 23 18:00:35 maggie /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00 00 10 
0 0 00

Jul 23 18:21:20 maggie /bsd: umb1: umb_attach
Jul 23 18:21:20 maggie /bsd: umb1: ctrl_len=4096, maxpktlen=1422, cap=0x20
Jul 23 18:21:20 maggie /bsd: umb1: ctrl-ifno#12: ep-ctrl=5, data-ifno#13: 
ep-rx= 4, ep-tx=3
Jul 23 18:21:20 maggie /bsd: umb1: rx/tx size 16384/16384
Jul 23 18:21:20 maggie /bsd: umb1: umb_open
Jul 23 18:21:20 maggie /bsd: umb1: umb_ctrl_msg
Jul 23 18:21:20 maggie /bsd: umb1: -> snd MBIM_OPEN_MSG (tid 1)
Jul 23 18:21:20 maggie /bsd: umb1: sent MBIM_OPEN_MSG (tid 1)
Jul 23 18:21:20 maggie /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00 00 10 
0 0 00

But it's only when connected externally that the card actually generates
an interrupt and sends a response:

Jul 23 18:15:48 maggie /bsd: umb1: umb_intr
Jul 23 18:15:48 maggie /bsd: umb1: umb_intr: response available
Jul 23 18:15:48 maggie /bsd: umb1: umb_get_response_task
Jul 23 18:15:48 maggie /bsd: umb1: umb_decode_response
Jul 23 18:15:48 maggie /bsd: umb1: got response: len 16


Any thoughts on how to diagnose what might be a USB driver issue as
opposed to an LTE card issue 8-/?

Thanks...

Re: Trouble with CARP and MSS/MTU

[Jean-Daniel]

As I said, CARP does not support specifying a MTU.

Either using ifconfig directly or adding the mtu in the hostname.carp0 file 
result in a SIOCSIFMTU: Inappropriate ioctl for device.


> Le 24 nov. 2017 à 17:28, Alarig Le Lay  a écrit :
> 
> Hi,
> 
> Did you try to add the mtu value argument to your ifconfig line?
> 
> -- 
> alarig

Re: L2TP IPsec + mschap-v2 with preshared key auth when OpenBSD as a CLIENT

[Denis]

Stuart,

thanks again for your support.

I've read some docs since my last post about IKEv1 support only for MS
IPsec + L2TP.

xl2tpd-1.3.8 has been installed already on OpenBSD 6.1amd64. I tried to
use it with integrated pppd, but unsuccessful.
Is xl2tcp-1.3.8 the same version with patches as from -current ports?

pppd has no option to support mschap-v2 available as pppd(8) shows, but
some people shared configs from OpenBSD 5.4 with mschap-v2 option
available in /etc/ppp/options.xl2tpd:
---
obsd client's /etc/xl2tpd/xl2tpd.conf:
[global]
debug avp = yes
debug network = yes
debug state = yes
debug tunnel = yes

[lac foo]
lns = A.B.C.D
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
autodial=yes

obsd client's /etc/ppp/options.l2tpd.client:
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-mschap-v2
noccp
noauth
idle 1800
mtu 1410
mru 1410
defaultroute
usepeerdns
debug
lock
name x
password x
--
I have no evidence if it was work or not.

Seems "require-mschap-v2" support is absent in pppd, While connection is
established it drops when xl2tpd call pppd with mschap-v2 option is needed.

The questions is: how to use npppd with "authentication method
mschap-v2" supported to make it work with xl2tpd together or what
program will help to connect with xl2tpd in bundle to MS IPsec services?

Stuart, I know that MS implementation is not so reliable as OpenBSD
implementation, but I have remote server with only MS based VPN managed
by others, so I can't affect on it.

Thanks

Denis
 
On 11/24/2017 1:54 PM, Stuart Henderson wrote:
> On 2017-11-23, Denis  wrote:
>> Hi All,
>>
>> I have a goal to make an IPsec connection to an external L2TP IPsec with
>> mschap-v2 (preshared key auth) server.
>> OpenBSD 6.1amd64 will play client role in this case.
>>
>> Would you recommended suitable way to make such VPN connection?
>>
>> Can it be realized using iked?
> No. IPsec+L2TP uses IKEv1, iked uses IKEv2.
>
>> Any recommendations or examples will be helpful.
>>
>> Thank you for answer in advance.
> It's not as nice or reliable as normal OpenBSD IPsec, but
> landry@ got this to work. Install xl2tpd (take the version from
> -current ports, it has a hack which avoids some problems seen with
> "large" packets) and look at the README.
>
>

Re: Trouble with CARP and MSS/MTU

[Alarig Le Lay]

Hi,

Did you try to add the mtu value argument to your ifconfig line?

-- 
alarig


signature.asc
Description: PGP signature

Re: logging in to joyent images

[Lyndon Nerenberg]

I have only limited experience with SmartOS, but the quick fix is to login to 
the global zone and use zlogin to enter the VM (get the VM hash from vmadmin 
list). You'll then have a shell and can change the password, add users, and 
adjust the sshd config to your liking.


Not sure that will work on a VM (vs zone), but I'll give it a shot when I 
get back to the machine.


--lyndon

Trouble with CARP and MSS/MTU

[Jean-Daniel Dupas]

Hello,

Using OpenBSD 6.2, I'm trying to setup a CARP interface with IPV6 address. My 
gateway require a 1480 MTU (1420 mss), but I can't figure out how to tell the 
system to use that value for the CARP iface.

I have setup my main interface with a 1480 mtu and ipv6 eui64:

ifconfig vio0
vio0: 
flags=8b43 mtu 1480)
lladdr -
index 1 priority 0 llprio 3
media: Ethernet autoselect
status: active
inet6 fe80::5054:ff:fe06:60d1%vio0 prefixlen 64 scopeid 0x1


I have then created a CARP iface that use a static IPv6. I can't set the mtu in 
the carp iface as this is not supported, so ifconfig report a mtu of 1500 for 
that iface.

ifconfig carp0
carp0: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:69
index 12 priority 15 llprio 3
carp: MASTER carpdev vio0 vhid 105 advbase 1 advskew 0
groups: carp egress
status: master
inet6 fe80::200:5eff:fe00:169%carp4 prefixlen 64 scopeid 0xc
inet6 2a01:e35:1394:9030::3 prefixlen 64

When I send an IPv6 request, by inspecting the packets, I can see that the 
packet specify 1440 as mss.

tcpdump:
2a01:e35:1394:9030::3.39277 > 2001:470:1:18::1281.80: S 
2338755655:2338755655(0) win 16384  [flowlabel 0x39dc5] 


If I instead configure the IPv6 and route on vio0, the packet properly contains 
a  value, so this is clearly an issue with CARP ignoring the carpdev 
MTU.

Is there a way to tell CARP to use the proper MTU ?

Re: kernel_relinking failed

[Roderick]

On Thu, 23 Nov 2017, Kevin Chadwick wrote:


[...] It is not like systemd that is replacing an existing system
in a more complex way.


I think, initialisation got always more complex. BSD init is simpler
than Sys V init, systemd went to the extrem. But rc scripts seem
also got always more complex. Even FreeBSD scripts got, in my
opinion, unreadable. For me is even a surprise to see a call "cc"
in an rc script.


[...] Personally I believe security should be the focus of almost
all software development,


This is definitively not my opinion, because I do not hold
internet connection (and networking) as escential in computing.

Rodrigo.

Re: inteldrm & blank console

[Erik Hunger]

Okay, that was the problem.

>> I've tried 'config -e' and
>> disabling drm and inteldrm lines but quit and save doesn't seem to
>> have the effect I expected.
> In case it didn't work, if config -ef or config -c (usb keyboard
> didn't work for me with config -c though) at boot time is affective then
> you shouldn't see inteldrm in the dmesg?
>

I didn't use the -f flag for config so it wasn't saving it. I could tell it
wasn't saving because the inteldrm was still showing up in dmesg.


Thanks!

Re: umb device, SIM has no PIN?

[Stuart Henderson]

On 2017-11-23, Paul B. Henson  wrote:
> SIM not initialized PIN required

>From my post at https://www.mail-archive.com/tech@openbsd.org/msg32396.html,
: The description in the spec for the state which triggers this
: message is,
:
: "The operation failed because the device is
: in the process of initializing. Retry the
: operation after the ReadyState of the device
: changes to MBIMSubscriberReadyStateInitialized."

> Under linux, the serial control interfaces were available as USB devices
> so you could poke at the card with AT commands, I don't see any listed
> booted under openbsd. The umb driver doesn't support accessing the card
> directly for debugging and diagnostics?

Correct, you can't get at those from OpenBSD atm.


On 2017-11-23, Paul B. Henson  wrote:
> Looking at the source code, I see that there's an workaround for the
> EM7455 card, something about requiring an "FCC Authentication" command?
> From what I understand the MC7455 is the same as the EM7455 other than
> form factor, so I added it to the list for that workaround and also
> turned on debugging in the driver. Here's what it has to say now:
>
> Jul 23 18:12:41 maggie /bsd: umb0 at uhub2 port 3 configuration 1
> interface 12 "Sierra Wireless, Inc
> orporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
> 2.10/0.06 addr 3
> Jul 23 18:12:41 maggie /bsd: umb0: ctrl_len=4096, maxpktlen=1422,
> cap=0x20
> Jul 23 18:12:41 maggie /bsd: umb0: ctrl-ifno#12: ep-ctrl=5,
> data-ifno#13: ep-rx=4, ep-tx=3
> Jul 23 18:12:41 maggie /bsd: umb0: rx/tx size 16384/16384
> Jul 23 18:12:41 maggie /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1)
> Jul 23 18:12:41 maggie /bsd: umb0: sent MBIM_OPEN_MSG (tid 1)
> Jul 23 18:12:41 maggie /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00
> 00 10 00 00
> Jul 23 18:12:41 maggie /bsd: umb0: vers 1.0
> Jul 23 18:12:41 maggie /bsd: ugen0 at uhub2 port 3 configuration 1
> "Sierra Wireless, Incorporated Si
> erra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev 2.10/0.06
> addr 3
>
>
> Jul 23 18:13:31 maggie /bsd: umb0: stop: reached state DOWN  
> Jul 23 18:13:59 maggie /bsd: umb0: init: opening ...
> Jul 23 18:13:59 maggie /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 2)
> Jul 23 18:13:59 maggie /bsd: umb0: sent MBIM_OPEN_MSG (tid 2)
> Jul 23 18:13:59 maggie /bsd:0:   01 00 00 00 10 00 00 00 02 00 00 00
> 00 10 00 00
> Jul 23 18:14:29 maggie /bsd: umb0: state change timeout
> Jul 23 18:14:29 maggie /bsd: umb0: init: opening ...
> Jul 23 18:14:29 maggie /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 3)
> Jul 23 18:14:29 maggie /bsd: umb0: sent MBIM_OPEN_MSG (tid 3)
> Jul 23 18:14:29 maggie /bsd:0:   01 00 00 00 10 00 00 00 03 00 00 00
> 00 10 00 00
> Jul 23 18:14:59 maggie /bsd: umb0: state change timeout
>
> Not sure where to go from here.

I don't have it handy to check now, but IIRC that's similar to what I
see on MC8805 after adding the ID for fcc auth.

Re: L2TP IPsec + mschap-v2 with preshared key auth when OpenBSD as a CLIENT

[Stuart Henderson]

On 2017-11-23, Denis  wrote:
> Hi All,
>
> I have a goal to make an IPsec connection to an external L2TP IPsec with
> mschap-v2 (preshared key auth) server.
> OpenBSD 6.1amd64 will play client role in this case.
>
> Would you recommended suitable way to make such VPN connection?
>
> Can it be realized using iked?

No. IPsec+L2TP uses IKEv1, iked uses IKEv2.

> Any recommendations or examples will be helpful.
>
> Thank you for answer in advance.

It's not as nice or reliable as normal OpenBSD IPsec, but
landry@ got this to work. Install xl2tpd (take the version from
-current ports, it has a hack which avoids some problems seen with
"large" packets) and look at the README.

Re: inteldrm & blank console

[Kevin Chadwick]

On Fri, 24 Nov 2017 02:41:59 -0600


> I've tried 'config -e' and
> disabling drm and inteldrm lines but quit and save doesn't seem to
> have the effect I expected.

In case it didn't work, if config -ef or config -c (usb keyboard
didn't work for me with config -c though) at boot time is affective then
you shouldn't see inteldrm in the dmesg?

Re: logging in to joyent images

[Alex Waite]

Hey Lyndon,


I have installed one of the openbsd-6 SmartOS VM images, gotten the
VM to boot, but I'll be damned if I can find out anywhere a login id
and password that will actually let me log in to the bloody thing.
Anybody been down this road and have an answer?


I have only limited experience with SmartOS, but the quick fix is to 
login to the global zone and use zlogin to enter the VM (get the VM hash 
from vmadmin list). You'll then have a shell and can change the 
password, add users, and adjust the sshd config to your liking.


Another option is, when writing the JSON descriptor, to have it inject 
an SSH key into the machine when provisioning. I've never done this 
myself, but I know there's a few examples floating around on the web 
somewhere.


---Alex

inteldrm & blank console

[Erik Hunger]

I'm running into a graphics problem and looking for work-around options.
I understand others have run into this as well.

I'm getting a black screen as inteldrm switches display modes after
upgrading from 6.1 (where this all worked fine) to 6.2. I blew away the
install and rebuilt from scratch with the same results. I think this
rules out an artifact from the ugprade. I've tried 'config -e' and
disabling drm and inteldrm lines but quit and save doesn't seem to
have the effect I expected.

Is there a workaround for this other than a serial console?

My graphics hardware is Intel HD Graphics 4000 from an i7-3517UE cpu.

Dmesg is below, thanks for any suggestions.


--


OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
   
r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16542121984 (15775MB)
avail mem = 16033763328 (15290MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0840 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version "IPC_2.2.400.3 X64" date
05/17/2017
bios0: CompuLab Ltd. Intense-PC
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT HPET APIC MCFG FPDT ASF! SSDT SSDT UEFI
POAT DMAR UEFI UEFI DBG2
acpi0: wakeup devices P0P1(S4) UAR1(S3) GLAN(S4) EHC1(S4) EHC2(S4)
XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3517UE CPU @ 1.70GHz, 2195.32 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2195316300 Hz
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.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3517UE CPU @ 1.70GHz, 2195.01 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-3517UE CPU @ 1.70GHz, 2195.01 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-3517UE CPU @ 1.70GHz, 2195.01 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 3 (RP01)
acpiprt3 at acpi0: bus 4 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus 5 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus 1 (PEG0)
acpiprt11 at acpi0: bus 2 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(350@80 mwait.1@0x20), 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 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
"INT3F0D" at acpi0 not