Re: em(4): Don't count RX overruns and missed packets as input errros

2013-12-31 Thread Mark Kettenis
 Date: Tue, 31 Dec 2013 01:28:04 -0500
 From: Brad Smith b...@comstyle.com
 
 Don't count RX overruns and missed packets as inputs errors. They're
 expected to increment when using MCLGETI.
 
 OK?

These may be expected, but they're still packets that were not
received.  And it is useful to know about these, for example when
debugging TCP performance issues.

 Index: if_em.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_em.c,v
 retrieving revision 1.275
 diff -u -p -u -p -r1.275 if_em.c
 --- if_em.c   28 Dec 2013 03:34:54 -  1.275
 +++ if_em.c   31 Dec 2013 06:03:55 -
 @@ -3246,9 +3248,9 @@ em_update_stats_counters(struct em_softc
   sc-stats.rxerrc +
   sc-stats.crcerrs +
   sc-stats.algnerrc +
 - sc-stats.ruc + sc-stats.roc +
 - sc-stats.mpc + sc-stats.cexterr +
 - sc-rx_overruns;
 + sc-stats.ruc +
 + sc-stats.roc +
 + sc-stats.cexterr;
  
   /* Tx Errors */
   ifp-if_oerrors = sc-stats.ecol + sc-stats.latecol +
 
 -- 
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.
 
 



Re: em(4): Don't count RX overruns and missed packets as input errros

2013-12-31 Thread Brad Smith

On 31/12/13 3:14 AM, Mark Kettenis wrote:

Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com

Don't count RX overruns and missed packets as inputs errors. They're
expected to increment when using MCLGETI.

OK?


These may be expected, but they're still packets that were not
received.  And it is useful to know about these, for example when
debugging TCP performance issues.


Well do we want to keep just the missed packets or both? Part of the
diff was inspired by this commit when I was looking at what counters
were incrementing..

for bge(4)..

revision 1.334
date: 2013/06/06 00:05:30;  author: dlg;  state: Exp;  lines: +2 -4;
dont count rx ring overruns as input errors. with MCLGETI controlling the
ring we expect to run out of rx descriptors as a matter of course, its not
an error.

ok mikeb@



Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.275
diff -u -p -u -p -r1.275 if_em.c
--- if_em.c 28 Dec 2013 03:34:54 -  1.275
+++ if_em.c 31 Dec 2013 06:03:55 -
@@ -3246,9 +3248,9 @@ em_update_stats_counters(struct em_softc
sc-stats.rxerrc +
sc-stats.crcerrs +
sc-stats.algnerrc +
-   sc-stats.ruc + sc-stats.roc +
-   sc-stats.mpc + sc-stats.cexterr +
-   sc-rx_overruns;
+   sc-stats.ruc +
+   sc-stats.roc +
+   sc-stats.cexterr;

/* Tx Errors */
ifp-if_oerrors = sc-stats.ecol + sc-stats.latecol +

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.







--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: TOD clock for octeons

2013-12-31 Thread Paul Irofti
On Tue, Dec 31, 2013 at 02:22:10AM +0200, Paul Irofti wrote:
 On Mon, Dec 30, 2013 at 06:49:38PM +0200, Paul Irofti wrote:
  On Mon, Dec 30, 2013 at 02:47:58PM +0200, Paul Irofti wrote:
   The following enables the DS1337 RTC clock found on octeon boards.
   
   I've tested it on my DSR-500 and would love to hear about tests on other
   machines.
   
   Comments? Okays?
  
  New diff after a helpful tip from miod
 
 Better diff. There still seems to be problems with setting the time.
 
 I'll look into it in the morning.

Found the problem. The year was handled wrong.
What's after 2000 is +100 not +2000.
2013 - 113 and 1998 - 98

This diff works in both getting and setting the time. Okay?

Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v
retrieving revision 1.11
diff -u -p -r1.11 GENERIC
--- conf/GENERIC24 Oct 2013 20:47:08 -  1.11
+++ conf/GENERIC31 Dec 2013 10:08:15 -
@@ -31,6 +31,8 @@ clock0at mainbus0
 iobus0 at mainbus0
 uartbus0   at mainbus0
 
+octrtc0at mainbus0
+
 octcf0 at iobus0
 octrng0at iobus0
 
Index: conf/files.octeon
===
RCS file: /cvs/src/sys/arch/octeon/conf/files.octeon,v
retrieving revision 1.16
diff -u -p -r1.16 files.octeon
--- conf/files.octeon   4 Nov 2013 14:07:16 -   1.16
+++ conf/files.octeon   31 Dec 2013 10:08:15 -
@@ -48,6 +48,11 @@ attach   cpu at mainbus
 device clock
 attach clock at mainbus
 
+# TOD clock
+device octrtc
+attach octrtc at mainbus
+file   arch/octeon/dev/octrtc.coctrtc
+
 define iobus {[base = -1]}
 device iobus
 attach iobus at mainbus
Index: dev/mainbus.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/mainbus.c,v
retrieving revision 1.5
diff -u -p -r1.5 mainbus.c
--- dev/mainbus.c   25 Jun 2011 19:39:32 -  1.5
+++ dev/mainbus.c   31 Dec 2013 10:08:15 -
@@ -86,6 +86,10 @@ mainbus_attach(struct device *parent, st
/* on-board I/O */
caa.caa_maa.maa_name = iobus;
config_found(self, caa.caa_maa, mainbus_print);
+
+   caa.caa_maa.maa_name = octrtc;
+   config_found(self, caa.caa_maa, mainbus_print);
+
 }
 
 int
Index: dev/octrtc.c
===
RCS file: dev/octrtc.c
diff -N dev/octrtc.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ dev/octrtc.c31 Dec 2013 10:08:15 -
@@ -0,0 +1,272 @@
+/* $OpenBSD$   */
+
+/*
+ * Copyright (c) 2013 Paul Irofti.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys/param.h
+#include sys/systm.h
+#include sys/device.h
+#include sys/proc.h
+
+#include mips64/dev/clockvar.h
+
+#include machine/bus.h
+#include machine/autoconf.h
+#include machine/octeonvar.h
+
+#ifdef OCTRTC_DEBUG
+#define DPRINTF(x) printf x
+#else
+#define DPRINTF(x)
+#endif
+
+#define MIO_TWS_SW_TWSI0x000118001000ULL
+#define MIO_TWS_SW_TWSI_EXT0x000118001018ULL
+#define OCTRTC_REG 0x68
+
+struct cfdriver octrtc_cd = {
+   NULL, octrtc, DV_DULL
+};
+
+intoctrtc_match(struct device *, void *, void *);
+void   octrtc_attach(struct device *, struct device *, void *);
+
+void   octrtc_gettime(void *, time_t, struct tod_time *);
+intoctrtc_read(uint8_t *, char);
+
+void   octrtc_settime(void *, struct tod_time *);
+intoctrtc_write(uint8_t);
+
+
+struct cfattach octrtc_ca = {
+   sizeof(struct device), octrtc_match, octrtc_attach,
+};
+
+
+union mio_tws_sw_twsi_reg {
+   uint64_t reg;
+   struct cvmx_mio_twsx_sw_twsi_s {
+   uint64_t v:1;   /* Valid bit */
+   uint64_t slonly:1;  /* Slave Only Mode */
+   uint64_t eia:1; /* Extended Internal Address */
+   uint64_t op:4;  /* Opcode field */
+   uint64_t r:1;   /* Read bit or result */
+   uint64_t sovr:1;/* Size Override */
+   uint64_t size:3;/* Size in bytes */
+   uint64_t scr:2; /* Scratch, unused */
+   uint64_t a:10;  

Re: em(4): Don't count RX overruns and missed packets as input errros

2013-12-31 Thread Mike Belopuhov
On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:
 On 31/12/13 3:14 AM, Mark Kettenis wrote:

 Date: Tue, 31 Dec 2013 01:28:04 -0500
 From: Brad Smith b...@comstyle.com

 Don't count RX overruns and missed packets as inputs errors. They're
 expected to increment when using MCLGETI.

 OK?


 These may be expected, but they're still packets that were not
 received.  And it is useful to know about these, for example when
 debugging TCP performance issues.


 Well do we want to keep just the missed packets or both? Part of the
 diff was inspired by this commit when I was looking at what counters
 were incrementing..

 for bge(4)..

 revision 1.334
 date: 2013/06/06 00:05:30;  author: dlg;  state: Exp;  lines: +2 -4;
 dont count rx ring overruns as input errors. with MCLGETI controlling the
 ring we expect to run out of rx descriptors as a matter of course, its not
 an error.

 ok mikeb@



it does screws up statistics big time.  does mpc counter follow rx_overruns?
why did we add them up both previously?



tedu old PKG_PREFIX

2013-12-31 Thread Marc Espie
I think I put this in for compatibility with the old tools years ago.
I don't think anyone still uses this, so this can probably die.

(I have run a grep thru the ports tree and the man pages, no reference at all)

okay ?

Index: OpenBSD/Delete.pm
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/pkg_add/OpenBSD/Delete.pm,v
retrieving revision 1.122
diff -u -p -r1.122 Delete.pm
--- OpenBSD/Delete.pm   30 Dec 2013 09:02:37 -  1.122
+++ OpenBSD/Delete.pm   31 Dec 2013 12:12:52 -
@@ -147,7 +147,6 @@ sub delete_plist
 
my $pkgname = $plist-pkgname;
$state-{pkgname} = $pkgname;
-   $ENV{'PKG_PREFIX'} = $plist-localbase;
if (!$state-{size_only}) {
$plist-register_manpage($state);
manpages_unindex($state);
Index: OpenBSD/PkgAdd.pm
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/pkg_add/OpenBSD/PkgAdd.pm,v
retrieving revision 1.41
diff -u -p -r1.41 PkgAdd.pm
--- OpenBSD/PkgAdd.pm   31 Dec 2013 11:24:55 -  1.41
+++ OpenBSD/PkgAdd.pm   31 Dec 2013 12:13:07 -
@@ -1,7 +1,7 @@
 #! /usr/bin/perl
 
 # ex:ts=8 sw=4:
-# $OpenBSD: PkgAdd.pm,v 1.41 2013/12/31 11:24:55 espie Exp $
+# $OpenBSD: PkgAdd.pm,v 1.40 2013/12/25 14:38:15 espie Exp $
 #
 # Copyright (c) 2003-2010 Marc Espie es...@openbsd.org
 #
@@ -134,15 +134,11 @@ sub handle_options
$state-{do_faked} = 1;
} elsif (defined $state-opt('B')) {
$state-{destdir} = $state-opt('B');
-   } elsif (defined $ENV{'PKG_PREFIX'}) {
-   $state-{destdir} = $ENV{'PKG_PREFIX'};
}
if (defined $state-{destdir}) {
$state-{destdir}.='/';
-   $ENV{'PKG_DESTDIR'} = $state-{destdir};
} else {
$state-{destdir} = '';
-   delete $ENV{'PKG_DESTDIR'};
}
 
 
@@ -729,8 +729,6 @@ sub really_add
 #  $replacing = 1;
 #  }
$state-{replacing} = $replacing;
-
-   $ENV{'PKG_PREFIX'} = $state-{localbase};
 
my $handler = sub {
$state-{interrupted} = shift;
Index: OpenBSD/PkgCheck.pm
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/pkg_add/OpenBSD/PkgCheck.pm,v
retrieving revision 1.42
diff -u -p -r1.42 PkgCheck.pm
--- OpenBSD/PkgCheck.pm 25 Dec 2013 14:38:15 -  1.42
+++ OpenBSD/PkgCheck.pm 31 Dec 2013 12:13:16 -
@@ -316,15 +316,11 @@ sub handle_options
$self-{quick} = $self-opt('q');
if (defined $self-opt('B')) {
$self-{destdir} = $self-opt('B');
-   } elsif (defined $ENV{'PKG_PREFIX'}) {
-   $self-{destdir} = $ENV{'PKG_PREFIX'};
-   }
+   } 
if (defined $self-{destdir}) {
$self-{destdir} .= '/';
-   $ENV{'PKG_DESTDIR'} = $self-{destdir};
} else {
$self-{destdir} = '';
-   delete $ENV{'PKG_DESTDIR'};
}
 }
 
Index: OpenBSD/PkgCreate.pm
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/pkg_add/OpenBSD/PkgCreate.pm,v
retrieving revision 1.76
diff -u -p -r1.76 PkgCreate.pm
--- OpenBSD/PkgCreate.pm31 Dec 2013 11:21:10 -  1.76
+++ OpenBSD/PkgCreate.pm31 Dec 2013 12:13:24 -
@@ -198,9 +198,7 @@ sub handle_options
my $base = '/';
if (defined $state-opt('B')) {
$base = $state-opt('B');
-   } elsif (defined $ENV{'PKG_PREFIX'}) {
-   $base = $ENV{'PKG_PREFIX'};
-   }
+   } 
 
$state-{base} = $base;
 



Re: tedu old PKG_PREFIX

2013-12-31 Thread Landry Breuil
On Tue, Dec 31, 2013 at 01:19:32PM +0100, Marc Espie wrote:
 I think I put this in for compatibility with the old tools years ago.
 I don't think anyone still uses this, so this can probably die.
 
 (I have run a grep thru the ports tree and the man pages, no reference at all)
 
 okay ?

I think i sent you a very similar diff years ago that got forgotten, so
obviously ok.

Landry



Re: re(4): tedu some unused code

2013-12-31 Thread Chris Cappuccio
Brad Smith [b...@comstyle.com] wrote:
 tedu some unused code. it has never been enabled and will not be; to
 deal with a hardware defect for rare boards. unmaintained, untested, etc.
 want to get rid of it.
 
 Comments? OK?
 

If RE_DIAG wasn't being compiled in, then it should be removed. The BUGS
section of re(4) needs to be updated to reflect the fact that the driver
does not detect this condition.



Re: re(4): tedu some unused code

2013-12-31 Thread Brad Smith
On Tue, Dec 31, 2013 at 09:55:54AM -0800, Chris Cappuccio wrote:
 Brad Smith [b...@comstyle.com] wrote:
  tedu some unused code. it has never been enabled and will not be; to
  deal with a hardware defect for rare boards. unmaintained, untested, etc.
  want to get rid of it.
  
  Comments? OK?
  
 
 If RE_DIAG wasn't being compiled in, then it should be removed. The BUGS
 section of re(4) needs to be updated to reflect the fact that the driver
 does not detect this condition.

Good idea especially since it has never been enabled so the driver
has never been able to detect this defective hardware.


Index: sys/dev/ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.146
diff -u -p -r1.146 re.c
--- sys/dev/ic/re.c 25 Oct 2013 22:48:10 -  1.146
+++ sys/dev/ic/re.c 31 Dec 2013 00:49:27 -
@@ -197,10 +197,6 @@ void   re_setup_intr(struct rl_softc *, in
 intre_wol(struct ifnet*, int);
 #endif
 
-#ifdef RE_DIAG
-intre_diag(struct rl_softc *);
-#endif
-
 struct cfdriver re_cd = {
0, re, DV_IFNET
 };
@@ -615,190 +611,6 @@ re_reset(struct rl_softc *sc)
CSR_WRITE_1(sc, RL_LDPS, 1);
 }
 
-#ifdef RE_DIAG
-
-/*
- * The following routine is designed to test for a defect on some
- * 32-bit 8169 cards. Some of these NICs have the REQ64# and ACK64#
- * lines connected to the bus, however for a 32-bit only card, they
- * should be pulled high. The result of this defect is that the
- * NIC will not work right if you plug it into a 64-bit slot: DMA
- * operations will be done with 64-bit transfers, which will fail
- * because the 64-bit data lines aren't connected.
- *
- * There's no way to work around this (short of talking a soldering
- * iron to the board), however we can detect it. The method we use
- * here is to put the NIC into digital loopback mode, set the receiver
- * to promiscuous mode, and then try to send a frame. We then compare
- * the frame data we sent to what was received. If the data matches,
- * then the NIC is working correctly, otherwise we know the user has
- * a defective NIC which has been mistakenly plugged into a 64-bit PCI
- * slot. In the latter case, there's no way the NIC can work correctly,
- * so we print out a message on the console and abort the device attach.
- */
-
-int
-re_diag(struct rl_softc *sc)
-{
-   struct ifnet*ifp = sc-sc_arpcom.ac_if;
-   struct mbuf *m0;
-   struct ether_header *eh;
-   struct rl_rxsoft*rxs;
-   struct rl_desc  *cur_rx;
-   bus_dmamap_tdmamap;
-   u_int16_t   status;
-   u_int32_t   rxstat;
-   int total_len, i, s, error = 0, phyaddr;
-   u_int8_tdst[] = { 0x00, 'h', 'e', 'l', 'l', 'o' };
-   u_int8_tsrc[] = { 0x00, 'w', 'o', 'r', 'l', 'd' };
-
-   DPRINTF((inside re_diag\n));
-   /* Allocate a single mbuf */
-
-   MGETHDR(m0, M_DONTWAIT, MT_DATA);
-   if (m0 == NULL)
-   return (ENOBUFS);
-
-   /*
-* Initialize the NIC in test mode. This sets the chip up
-* so that it can send and receive frames, but performs the
-* following special functions:
-* - Puts receiver in promiscuous mode
-* - Enables digital loopback mode
-* - Leaves interrupts turned off
-*/
-
-   ifp-if_flags |= IFF_PROMISC;
-   sc-rl_testmode = 1;
-   re_reset(sc);
-   re_init(ifp);
-   sc-rl_flags |= RL_FLAG_LINK;
-   if (sc-sc_hwrev == RL_HWREV_8139CPLUS)
-   phyaddr = 0;
-   else
-   phyaddr = 1;
-
-   re_miibus_writereg((struct device *)sc, phyaddr, MII_BMCR,
-   BMCR_RESET);
-   for (i = 0; i  RL_TIMEOUT; i++) {
-   status = re_miibus_readreg((struct device *)sc,
-   phyaddr, MII_BMCR);
-   if (!(status  BMCR_RESET))
-   break;
-   }
-
-   re_miibus_writereg((struct device *)sc, phyaddr, MII_BMCR,
-   BMCR_LOOP);
-   CSR_WRITE_2(sc, RL_ISR, RL_INTRS);
-
-   DELAY(10);
-
-   /* Put some data in the mbuf */
-
-   eh = mtod(m0, struct ether_header *);
-   bcopy ((char *)dst, eh-ether_dhost, ETHER_ADDR_LEN);
-   bcopy ((char *)src, eh-ether_shost, ETHER_ADDR_LEN);
-   eh-ether_type = htons(ETHERTYPE_IP);
-   m0-m_pkthdr.len = m0-m_len = ETHER_MIN_LEN - ETHER_CRC_LEN;
-
-   /*
-* Queue the packet, start transmission.
-*/
-
-   CSR_WRITE_2(sc, RL_ISR, 0x);
-   s = splnet();
-   IFQ_ENQUEUE(ifp-if_snd, m0, NULL, error);
-   re_start(ifp);
-   splx(s);
-   m0 = NULL;
-
-   DPRINTF((re_diag: transmission started\n));
-
-   /* Wait for it to propagate through the chip */
-
-   DELAY(10);
-   for (i = 0; i  RL_TIMEOUT; i++) {
-   status = 

Re: em(4): Don't count RX overruns and missed packets as input errros

2013-12-31 Thread Brad Smith

On 31/12/13 5:50 AM, Mike Belopuhov wrote:

On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:

On 31/12/13 3:14 AM, Mark Kettenis wrote:


Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com

Don't count RX overruns and missed packets as inputs errors. They're
expected to increment when using MCLGETI.

OK?



These may be expected, but they're still packets that were not
received.  And it is useful to know about these, for example when
debugging TCP performance issues.



Well do we want to keep just the missed packets or both? Part of the
diff was inspired by this commit when I was looking at what counters
were incrementing..

for bge(4)..

revision 1.334
date: 2013/06/06 00:05:30;  author: dlg;  state: Exp;  lines: +2 -4;
dont count rx ring overruns as input errors. with MCLGETI controlling the
ring we expect to run out of rx descriptors as a matter of course, its not
an error.

ok mikeb@




it does screws up statistics big time.  does mpc counter follow rx_overruns?
why did we add them up both previously?


.e.g.

em0: Missed Packets = 1925
em0: RX overruns = 267
em0: Good Packets Rcvd = 22279749

this already wasn't being counted but for reference..

em0: Receive No Buffers = 24382

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: OpenBSD-current on MacBookPro9,2 Xorg acpilk-ed

2013-12-31 Thread Mark Kettenis
  I have the same symptoms on a MacbookAir5,1 running -current: boot up, run
  startx (gnome), wait a couple hours while X is running, eventually observe
  the screen is frozen (whatever was on the screen stays and no longer
  changes), ssh into the box, run top, notice Xorg in the 'acpilk' WAIT
  column. This is 100% reproducible, though the length of time before the
  freeze does not seem consistent. It happens whether or not I'm interacting
  with the machine at the time of the screen freeze. I encountered the
  freeze on 5.4-release as well, that is why I installed -current. It
  happens when I using gdm and when I don't use it. It happens when I'm use
  gnome and when I use fvwm instead.

  The brightness keys do not function, neither in X nor while on the
  console.

  Here are my dmesg (identical to dmesg.boot), .xinitrc, xorg.0.log, ps -axk
  -Owchan, and top output.

Bet it disappears when you disable acpivout.  Might also fix the problem
with the brightness keys.

  == dmesg ==

  OpenBSD 5.4-current (GENERIC.MP) #211: Sun Dec 22 14:18:30 MST 2013
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  RTC BIOS diagnostic error
  dfclock_battery,ROM_cksum,memory_size,fixed_disk,invalid_time
  real mem = 8475713536 (8083MB)
  avail mem = 8241897472 (7860MB)
  mainbus0 at root
  bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (54 entries)
  bios0: vendor Apple Inc. version MBA51.88Z.00EF.B02.1211271028 date
  11/27/2012
  bios0: Apple Inc. MacBookAir5,1
  acpi0 at bios0: rev 2
  acpi0: sleep states S0 S3 S4 S5
  acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT
  SSDT SSDT SSDT SSDT SSDT DMAR MCFG
  acpi0: wakeup devices P0P2(S4) PEG2(S4) EC__(S4) HDEF(S4) RP02(S4)
  ARPT(S4) RP05(S4) EHC1(S4) EHC2(S4) XHC1(S4) ADP1(S4) LID0(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-3667U CPU @ 2.00GHz, 1896.01 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,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  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.1.2, IBE
  cpu1 at mainbus0: apid 2 (application processor)
  cpu1: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.70 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,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  cpu1: 256KB 64b/line 8-way L2 cache
  cpu1: smt 0, core 1, package 0
  cpu2 at mainbus0: apid 1 (application processor)
  cpu2: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.70 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,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  cpu2: 256KB 64b/line 8-way L2 cache
  cpu2: smt 1, core 0, package 0
  cpu3 at mainbus0: apid 3 (application processor)
  cpu3: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 1895.70 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,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  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
  ioapic0: misconfigured as apic 0, remapped to apid 2
  acpiec0 at acpi0
  acpimcfg0 at acpi0 addr 0xe000, bus 0-153
  acpiprt0 at acpi0: bus 0 (PCI0)
  acpiprt1 at acpi0: bus -1 (P0P2)
  acpiprt2 at acpi0: bus -1 (PEG2)
  acpiprt3 at acpi0: bus 2 (RP02)
  acpiprt4 at acpi0: bus 3 (RP05)
  acpicpu0 at acpi0: C3, C1, PSS
  acpicpu1 at acpi0: C3, C1, PSS
  acpicpu2 at acpi0: C3, C1, PSS
  acpicpu3 at acpi0: C3, C1, PSS
  acpibat0 at acpi0: BAT0 model 3545797981023400290 type
  3545797981528607052 oem 3545797981528673619
  acpiac0 at acpi0: AC unit offline
  acpibtn0 at acpi0: LID0
  acpibtn1 at acpi0: PWRB
  acpibtn2 at acpi0: SLPB
  acpivideo0 at acpi0: IGPU
  acpivout0 at acpivideo0: DD02
  cpu0: Enhanced SpeedStep 1896 MHz: speeds: 2001, 2000, 1900, 1800, 1700,
  1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
  memory map conflict