Re: ifconfig AF

[Jason McIntyre]

On Tue, Feb 19, 2019 at 09:42:17PM -0600, Alfred Morgan wrote:
> I ran the command ifconfig re0 autoconf and found an error message saying
> "autoconf not allowed for this AF" and it took me some time searching to
> figure out what "AF" meant. After I found out that it meant "address
> family" I used the inet6 syntax. I think it would be useful to change the
> error message to say "address family" instead of "AF". If you require a
> diff for the source code changes then let me know.
> -- 
> -alfred

hi.

you could also have verified in the ifconfig(8) page the right way to
use autoconf.

not trying to discourage you from submitting a diff, but i think the
information you needed was already there.

jmc

Re: Multiple instances of OSPFD in different RDomains - rcctl behavior

[Henry Bonath]

That was actually how I noticed it in the first place. I was running a 
highstate and it kept wanting to change my rc.conf.local and put the 
ospf2d_flags line back in. 

I do not run any salt states automatically, that would be an obvious 
workaround. I was just hoping to get some clarification as to my approach, and 
if I wasn’t doing something correctly in regards to working with multiple 
rdomains. 

This is on OpenBSD 6.4 btw...

Thanks!
-Henry


> On Feb 19, 2019, at 9:47 PM, Scott Reese  wrote:
> 
> - Original Message -
>> From: "Henry Bonath" 
>> To: "misc" 
>> Sent: Tuesday, February 19, 2019 2:03:31 PM
>> Subject: Multiple instances of OSPFD in different RDomains - rcctl behavior
> 
>> Hello, I am seeing some strange behavior with my /etc/rc.conf.local
>> regarding my configuration for running two instances of OSPFD in
>> different RDomains.
>> 
>> The way I have this configured, is I have a symlink: /etc/rc.d/ospf2d
>> -> /etc/rc.d/ospfd so that the ospfd that runs in rdomain 2 has its
>> own entry in rc.conf.local, pointing to its own config file.
>> 
>> In my /etc/rc.conf.local I have the following:
>> #
>> bgpd_flags=
>> ldpd_flags=
>> ospf2d_flags=-f /etc/ospf2d.conf
>> ospf2d_rtable=2
>> ospfd_flags=
>> pf=NO
>> pkg_scripts=salt_minion ospf2d
>> salt_minion_rtable=3
>> #
>> 
>> However I notice that something is removing the "ospf2d_flags=..."
>> line as output from daily insecurity mail:
>> 
>> ==
>> /etc/rc.conf.local diffs (-OLD  +NEW)
>> ==
>> --- /var/backups/etc_rc.conf.local.current  Wed Jan 16 01:30:06 2019
>> +++ /etc/rc.conf.local  Fri Feb 15 13:05:17 2019
>> @@ -1,9 +1,7 @@
>> bgpd_flags=
>> ldpd_flags=
>> -ospf2d_flags=-f /etc/ospf2d.conf
>> ospf2d_rtable=2
>> ospfd_flags=
>> pf=NO
>> pkg_scripts=salt_minion ospf2d
>> salt_minion_rtable=3
>> 
>> Is my syntax incorrect? Would /etc/daily be doing something here to my
>> configuration?
>> Why would this line keep being automatically removed?
>> 
>> Thanks in advance!
> 
> Greetings Henry:
> 
> Looks like you're running Saltstack. Any chance that your Salt master
> has a copy of the rc.conf.local that doesn't have the ospf2d_flags line
> and is resetting the file back to its "correct" values?
> 
> -Scott
> 

Re: Multiple instances of OSPFD in different RDomains - rcctl behavior

[Scott Reese]

- Original Message -
> From: "Henry Bonath" 
> To: "misc" 
> Sent: Tuesday, February 19, 2019 2:03:31 PM
> Subject: Multiple instances of OSPFD in different RDomains - rcctl behavior

> Hello, I am seeing some strange behavior with my /etc/rc.conf.local
> regarding my configuration for running two instances of OSPFD in
> different RDomains.
> 
> The way I have this configured, is I have a symlink: /etc/rc.d/ospf2d
> -> /etc/rc.d/ospfd so that the ospfd that runs in rdomain 2 has its
> own entry in rc.conf.local, pointing to its own config file.
> 
> In my /etc/rc.conf.local I have the following:
> #
> bgpd_flags=
> ldpd_flags=
> ospf2d_flags=-f /etc/ospf2d.conf
> ospf2d_rtable=2
> ospfd_flags=
> pf=NO
> pkg_scripts=salt_minion ospf2d
> salt_minion_rtable=3
> #
> 
> However I notice that something is removing the "ospf2d_flags=..."
> line as output from daily insecurity mail:
> 
> ==
> /etc/rc.conf.local diffs (-OLD  +NEW)
> ==
> --- /var/backups/etc_rc.conf.local.current  Wed Jan 16 01:30:06 2019
> +++ /etc/rc.conf.local  Fri Feb 15 13:05:17 2019
> @@ -1,9 +1,7 @@
> bgpd_flags=
> ldpd_flags=
> -ospf2d_flags=-f /etc/ospf2d.conf
> ospf2d_rtable=2
> ospfd_flags=
> pf=NO
> pkg_scripts=salt_minion ospf2d
> salt_minion_rtable=3
> 
> Is my syntax incorrect? Would /etc/daily be doing something here to my
> configuration?
> Why would this line keep being automatically removed?
> 
> Thanks in advance!

Greetings Henry:

Looks like you're running Saltstack. Any chance that your Salt master
has a copy of the rc.conf.local that doesn't have the ospf2d_flags line
and is resetting the file back to its "correct" values?

-Scott

ifconfig AF

[Alfred Morgan]

I ran the command ifconfig re0 autoconf and found an error message saying
"autoconf not allowed for this AF" and it took me some time searching to
figure out what "AF" meant. After I found out that it meant "address
family" I used the inet6 syntax. I think it would be useful to change the
error message to say "address family" instead of "AF". If you require a
diff for the source code changes then let me know.
-- 
-alfred

Re: Research and OpenBSD: How can I help?

[Frank Beuth]

On Thu, Feb 14, 2019 at 04:22:05AM +, Paul Swanson wrote:

I have some general areas of interest, such as embedded
computing, but nothing is set in stone yet, so I thought it'd
be fun to hear from those in know about areas of priority need
within the OpenBSD community.

Are there particular problems that could benefit from new
ideas or solutions?


An area that I am personally interested in is running OpenBSD on fully 
open-source / binary-blob-free hardware: hardware where there is no proprietary 
firmware that could hide vendor backdoors, and ideally where even the design of 
the chip is available to the user for review.


The trouble is it's VERY hard to find "fully open" hardware, and the hardware 
which is known to exist (loongson, OpenPOWER, RISC V) is difficult to get, 
expensive or not very good, and (except for loongson) not supported by OpenBSD.

Re: Research and OpenBSD: How can I help?

[Paul Swanson]

Hi Ingo,

Yes, I realise my question was quite vague but it was deliberately very general 
in the hope of netting the broadest range of opinions.

I do have specialisations and specific interests, and the nature of my studies 
will largely be self directed and primarily code generating.

I am simply canvasing for problems that might intersect with those I already 
have in mind. It's the old, you don't know what you don't know, and I prefer 
not to lead people too much when when attempting to solicit this kind of 
information. Sometimes, I find lateral opinions to be very useful in 
formulating new ideas or direction.

Nonetheless, thanks for your thoughts.

Regards,

Paul Swanson

Sent from ProtonMail mobile

 Original Message 
On Feb 20, 2019, 04:54, Ingo Schwarze wrote:

> Hi Paul,
>
> Short answer:
>
> Shut up and hack.
>
> The same answer in more verbose form:
>
> Research is often regarded as equally valuable as cheap and useless
> talk in the OpenBSD community - unless it is accompanied by source
> code patches actually making things better.
> (That's an oversimplification, but i hope you get the idea.)
>
> Regarding what to work on:
>
> Almost everything can be improved.
>
> Finding out what you are interested in, what you are capable of,
> and finding out *yourself* what needs to be done (both in a specific
> situation and globally) is among the most important qualifications;
> attending university is one way to try and learn that, but no
> guarantee for actually learning it.
>
> Your question is naive and not specific enough to permit any
> answer that might be satisfactory.
>
> Yours,
> Ingo
>
> Paul Swanson wrote on Thu, Feb 14, 2019 at 04:22:05AM +:
>
>> I'm beginning a Computer Science Master's program and would
>> like to hear from members of the OpenBSD community about
>> possible areas of research that could be of benefit to OpenBSD
>> and its associated projects.
>>
>> I have some general areas of interest, such as embedded
>> computing, but nothing is set in stone yet, so I thought it'd
>> be fun to hear from those in know about areas of priority need
>> within the OpenBSD community.
>>
>> Are there particular problems that could benefit from new
>> ideas or solutions?
>>
>> Please let me know your thoughts!
>>
>> Regards,
>>
>> Paul Swanson

Re: video(1) Unable to use webcam

[Alexandre Ratchov]

On Tue, Feb 19, 2019 at 06:16:42PM +0200, Vitaly Kovalyshyn wrote:
> I have disabled USB3.0 in the BIOS and my camera now works.
> Thank you.
> 
> Is it posible to use USB3.0 and webcam at the same time in OpenBSD?

Not yet on all machines and webcam combinations.

Re: Is there a fix for stock vi's bug-for-bug compatible ESC-equals-return feature?

[Ted Unangst]

I think the answer is, you want traditional vi, you get traditional vi. If you
want something else, try ports.

Re: Is there a fix for stock vi's bug-for-bug compatible ESC-equals-return feature?

[ropers]

> On 2019-02-18 09:04, ropers wrote:
> [...]
>> vi(1) has a feature where pressing ESC while in command-line mode
>> (i.e. entering an ex command in command mode) will sometimes cancel
>> the current line of ex input, but other times will have the same
>> effect as if the user had pressed return.

On 19/02/2019, Alessandro DE LAURENZIS  wrote:
> I'm not an expert, but this behavior seems to be in line with POSIX [1]
> requirements:
>
> [...]
> 
> Synopsis:
> 
>
> If input was part of a line-oriented command:
>
> If interrupt was entered, text input mode shall be terminated and the
> editor shall return to command mode. The terminal shall be alerted.
>
> If  was entered, text input mode shall be terminated and the
> command shall continue execution with the input provided.
>
> Otherwise, terminate text input mode and return to command mode.
> [...]
>
> In nvi, it is consistent among all line-oriented commands (:, /, ? and
> !).
>
> Just my 2 cents
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/

That's still a frames-based webpage. The direct link you probably
intended is this:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
Or, more directly:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_13_97

Thanks for the POSIX hint. Sadly, that page still leaves me confused,
or maybe the spec is bad, and I would welcome further advice from you
or others.
(That said, to my understanding OpenBSD tries to Do The Right Thing
more so than follow any spec, so perhaps discussing the spec's merit
is getting off-topic. If the spec is off-topic, I'd still welcome
further replies to my original question. If people would prefer I took
this to another forum, I'd welcome suggestions on where to go.)

Here's what has me confused about that POSIX spec:
1.
There is another ESC-related section on that vi page:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_13_16
"Terminate Command or Input Mode"
However, that section is about how ESC behaves either in command (aka
normal) mode or in input (aka insert) mode, and that's arguably
different from how ESC behaves when typing (visible) command lines at
the bottom. Technically *command-line mode* (as entered by :, /, ? and
!etc) is a different mode; cf. here:
https://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/Modes That's
at least according to how most vi and vim experts describe things.
Granted, that POSIX spec does not explicitly state that command-line
mode is a separate mode; it speaks of "line-oriented commands", but
whether this part of vi is called a separate mode or not is ultimately
just semantics.
However, *if* the POSIX spec considers command-line mode a part of
command mode, then that section *would* seem to apply to command-line
mode, and it *differs* from the section you quoted, and according to
it, ESC should *not* behave like return.
2.
The  section you quoted is part of a list of possible input, and
on top of that list, just above the NUL section (how do you even input
that off the keyboard?),

it says: "The following specifications are for command characters
entered during text input mode." The headline above that reads, "Input
Mode Commands in vi".
However, in the specifications that follow, there are multiple
references to line-oriented command input, so which is it? Even if we
accept that command-line mode is part of command mode, clearly neither
are part of text input mode (i.e. insert mode). So this is very
inconsistent.
I also really don't like the phrasing, "If input was part of a
line-oriented command", because many *commands* in input mode are
arguably line-oriented (e.g. d2d, y5y) , and many commands in
command-line mode are arguably not really line oriented (e.g.
:%s/foo/bar), at least in their effects.
Moreover, the explicit references to terminating "text input mode"
seem to imply that the user is in insert mode.

So if the ESC-equals-return behaviour was implemented as a result of
the POSIX spec like you suggest, then it seems to me that this may
have been based on a misreading of a very confusing spec.

Or is it just me who's confused?
Clarifications welcome.

Thanks and regards,
Ian

PS: Considering what it says here:
, I would be very interested
in hearing whether the ESC-equals-return behaviour existed in the
original 4BSD vi. Does anyone know?

PPS: Under Fast Startup , man vi says:
"There is only one key that takes you out of input mode, and that is
the ⟨escape⟩ key",
but under vi Text Input Commands,
 it says:
"⟨interrupt⟩ Interrupt text input mode, returning to command mode.
The ⟨interrupt⟩ character is usually ⟨control-C⟩."
Do people think that that's a contradiction? Arguably, control-C is
not "one key", but still. Also, is the second quote 

Re: keeping track of MAC addresses

[Adam Thompson]

On 2019-02-14 02:01, mailingli...@dotbit.ro wrote:

I would like to keep tabs on the MAC/IP addresses in my secure net.
I do know how to do this, but keeping track of ethernet MAC addresses 
seems
quite cumbersome in OpenBSD, not that it is more convenient in any 
other
general purpose operating system but many interfaces for ex. routers 
make it

easy to manage, especially MAC filtering.


Perhaps look at the "arpwatch" package in ports, which may be 
applicable.


But... you know that both ARP and MAC addresses can be trivially 
spoofed, right?  Just using /etc/ethers instead of ARP does *not* make 
your network secure.


Some "intelligent" switches do ARP sniffing to populate their internal 
hardware FIBs.  (Yes, that's a dumb idea.  Switch vendors still do it.)  
Disabling ARP on your hosts is... not generally a good idea.


PS: after running ifconfig em0 -arp my Allied Telesis AT-GS950-16 
managed
switch took the link down and refuses to bring it back up on the same 
port

without a reset. Other ports work fine.


I won't say this is impossible, but it seems unlikely.  I think it's 
more likely the lack of ARP traffic on the port caused the switch to do 
something "interesting" with IP traffic destined for this host.  Or 
maybe something else triggered storm-prevention features in the switch?  
Running an ifconfig(8) command should not be able to persistently shut 
down a switch port in any network environment.  Did you observe the link 
lights on the NIC and switch actually turn off and stay off?


As I have already mentioned I can manage by myself, but it seems to me 
that

this is something that a lot of people would want.


Not so much, AFAIK.  Disabling core IP protocols usually generates more 
problems than it solves.  Let us know how disabling/blocking ICMPv6 
works out for you... ;-)  [Hint: that's a trick question.  You can't run 
IPv6 without ICMPv6.]


You could filter on MAC addresses instead of restricting ARP:  
https://www.openbsd.org/faq/pf/tagging.html#ethernet   That requires 
using bridge(4) which apparently is on its way out, and I don't know if 
the replacement (switch(4)) supports filtering packets based on MAC 
address or not - it's OpenFlow-compliant, so there has to be a way, but 
it may or may not be easily accessible from inside OpenBSD.


You may also want to assign new MAC addresses to your hosts, both to 
eliminate the need to gather the MACs, and to simplify maintenance (e.g. 
the labour involved in replacing a NIC on a server or a motherboard is 
O(n^2) with hardware-bound MAC addresses in your setup, instead of 
O(1)).  There are special LAAs (Locally-Assigned Addresses) that you can 
use for this.  OpenBSD supports setting a locally-assigned MAC address 
with ifconfig(8) "lladdr" option.


Good luck on your strange quest,
-Adam

Multiple instances of OSPFD in different RDomains - rcctl behavior

[Henry Bonath]

Hello, I am seeing some strange behavior with my /etc/rc.conf.local
regarding my configuration for running two instances of OSPFD in
different RDomains.

The way I have this configured, is I have a symlink: /etc/rc.d/ospf2d
-> /etc/rc.d/ospfd so that the ospfd that runs in rdomain 2 has its
own entry in rc.conf.local, pointing to its own config file.

In my /etc/rc.conf.local I have the following:
#
bgpd_flags=
ldpd_flags=
ospf2d_flags=-f /etc/ospf2d.conf
ospf2d_rtable=2
ospfd_flags=
pf=NO
pkg_scripts=salt_minion ospf2d
salt_minion_rtable=3
#

However I notice that something is removing the "ospf2d_flags=..."
line as output from daily insecurity mail:

==
/etc/rc.conf.local diffs (-OLD  +NEW)
==
--- /var/backups/etc_rc.conf.local.current  Wed Jan 16 01:30:06 2019
+++ /etc/rc.conf.local  Fri Feb 15 13:05:17 2019
@@ -1,9 +1,7 @@
 bgpd_flags=
 ldpd_flags=
-ospf2d_flags=-f /etc/ospf2d.conf
 ospf2d_rtable=2
 ospfd_flags=
 pf=NO
 pkg_scripts=salt_minion ospf2d
 salt_minion_rtable=3

Is my syntax incorrect? Would /etc/daily be doing something here to my
configuration?
Why would this line keep being automatically removed?

Thanks in advance!

Re: Research and OpenBSD: How can I help?

[Ingo Schwarze]

Hi Paul,

Short answer:

  Shut up and hack.

The same answer in more verbose form:

  Research is often regarded as equally valuable as cheap and useless
  talk in the OpenBSD community - unless it is accompanied by source
  code patches actually making things better.
  (That's an oversimplification, but i hope you get the idea.)

Regarding what to work on:

  Almost everything can be improved.

  Finding out what you are interested in, what you are capable of,
  and finding out *yourself* what needs to be done (both in a specific
  situation and globally) is among the most important qualifications;
  attending university is one way to try and learn that, but no
  guarantee for actually learning it.

Your question is naive and not specific enough to permit any
answer that might be satisfactory.

Yours,
  Ingo


Paul Swanson wrote on Thu, Feb 14, 2019 at 04:22:05AM +:

> I'm beginning a Computer Science Master's program and would
> like to hear from members of the OpenBSD community about
> possible areas of research that could be of benefit to OpenBSD
> and its associated projects.
> 
> I have some general areas of interest, such as embedded
> computing, but nothing is set in stone yet, so I thought it'd
> be fun to hear from those in know about areas of priority need
> within the OpenBSD community.
> 
> Are there particular problems that could benefit from new
> ideas or solutions?
> 
> Please let me know your thoughts!
> 
> Regards,
> 
> Paul Swanson

Re: wscons API question: input handling?

[Leonid Bobrov]

On Tue, Feb 19, 2019 at 04:01:08PM +, tfrohw...@fastmail.com wrote:
> Is the package x11/xbindkeys what you are looking for?
>

No, I need a direct access to keyboard outside X11. If I understand
wscons, I might help to port libinput to OpenBSD (and send patches to
upstream) to have usable Wayland compositors, but before I do that, I
need to start small.

Re: video(1) Unable to use webcam

[Vitaly Kovalyshyn]

I have disabled USB3.0 in the BIOS and my camera now works.
Thank you.

Is it posible to use USB3.0 and webcam at the same time in OpenBSD?

On Tue, Feb 19, 2019 at 05:32:04PM +0200, Mihai Popescu wrote:
> https://marc.info/?l=openbsd-misc=155050320512916=2
>

Re: wscons API question: input handling?

[tfrohw...@fastmail.com]

On February 19, 2019 2:16:04 PM UTC, Leonid Bobrov  wrote:
>Hi!
>
>I want to write a program that executes a particular code at key press,
>where can I find documentation about that? I have example program which
>doesn't work:
>
>int
>main(void)
>{
>int kbdfd = open("/dev/wskbd", O_RDWR, 0);
>
>if (errno != 0) {
>printf("%s\n", strerror(errno));
>return 1;
>}
>
>int key;
>
>while(ioctl(kbdfd, WSCONS_EVENT_KEY_UP, ) != -1) {
>if (key == KS_k)
>printf("You pressed k!");
>else if (key == KS_q)
>break;
>else
>printf("You pressed %d!", key);
>}
>
>if (errno != 0) {
>printf("%s\n", strerror(errno));
>return 1;
>}
>
>return 0;
>}

Is the package x11/xbindkeys what you are looking for?

Re: video(1) Unable to use webcam

[Mihai Popescu]

https://marc.info/?l=openbsd-misc=155050320512916=2

Re: wscons API question: input handling?

[Leonid Bobrov]

I don't know why, but my includes were not sent:

wscons API question: input handling?

[Leonid Bobrov]

Hi!

I want to write a program that executes a particular code at key press,
where can I find documentation about that? I have example program which
doesn't work:

int
main(void)
{
int kbdfd = open("/dev/wskbd", O_RDWR, 0);

if (errno != 0) {
printf("%s\n", strerror(errno));
return 1;
}

int key;

while(ioctl(kbdfd, WSCONS_EVENT_KEY_UP, ) != -1) {
if (key == KS_k)
printf("You pressed k!");
else if (key == KS_q)
break;
else
printf("You pressed %d!", key);
}

if (errno != 0) {
printf("%s\n", strerror(errno));
return 1;
}

return 0;
}

Re: Is there a fix for stock vi's bug-for-bug compatible ESC-equals-return feature?

[Alessandro DE LAURENZIS]

Hello,

On 2019-02-18 09:04, ropers wrote:
[...]

vi(1) has a feature where pressing ESC while in command-line mode
(i.e. entering an ex command in command mode) will sometimes cancel
the current line of ex input, but other times will have the same
effect as if the user had pressed return.


I'm not an expert, but this behavior seems to be in line with POSIX [1] 
requirements:


[...]

Synopsis:


If input was part of a line-oriented command:

If interrupt was entered, text input mode shall be terminated and the 
editor shall return to command mode. The terminal shall be alerted.


If  was entered, text input mode shall be terminated and the 
command shall continue execution with the input provided.


Otherwise, terminate text input mode and return to command mode.
[...]

In nvi, it is consistent among all line-oriented commands (:, /, ? and 
!).


Just my 2 cents

[1] http://pubs.opengroup.org/onlinepubs/9699919799/

--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis

video(1) Unable to use webcam

[Vitaly Kovalyshyn]

Hi misc@

Can anyone help me with a webcam on OpenBSD 6.4 (dmesg below) ThinkPad X240?

ktrace(1) has: recvfrom -1 errno 35 Resource temporarily unavailable

samael@x240:~$ video -q -f /dev/video0
video device /dev/video0:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
320x180: 30, 15
320x240: 30, 15
352x288: 30, 15
424x240: 30, 15
640x360: 30, 15
640x480: 30, 15
848x480: 20
960x540: 15
1280x720: 10
  controls: brightness, contrast, saturation, hue, gamma, sharpness

samael@x240:~$ video -e yuy2 -f /dev/video0
video: ioctl VIDIOC_STREAMON: Invalid argument

samael@x240:~$ video  -f /dev/video0
video: ioctl VIDIOC_STREAMON: Invalid argument

Thank You!

dmesg:

OpenBSD 6.4 (GENERIC) #349: Thu Oct 11 13:25:13 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 4175851520 (3982MB)
avail mem = 4040130560 (3852MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (60 entries)
bios0: vendor LENOVO version "GIET94WW (2.44 )" date 09/20/2018
bios0: LENOVO 20AMA1LFGE
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
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) i5-4300U CPU @ 1.90GHz, 1796.12 MHz, 06-45-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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
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
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: 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@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
acpitz0 at acpi0: critical temperature is 200 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "45N1773" serial 17296 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 model "45N1735" serial  4008 type LION oem "LGC"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
acpivideo0 at acpi0: VID_
acpivout at acpivideo0 not configured
acpivideo1 at acpi0: VID_
cpu0: Enhanced SpeedStep 1796 MHz: speeds: 2501, 2500, 2400, 2200, 2100, 1900, 
1800, 1700, 1600, 1500, 1300, 1200, 1100, 1000, 800, 775 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x0b
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x0b
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1366x768, 32bpp
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 0x0b: msi
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
"Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel I218-LM" rev 0x04: msi, address 
28:d2:44:d8:69:1b
azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi
azalia1: codecs: Realtek ALC292
audio0 at azalia1
ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xe4: msi
pci1 at ppb0 bus 2
rtsx0 at pci1 dev 0 function 0 "Realtek RTS5227 Card Reader" rev 0x01: msi
sdmmc0 at rtsx0: 4-bit, dma
ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xe4: msi
pci2 at ppb1 bus 3
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x6b, msi
ehci0 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x04: apic 2 int 23
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
pcib0 at