Re: arc4random unexpected results
On 03/24/18 21:27, Mike Burns wrote:
On 2018-03-24 21.05.56 -0500, Edgar Pettijohn wrote:
#include
#include
#include
int
main(void)
{
uint32_t n = arc4random();
printf("arc4random %d\n", n);
printf("abs %d\n", abs(n));
return 0;
}
Which is well and good. However, I get the following output.
laptop$ ./a.out
arc4random 247165650
abs 247165650
laptop$ ./a.out
arc4random 2012715611
abs 2012715611
laptop$ ./a.out
arc4random 222644175
abs 222644175
laptop$ ./a.out
arc4random -843593186
abs 843593186
// -
#include
#include
#include
#include
int
main(void)
{
uint32_t n = arc4random();
printf("arc4random %"PRIu32"\n", n);
printf("arc4random with %%d %d\n", n);
printf("abs %d\n", abs(n));
return 0;
}
//
output:
~% ./a.out
arc4random 1647540484
arc4random with %d 1647540484
abs 1647540484
~% ./a.out
arc4random 3569752639
arc4random with %d -725214657
abs 725214657
More docs:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
At first Basic C didn't seem like a good answer, but I went back to the
printf() manual and found the miraculous %u. Which seems to have fixed
it as well. Thanks for this alternate.
Re: arc4random unexpected results
On 2018-03-24 21.05.56 -0500, Edgar Pettijohn wrote:
> #include
> #include
> #include
>
> int
> main(void)
> {
> uint32_t n = arc4random();
>
> printf("arc4random %d\n", n);
> printf("abs %d\n", abs(n));
>
> return 0;
> }
>
> Which is well and good. However, I get the following output.
>
> laptop$ ./a.out
> arc4random 247165650
> abs 247165650
> laptop$ ./a.out
> arc4random 2012715611
> abs 2012715611
> laptop$ ./a.out
> arc4random 222644175
> abs 222644175
> laptop$ ./a.out
> arc4random -843593186
> abs 843593186
// -
#include
#include
#include
#include
int
main(void)
{
uint32_t n = arc4random();
printf("arc4random %"PRIu32"\n", n);
printf("arc4random with %%d %d\n", n);
printf("abs %d\n", abs(n));
return 0;
}
//
output:
~% ./a.out
arc4random 1647540484
arc4random with %d 1647540484
abs 1647540484
~% ./a.out
arc4random 3569752639
arc4random with %d -725214657
abs 725214657
More docs:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
Re: arc4random unexpected results
Basic C.
> Take this example program:
>
> #include
> #include
> #include
>
> int
> main(void)
> {
> uint32_t n = arc4random();
>
> printf("arc4random %d\n", n);
> printf("abs %d\n", abs(n));
>
> return 0;
> }
>
> It gives the following warning when compiling:
>
> test.c:11:21: warning: taking the absolute value of unsigned type
> 'uint32_t' (aka 'unsigned int') has no effect [-Wabsolute-value]
> printf("abs %d\n", abs(n));
> ^
> test.c:11:21: note: remove the call to 'abs' since unsigned values
> cannot be negative
> printf("abs %d\n", abs(n));
> ^~~
>
> Which is well and good. However, I get the following output.
>
> laptop$ ./a.out
> arc4random 247165650
> abs 247165650
> laptop$ ./a.out
> arc4random 2012715611
> abs 2012715611
> laptop$ ./a.out
> arc4random 222644175
> abs 222644175
> laptop$ ./a.out
> arc4random -843593186
> abs 843593186
>
> So on the fourth try I got what appears to be a negative number back.
> I'm not sure if this is some printf() funny business or what. Please
> explain. In real life I don't intend on using this with printf() so If
> thats the case no worries. However, if not I need to know that my random
> number is positive. I also tried if (n < 0) etc.. and got similar warnings.
>
> Thanks in advance,
>
> Edgar
>
arc4random unexpected results
Take this example program:
#include
#include
#include
int
main(void)
{
uint32_t n = arc4random();
printf("arc4random %d\n", n);
printf("abs %d\n", abs(n));
return 0;
}
It gives the following warning when compiling:
test.c:11:21: warning: taking the absolute value of unsigned type
'uint32_t' (aka 'unsigned int') has no effect [-Wabsolute-value]
printf("abs %d\n", abs(n));
^
test.c:11:21: note: remove the call to 'abs' since unsigned values
cannot be negative
printf("abs %d\n", abs(n));
^~~
Which is well and good. However, I get the following output.
laptop$ ./a.out
arc4random 247165650
abs 247165650
laptop$ ./a.out
arc4random 2012715611
abs 2012715611
laptop$ ./a.out
arc4random 222644175
abs 222644175
laptop$ ./a.out
arc4random -843593186
abs 843593186
So on the fourth try I got what appears to be a negative number back.
I'm not sure if this is some printf() funny business or what. Please
explain. In real life I don't intend on using this with printf() so If
thats the case no worries. However, if not I need to know that my random
number is positive. I also tried if (n < 0) etc.. and got similar warnings.
Thanks in advance,
Edgar
[patch] autofs for OpenBSD
Hi This is the initial patch submission of autofs filesystem support for OpenBSD, which was originally written for FreeBSD and later ported to DragonFlyBSD and NetBSD. Autofs is a generic filesystem automounter filesystem, not limited to mounting NFS. This OpenBSD port actually started off with the NetBSD code rather than FreeBSD though all versions are quite similar except for the autofs filesystem code in kernel space. While I currently maintain it as an out-of-tree filesystem on GitHub, I'm aiming for this to get merged by OpentBSD. The initial patch is available from below in three formats. The patch applies to the current src as of March 24 (and builds on amd64). diff -aNur https://leaf.dragonflybsd.org/~tkusumi/diff/openbsd/OpenBSD-autofs-v1.patch git format-patch https://leaf.dragonflybsd.org/~tkusumi/diff/openbsd/0001-OpenBSD-autofs-v1.patch GitHub https://github.com/kusumi/src/tree/autofs-20180325 Online documentation and man pages for FreeBSD (which are also part of the patch) would/should work against OpenBSD with a few exceptions. Below links are FreeBSD autofs info you can find on the web. Note that FreeBSD autofs is not a port of Linux autofs which has existed for a long(er) time. Although they are quite similar in terms of features, there is no compatibility in configuration files and such, thus the same for OpenBSD and Linux. https://people.freebsd.org/~trasz/autofs.pdf https://wiki.freebsd.org/Automounter http://freebsdfoundation.blogspot.fi/2015/03/freebsd-from-trenches-using-autofs5-to_13.html --- How to use autofs (currently only enabled on amd64) 1. Build kernel (autofs enabled by default atm in sys/conf/GENERIC) and world. 2. Enable etc/rc.d/automountd and etc/rc.d/autounmountd via rcctl(8). 3. Create a character device /dev/autofs via /dev/MAKEDEV. 4. Write auto mount configuration(s) to /etc/auto_master. FreeBSD documentation should help, though configuration needed to do a simple NFS auto mounting is quite simple (2 lines basically - i.e. 1 line in /etc/auto_master to specify a configuration file for eithre direct or indirect map, and 1 line in that file to specify NFS mount details). 5. Run automount(8) command (no options needed) to mount autofs(5) based on /etc/auto_master contents, and confirm autofs(5) is mounted via mount(8) command. 6. Restart automountd(8) and autounmountd(8). This could be before or after running automount(8) command. 7. Access autofs(5) mount point, and see if auto mounting works. I've only tested with NFS with both direct/indirect mapping, which is probably what majority of people use autofs for, however the basic automounting mechanism is filesystem-agnostic. I'll write down some more details of newly added code. --- Newly added subsystems 1. sys/miscfs/autofs The autofs(5) filesystem catches some of the vnode operations, and notifies the user space daemon automountd(8) that auto mounting requests from user process have arrived. The character device /dev/autofs (with major# 98) is used as a communication channel between autofs(5) and automountd(8) daemon via ioctl(2). Once automountd(8) receives the request from autofs(5) filesystem, it attempts to mount a target filesystem which corresponds to the autofs(5) mount point accessed by the user process, based on what auto_master(5) (/etc/auto_master file) has. The actual mounting is done by a child process forked from automountd(8) using mount(8) and variants. 2. usr.sbin/autofs User space is basically the same as the FreeBSD code as well as DragonFlyBSD and NetBSD ports with minimum changes needed for OpenBSD. The changes mostly come from difference in library/syscall interface, FreeBSD specific syscalls, workaround code specific to OpenBSD, etc. The directory contains followings. * autmount(8) - a command to mount autofs(5) filesystem. * automountd(8) - a daemon to auto mount target filesystems specified in /etc/auto_master. * autounmountd(8) - a daemon to auto unmount the auto mounted filesystems if no longer used when the timer has expired. These executable binaries actually consist of a single inode, i.e. /usr/sbin/automountd and /usr/sbin/autounmountd are hardlinks to /usr/sbin/automount, and they do what they do by checking argv[0] in its main(). 3. etc/auto_master and etc/autofs/* etc/auto_master is a configuration file which describes relations between autofs(5) mount points and target filesystems to auto mount. As mentioned above, automountd(8) mounts filesystems based on this file. The auto_master(5) man page explains details of the format. etc/autofs/* are collection of scripts used by auto_master(5) when pre-defined special mappings are used. These are just copied from FreeBSD unless a script contains FreeBSD specific stuff (e.g. etc/autofs/special_media uses FreeBSD specific sysctl). 4. usr.sbin/fstyp Fstyp(8) is an utility to detect filesystem type of the given block device, and was originally added
Re: acpicmos(4) adding support for SystemCMOS OperationRegions
On Sat, Mar 24, 2018 at 12:04:06PM +0100, Mark Kettenis wrote:
> I have a HP laptop that unconditionally reads from a SystemCMOS
> OperationRegion. That's a bug in the AML; it should check whether the
> region is available before accessing it. But crashing is a bit harsh.
> There have been a couple of reports of such crashes in the past.
>
> Diff below adds the missing support. Would like to commit this
> shortly after unlock.
>
> ok?
>
Glad you tackled this. Thanks.
ok mlarkin
>
> Index: dev/acpi/acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.340
> diff -u -p -r1.340 acpi.c
> --- dev/acpi/acpi.c 19 Feb 2018 08:59:52 - 1.340
> +++ dev/acpi/acpi.c 24 Mar 2018 10:56:29 -
> @@ -2907,7 +2907,6 @@ const char *acpi_skip_hids[] = {
> "PNP0800", /* Microsoft Sound System Compatible Device */
> "PNP0A03", /* PCI Bus */
> "PNP0A08", /* PCI Express Bus */
> - "PNP0B00", /* AT Real-Time Clock */
> "PNP0C01", /* System Board */
> "PNP0C02", /* PNP Motherboard Resources */
> "PNP0C04", /* x87-compatible Floating Point Processing Unit */
> Index: dev/acpi/acpicmos.c
> ===
> RCS file: dev/acpi/acpicmos.c
> diff -N dev/acpi/acpicmos.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ dev/acpi/acpicmos.c 24 Mar 2018 10:56:29 -
> @@ -0,0 +1,90 @@
> +/* $OpenBSD$ */
> +/*
> + * Copyright (c) 2018 Mark Kettenis
> + *
> + * 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
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct acpicmos_softc {
> + struct device sc_dev;
> + struct aml_node *sc_node;
> +};
> +
> +int acpicmos_match(struct device *, void *, void *);
> +void acpicmos_attach(struct device *, struct device *, void *);
> +
> +struct cfattach acpicmos_ca = {
> + sizeof(struct acpicmos_softc), acpicmos_match, acpicmos_attach
> +};
> +
> +struct cfdriver acpicmos_cd = {
> + NULL, "acpicmos", DV_DULL
> +};
> +
> +const char *acpicmos_hids[] = {
> + "PNP0B00",
> + "PNP0B01",
> + "PNP0B02",
> + NULL
> +};
> +
> +int acpicmos_opreg_handler(void *, int, uint64_t, int, uint64_t *);
> +
> +int
> +acpicmos_match(struct device *parent, void *match, void *aux)
> +{
> + struct acpi_attach_args *aaa = aux;
> + struct cfdata *cf = match;
> +
> + return acpi_matchhids(aaa, acpicmos_hids, cf->cf_driver->cd_name);
> +}
> +
> +void
> +acpicmos_attach(struct device *parent, struct device *self, void *aux)
> +{
> + struct acpicmos_softc *sc = (struct acpicmos_softc *)self;
> + struct acpi_attach_args *aaa = aux;
> +
> + printf("\n");
> +
> + sc->sc_node = aaa->aaa_node;
> + aml_register_regionspace(sc->sc_node, ACPI_OPREG_CMOS,
> + sc, acpicmos_opreg_handler);
> +}
> +
> +
> +int
> +acpicmos_opreg_handler(void *cookie, int iodir, uint64_t address, int size,
> +uint64_t *value)
> +{
> + /* Only allow 8-bit access. */
> + if (size != 8 || address > 0xff)
> + return -1;
> +
> + if (iodir == ACPI_IOREAD)
> + *value = mc146818_read(NULL, address);
> + else
> + mc146818_write(NULL, address, *value);
> +
> +
> + return 0;
> +}
> Index: dev/acpi/files.acpi
> ===
> RCS file: /cvs/src/sys/dev/acpi/files.acpi,v
> retrieving revision 1.39
> diff -u -p -r1.39 files.acpi
> --- dev/acpi/files.acpi 14 Mar 2018 18:52:16 - 1.39
> +++ dev/acpi/files.acpi 24 Mar 2018 10:56:29 -
> @@ -31,6 +31,11 @@ device acpibtn
> attach acpibtn at acpi
> file dev/acpi/acpibtn.c acpibtn
>
> +# cmos device
> +device acpicmos
> +attach acpicmos at acpi
> +file dev/acpi/acpicmos.c acpicmos
> +
> # cpu device
> device acpicpu
> attach acpicpu at acpi
> Index: arch/amd64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.451
> diff -u -p -r1.451 GENERIC
> --- arch/amd64/con
[patch] 6.3 /etc/examples/relayd.conf
Hi tech@,
One more quick change to the TLS acceleration example in
/etc/examples/relayd.conf. The man page recommends match header set
"Keep-Alive" value "$TIMEOUT" while the example in
/etc/examples/relayd.conf uses match request header set "Connection"
value "close"
This tripped me up once when I forgot to make this change and couldn't
understand why I was running into difficulty with the connection
closing prematurely. Diff below
Thanks,
Matt
Index: relayd.conf
===
RCS file: /cvs/src/etc/examples/relayd.conf,v
retrieving revision 1.3
diff -u -p -r1.3 relayd.conf
--- relayd.conf 12 Dec 2014 10:05:09 - 1.3
+++ relayd.conf 24 Mar 2018 14:02:21 -
@@ -40,13 +40,15 @@ http protocol https {
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
- match request header set "Connection" value "close"
+ match header set "Keep-Alive" value "$TIMEOUT"
+
+ match query hash "sessid"
# Various TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# tls { no tlsv1.0, ciphers HIGH }
-# tls session cache disable
+# tls no session tickets
}
relay wwwtls {
[patch] 6.3 relayd.conf(5) man page correction
Hi tech@,
One small correction to relayd.conf(5). In the examples section for
TLS acceleration, the configuration option match hash "sessid" results
in a syntax error. Diff below.
Thanks,
Matt
Index: relayd.conf.5
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.182
diff -u -p -r1.182 relayd.conf.5
--- relayd.conf.5 29 Nov 2017 21:17:51 - 1.182
+++ relayd.conf.5 24 Mar 2018 13:47:17 -
@@ -1484,7 +1484,6 @@ http protocol "https" {
match header set "Keep-Alive" value "$TIMEOUT"
match query hash "sessid"
- match hash "sessid"
pass
block path "/cgi-bin/index.cgi" value "*command=*"
acpicmos(4) adding support for SystemCMOS OperationRegions
I have a HP laptop that unconditionally reads from a SystemCMOS
OperationRegion. That's a bug in the AML; it should check whether the
region is available before accessing it. But crashing is a bit harsh.
There have been a couple of reports of such crashes in the past.
Diff below adds the missing support. Would like to commit this
shortly after unlock.
ok?
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.340
diff -u -p -r1.340 acpi.c
--- dev/acpi/acpi.c 19 Feb 2018 08:59:52 - 1.340
+++ dev/acpi/acpi.c 24 Mar 2018 10:56:29 -
@@ -2907,7 +2907,6 @@ const char *acpi_skip_hids[] = {
"PNP0800", /* Microsoft Sound System Compatible Device */
"PNP0A03", /* PCI Bus */
"PNP0A08", /* PCI Express Bus */
- "PNP0B00", /* AT Real-Time Clock */
"PNP0C01", /* System Board */
"PNP0C02", /* PNP Motherboard Resources */
"PNP0C04", /* x87-compatible Floating Point Processing Unit */
Index: dev/acpi/acpicmos.c
===
RCS file: dev/acpi/acpicmos.c
diff -N dev/acpi/acpicmos.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/acpi/acpicmos.c 24 Mar 2018 10:56:29 -
@@ -0,0 +1,90 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2018 Mark Kettenis
+ *
+ * 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
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct acpicmos_softc {
+ struct device sc_dev;
+ struct aml_node *sc_node;
+};
+
+intacpicmos_match(struct device *, void *, void *);
+void acpicmos_attach(struct device *, struct device *, void *);
+
+struct cfattach acpicmos_ca = {
+ sizeof(struct acpicmos_softc), acpicmos_match, acpicmos_attach
+};
+
+struct cfdriver acpicmos_cd = {
+ NULL, "acpicmos", DV_DULL
+};
+
+const char *acpicmos_hids[] = {
+ "PNP0B00",
+ "PNP0B01",
+ "PNP0B02",
+ NULL
+};
+
+intacpicmos_opreg_handler(void *, int, uint64_t, int, uint64_t *);
+
+int
+acpicmos_match(struct device *parent, void *match, void *aux)
+{
+ struct acpi_attach_args *aaa = aux;
+ struct cfdata *cf = match;
+
+ return acpi_matchhids(aaa, acpicmos_hids, cf->cf_driver->cd_name);
+}
+
+void
+acpicmos_attach(struct device *parent, struct device *self, void *aux)
+{
+ struct acpicmos_softc *sc = (struct acpicmos_softc *)self;
+ struct acpi_attach_args *aaa = aux;
+
+ printf("\n");
+
+ sc->sc_node = aaa->aaa_node;
+ aml_register_regionspace(sc->sc_node, ACPI_OPREG_CMOS,
+ sc, acpicmos_opreg_handler);
+}
+
+
+int
+acpicmos_opreg_handler(void *cookie, int iodir, uint64_t address, int size,
+uint64_t *value)
+{
+ /* Only allow 8-bit access. */
+ if (size != 8 || address > 0xff)
+ return -1;
+
+ if (iodir == ACPI_IOREAD)
+ *value = mc146818_read(NULL, address);
+ else
+ mc146818_write(NULL, address, *value);
+
+
+ return 0;
+}
Index: dev/acpi/files.acpi
===
RCS file: /cvs/src/sys/dev/acpi/files.acpi,v
retrieving revision 1.39
diff -u -p -r1.39 files.acpi
--- dev/acpi/files.acpi 14 Mar 2018 18:52:16 - 1.39
+++ dev/acpi/files.acpi 24 Mar 2018 10:56:29 -
@@ -31,6 +31,11 @@ device acpibtn
attach acpibtn at acpi
file dev/acpi/acpibtn.c acpibtn
+# cmos device
+device acpicmos
+attach acpicmos at acpi
+file dev/acpi/acpicmos.c acpicmos
+
# cpu device
device acpicpu
attach acpicpu at acpi
Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.451
diff -u -p -r1.451 GENERIC
--- arch/amd64/conf/GENERIC 14 Mar 2018 18:52:16 - 1.451
+++ arch/amd64/conf/GENERIC 24 Mar 2018 10:56:29 -
@@ -44,6 +44,7 @@ acpiac* at acpi?
acpibat* at acpi?
acpibtn* at acpi?
acpicpu* at acpi?
+acpicmos* at acpi?
acpidock* at acpi?
acpiec*at acpi?
acpiprt* at acpi?
Index: arch/amd64/conf/RA
Re: iwm0 doesn't connect automatically after reboot
On Sat, Mar 24, 2018 at 07:36:07AM +0100, Mischa wrote: > Hi All, > > I have been running the last couple of 6.3-beta snapshots on both a Lenovo > x270 with Intel 8265 and an apu2 with 7260. > On both machines iwm0 doesn't come up automatically after a reboot and I have > to issue /etc/netstat iwm0 a couple of times in order for it to get an IP > address and stay active. > > This on the following snapshots: > OpenBSD x270.local.high5.nl 6.3 GENERIC.MP#68 amd64 > OpenBSD x270.local.high5.nl 6.3 GENERIC.MP#80 amd64 > OpenBSD x270.local.high5.nl 6.3 GENERIC.MP#102 amd64 > > What can I capture to troubleshoot this further? For starters, you could enable 'ifconfig iwm0 debug' and then for each operation you're doing show us what it prints to /var/log/messages. > ### dmesg from Lenevo x270 ### > OpenBSD 6.3 (GENERIC.MP) #102: Fri Mar 23 00:06:18 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16810577920 (16031MB) > avail mem = 16294031360 (15539MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xca6ce000 (62 entries) > bios0: vendor LENOVO version "R0IET46W (1.24 )" date 10/23/2017 > bios0: LENOVO 20HNCTO1WW > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT > BATB SLIC SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM ASF! FPDT UEFI > acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4) > RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4) > RP12(S4) RP13(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 1296.23 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,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 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 1062.81 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > 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-7500U CPU @ 2.70GHz, 997.69 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > 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-7500U CPU @ 2.70GHz, 997.69 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 1, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins > acpimcfg0 at acpi0 addr 0xf000, bus 0-63 > acpiec0 at acpi0 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 2 (RP01) > acpiprt2 at acpi0: bus -1 (RP02) > acpiprt3 at acpi0: bus 3 (RP03) > acpiprt4 at acpi0: bus -1 (RP04) > acpiprt5 at acpi0: bus -1 (RP05) > acpiprt6 at acpi0: bus -1 (RP06) > acpiprt7 at acpi0: bus -1 (RP07) > acpiprt8 at acpi0: bus -1 (RP08) > acpiprt9 at acpi0: bus -1 (RP09) > acpiprt10 at acpi0: bus -1 (RP10) > acpiprt11 at acpi0: bus -1 (RP11) > acpiprt12 at a
