Re: amd64 Intel cpu microcode

[Lampshade]

Does microcode updated that way is being
erased after each reboot?

From: "Theo de Raadt" 
To: tech@openbsd.org; 
Date: 1:09 Niedziela 2018-01-14
Subject: amd64 Intel cpu microcode

> Patrick and others commited amd64 Intel cpu microcode update code
> over the last few days.  The approach isn't perfect, but it is good
> enough for a start.  I want to explain the situation.
> 
> When you fw_update, you'll get the firmware files.
> 
> Upon a reboot, it will attempt to update the microcode on your cpus.
> Maybe there isn't a new microcode.  Maybe your BIOS has a copy of
> the microcode and installs it before booting OpenBSD.
> 
> This firmware installation is done a little late.  Doing it better
> will require some work in the bootblocks to find the firmware files,
> but time is a bit short to do that right now.
> 
> The branch-target-cache flushing features added in new microcode
> are not being used yet.  There is more code which has to be written,
> but again other work is happening first.
> 
> Also, Intel is saying their new microcodes sucks and people should
> wait a little.
> 
> "Hi, my name is Intel and I'm an cheating speculator".
> 
> 

Re: Intel CPU Security Flaw Kernel Memory Leak (no microcode update) SW workarounds only

[Lampshade]

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

or shortened URLs:
goo.gl/ndYk6H
goo.gl/kTfwfn

Od: "Tom Smyth" 
Do: tech@openbsd.org; 
Temat: Intel CPU Security Flaw Kernel Memory Leak (no microcode update) SW 
workarounds only

> Hello all,
> 
> Thought I might mention this CPU Flaw that apparently allows
> unauthorised viewing
> of kernel Memory
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
> 
> apparently there is no microcode update to fix it, and that software
> only workarounds with heavy performance penalties are the only
> security fixes available
> 
> I hope this helps
> 
> Tom Smyth
> 
> 

Re: ffs/msdosfs: Flush cache when updating mount to R/O

[Lampshade]

 What if somebody remounts
 from default options
 (metadata: sync, data: nosync)
 to fully synced
 (metadata: sync, data:   sync)
 
 Example:
# mount | grep /home 
/dev/sd1h on /home type ffs (local)
# /sbin/mount -u -o sync /home   
# mount | grep /home 
/dev/sd1h on /home type ffs (local, synchronous)

 Should this flush cache?

Re: usb disk dirty after every reboot

[Lampshade]

>I found a few cases, where we should send a cache flush but don't. 
>Unfortunately, none of these cases explain the problem seen by
>Jan and Darren.
>The cases I have found are:
>* When a R/W mount is updated to R/O. I will send patches for this in a 
>separate mail.
>* When a R/W mount is unmounted but there is still another partition from the 
>same disk mounted.
>* When sync(2)  is called. Though I am not 100% sure if we really want
> to do a cache flush for every sync. Thoughts?

What if somebody remounts
from normal options
(metadata: sync, data: async)
to fully synced
(metadata: sync, data: sync)

Example:
# mount | grep home 
/dev/sd1h on /home type ffs (local, noatime, nodev, nosuid)
# /sbin/mount -u -o sync,rw,nodev,nosuid,noatime /home 
# mount | grep home
/dev/sd1h on /home type ffs (local, noatime, nodev, nosuid, synchronous)

Should this flush cache for this particular filesystem?

Re: Help me testing the netlock

[Lampshade]

> > panic: rw_enter: netlock locking against myself
> 
> Your tree is not up-to-date, you're missing sys/net/route.c r1.332.

My bad.
With updated sources I have tested this for few minutes
and I don't encountered any kernel panic.
CVS sync, wget to download base system from mirror,
browsing web with Chromium (with privoxy and relayd).
I have amd64 on laptop.

Re: Help me testing the netlock

[Lampshade]

panic: rw_enter: netlock locking against myself

 TIDPID UIDPRFLAGS
 12705 12705 1041 0x23
*62630 62630 1000 0x32
   
PFLAGS CPU COMMAND
0  1chrome
0  0 Xorg

panic()
rw_enter()
rw_enter_write()
rw_enter_timer()
timeout_run()
softlock()
softintr_dispatch()
Xsoftlock()
---interrupt---
param.c at 0x8
Bad frame pointer: 0x800032d78 b14

Above was similar with ddbcpu 0
Following machine
ddbcpu 1

x86_ipi_handler()
Xresume_lapic_ipi_
---interrupt---
__mp_lock()
syscall()
---syscall (number 27)---
end of kernel

Re: Kernel panic pf.c during halting

[Lampshade]

My system don't started Tor daemon and dnscrypt-proxy
daemon and still I get this kernel panic.
I still use Unbound.
I still have pf rules for transparent
proxying. I only disabled Tor client.

I was thinking about simplify more before I answer, but
dhill () mindcry ! org posted similar bug to bug mailing list.
I will post further messages to his bug report.

I have complete list of processes (ps auxww) just before
I executed halt -p, because I have written script to do so
every time I turn off or reboot OpenBSD.

USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
root 1  0.0  0.0   444   560 ??  Is10:35AM0:01.00 /sbin/init
root 23793  0.0  1.1 409972 67552 ??  Ss10:35AM0:00.22 
/sbin/mount_mfs -o rw -s 819200 -o nosuid -o nodev swap /tmp
root 86233  0.0  0.0 20852   328 ??  Ss10:35AM0:00.01 
/sbin/mount_mfs -o rw -s 40960 -o nosuid -o nodev swap /var/log
root  5733  0.0  0.0   608   476 ??  Is10:35AM0:00.01 dhclient: 
bge0 [priv] (dhclient)
_dhcp91232  0.0  0.0   736   680 ??  Isp   10:35AM0:00.07 dhclient: 
bge0 (dhclient)
_syslogd 41780  0.0  0.0   956  1480 ??  Sp10:36AM0:00.03 
/usr/sbin/syslogd
root 18297  0.0  0.0   956  1292 ??  Isp   10:36AM0:00.00 syslogd: 
[priv] (syslogd)
root 38573  0.0  0.0   604   612 ??  Is10:36AM0:00.02 pflogd: 
[priv] (pflogd)
_pflogd  35694  0.0  0.0   668   436 ??  Sp10:36AM0:00.36 pflogd: 
[running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
_unbound 90885  0.0  0.2  9852 10852 ??  Is10:36AM0:00.25 unbound -c 
/var/unbound/etc/unbound.conf
_relayd  74560  0.0  0.0  1176  2836 ??  Ip10:36AM0:00.01 relayd: hce 
(relayd)
root 18863  0.0  0.1  1568  3408 ??  Is10:36AM0:00.02 
/usr/sbin/relayd
_relayd  50673  0.0  0.0  1204  2908 ??  Ip10:36AM0:00.02 relayd: pfe 
(relayd)
_relayd  70251  0.0  0.1  1308  3280 ??  Ip10:36AM0:00.03 relayd: relay 
(relayd)
_relayd  13920  0.0  0.0  1136  2876 ??  Ip10:36AM0:00.02 relayd: ca 
(relayd)
_relayd  97513  0.0  0.0  1148  2856 ??  Ip10:36AM0:00.02 relayd: ca 
(relayd)
_relayd  68353  0.0  0.0  1140  2860 ??  Ip10:36AM0:00.02 relayd: ca 
(relayd)
_relayd  98221  0.0  0.1  1312  3280 ??  Ip10:36AM0:00.03 relayd: relay 
(relayd)
_relayd  52134  0.0  0.1  1316  3288 ??  Ip10:36AM0:00.03 relayd: relay 
(relayd)
_sndio   12325  0.0  0.0   500  1188 ??  I

Re: Kernel panic pf.c during halting

[Lampshade]

> 
> > The key is really being able to reproduce the problem, Lampshade do you 
> > already know which service or config triggers this panic?  Could you try
> > to figure out by simplifying your setup?
> 
> I don't know.
> Problem is that even with most complicated config it happens a few times
> in a month at most.
> I will try to simplify config.
> From today I don't start Tor clients. I hope crash will happen and then
> I would simplify more.

Re: Kernel panic pf.c during halting

[Lampshade]

Another crash.
I should note that this kernel is build by me with patches
to GENERIC (HZ from 100 to 300), pci and acpi files.
Both previous reports were from
official kernel builds (snapshots).
Source code is based on:
cvs -d$CVSROOT up -D  "2016-08-26 12:45" -Pd

As always with this panic I issued command:
sudo halt -p

Stopped at Debugger+0x9: leave
TID  PID   UID PRFLAGS
51607 51607  53   0x10
PFLAGS  CPU  COMMAND
01  unbound

main message from debugger is the same as previous
panic()
__assert()
pf_state_key_unref()
pf_pkt_unlink_state_key()
and so on as previous

machine ddbcpu 1  - slightly changed,
but still the same 3 function calls before crash

x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
---interrupt---
__mp_lock() at __mp_lock+0x48
syscall() at syscall+0x2e5
---syscall (number 73) ---
end of kernel
end trace from

Re: Kernel panic pf.c during halting

[Lampshade]

> Are you using the tor TRANS_PF stuff for transparent proxying?
Yes, I am.

# grep -v -e ^# -e Password /etc/tor/instancjaDlaFF.conf 
user _tor_do_FF
RunAsDaemon 1
DataDirectory /home/_tor_do_FF/
Log notice file /home/_tor_do_FF/logs/log
SocksPort 0
TransListenAddress 172.10.0.2:9040
TransPort 9040
DNSListenAddress 172.10.0.2:9053
DNSPort 9053
ControlSocket /home/_tor_do_FF/con_socket.socket

two lines of log file:
 [notice] Opening DNS listener on 172.10.0.2:9053
 [notice] Opening Transparent pf/netfilter listener on 172.10.0.2:9040
***
# grep -v -e ^# -e Password /etc/tor/instancjaDlaDNS.conf  
user _tor_do_dns
RunAsDaemon 1
DataDirectory /home/_tor_do_dns/
Log notice file /home/_tor_do_dns/logs/log
SocksPort 0
TransListenAddress 127.0.0.1:9040
TransPort 9040
DNSListenAddress   127.0.0.1:9053
DNSPort 9053
ExitNodes 
{AT},{BE},{CZ},{DK},{FI},{FR},{DE},{GR},{HU},{IE},{IT},{LU},{NL},{NO},{PL},{PT},{SK},{SI},{EA},{SE},{CH},{GB}

two lines of log file:
[notice] Opening DNS listener on 127.0.0.1:9053
[notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040

Re: Kernel panic pf.c during halting

[Lampshade]

> 
> > Which daemons do you use on this machine?
> 
> # rcctl ls on
> check_quotas
> cron
> dnscrypt_proxy_one
> dnscrypt_proxy_second
> messagebus
> pf
> pflogd
> relayd
> sndiod
> syslogd
> unbound
> # rcctl ls started   
> cron
> dnscrypt_proxy_one
> dnscrypt_proxy_second
> messagebus
> pflogd
> relayd
> sndiod
> syslogd
> unbound
> # 
> 
> I use also www/privoxy and tor.

Re: Kernel panic pf.c during halting

[Lampshade]

> On 22/06/16(Wed) 00:53, Lampshade wrote:
> > I don't know if this is enough, but I haven't had access to web
> > using other device when kernel panicked.
> 
> What's the output of ifconfig and route -n show for this system?
> 

Sorry for silence.
Kernel panic happened only once in June and this is all.
I understand if you allocate time for more frequent bugs than this.

# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
index 3 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr b8:88:e3:d3:08:70
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT 
full-duplex,master,rxpause,txpause)
status: active
inet 192.168.0.10 netmask 0xff00 broadcast 192.168.0.255
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
pair1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 1 mtu 1500
lladdr fe:e1:ba:d0:d0:14
description: An isolated Ethernet
index 4 priority 0 llprio 3
patch: pair2
groups: pair
media: Ethernet autoselect
status: active
inet 172.10.0.1 netmask 0xff00 broadcast 172.10.0.255
pair2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d1:a4:80
index 5 priority 0 llprio 3
patch: pair1
groups: pair
media: Ethernet autoselect
status: active
inet 172.10.0.2 netmask 0xff00 broadcast 172.10.0.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
index 6 priority 0 llprio 3
groups: pflog

# route -n show  
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default192.168.0.1UGS4 1057 - 8 bge0 
224/4  127.0.0.1  URS00 32768 8 lo0  
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHl4 4021 32768 1 lo0  
172.10.0/24172.10.0.2 UC 00 - 4 pair2
172.10.0.2 fe:e1:ba:d1:a4:80  UHLl   00 - 1 pair2
172.10.0.255   172.10.0.2 UHb00 - 1 pair2
192.168.0/24   192.168.0.10   UC 10 - 4 bge0 
192.168.0.124:76:7d:20:55:f9  UHLc   2  124 - 4 bge0 
192.168.0.10   b8:88:e3:d3:08:70  UHLl   0  151 - 1 bge0 
192.168.0.255  192.168.0.10   UHb00 - 1 bge0 

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
::/96  ::1UGRS   0  
  0 32768 8 lo0  
::/104 ::1UGRS   0  
  0 32768 8 lo0  
::1::1UHl   14  
 14 32768 1 lo0  
::127.0.0.0/104::1UGRS   0  
  0 32768 8 lo0  
::224.0.0.0/100::1UGRS   0  
  0 32768 8 lo0  
::255.0.0.0/104::1UGRS   0  
  0 32768 8 lo0  
:::0.0.0.0/96  ::1UGRS   0  
  0 32768 8 lo0  
2002::/24  ::1UGRS   0  
  0 32768 8 lo0  
2002:7f00::/24 ::1UGRS   0  
  0 32768 8 lo0  
2002:e000::/20 ::1UGRS   0  
  0 32768 8 lo0  
2002:ff00::/24 ::1UGRS   0  
  0 32768 8 lo0  
fe80::/10  ::1UGRS   0  
  0 32768 8 lo0  
fec0::/10  ::1UGRS   0  
  0 32768 8 lo0  
fe80::1%lo0fe80::1%lo0UHl0  
  0 32768 1 lo0  
ff01::/16  ::1UGRS   1  
  1 32768 8 lo0  
ff01::%lo0/32  ::1Um 0  
  1 32768 4 lo0  
ff02::/16  ::1UGRS   1  
  1 32768 8 lo0  
ff02::%lo0/32  ::1Um 0  
  1 32768 4 lo0  

# cat /etc/hostname.bge0  
dhcp
# cat /etc/hostname.pair1 

Kernel panic pf.c during halting

[Lampshade]

I don't know if this is enough, but I haven't had access to web
using other device when kernel panicked.

sysctl kern.version  
kern.version=OpenBSD 6.0-beta (GENERIC.MP) #2198: Sun Jun 19 11:58:45 MDT 2016
r...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

It happened after command:
sudo halt -p

What has been written during panic

panic:kernel diagnostic assertion "(sk->inp == NULL) || (sk->inp->inp_pf_sk == 
NULL)"
failed: file "../../../net/pf.c", line 6870

Stopped at Debugger+0x9: leave
TID PID UID
PRFLAGS 0x100010
PFLAGS 0x80
CPU 0
COMMAND pflogd

Debugger() at Debugger+0x9
panic() at panic+0xfe
__assert() at assert+0x25
pf_state_key_unref() at pf_state_key_unref+0xc6
pf_pkt_unlink_state_key() at pf_pkt_unlink_state_key+0x15
m_free() at m_free+0xa0
sbdrop() at sbdrop+0x80
sbflush() at sbflush+0x1f
sbrelease() at sbrelease+0x11
sorflush() at sorflush+0x17c
sofree() at sofree+0xbc
soclose() at soclose+0x92
soo_close() at soo_close+0x1e (or0x1c)
fdrop() at fdrop+0x2c
end trace frame: 0x800032d01da0, count: 0

Re: Get PCI resources from ACPI

[Lampshade]

Firstly diff, secondly all dmesg from unmodified and modified with yours patch 
kernel.
OpenBSD-current amd64 with source code updated using
cvs -d$CVSROOT up -D "2016-01-07 05:00" -Pd

diff -u  /katalogDmesg/nieZmodyfikowaneAcpiMark/dmesg.log  
/katalogDmesg/zmodyfikowaneAcpiMark/dmesg.log


--- /katalogDmesg/nieZmodyfikowaneAcpiMark/dmesg.log   Thu Jan  7 19:20:03 
2016
+++ /katalogDmesg/zmodyfikowaneAcpiMark/dmesg.log   Thu Jan  7 18:42:46 2016
@@ -1,7 +1,7 @@
-OpenBSD 5.9-beta (GENERIC.MP) #2: Thu Jan  7 19:16:41 CET 2016
-
r...@r2d2.my.domain:/usr/originalKernel/src/sys/arch/amd64/compile/GENERIC.MP
+OpenBSD 5.9-beta (GENERIC.MP) #1: Thu Jan  7 18:40:17 CET 2016
+
o...@r2d2.my.domain:/usr/originalKernel/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 632704 (6018MB)
-avail mem = 6115713024 (5832MB)
+avail mem = 6115708928 (5832MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
@@ -16,7 +16,7 @@
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
-cpu0: Intel(R) Pentium(R) CPU B960 @ 2.20GHz, 2195.31 MHz
+cpu0: Intel(R) Pentium(R) CPU B960 @ 2.20GHz, 2195.36 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
@@ -30,6 +30,11 @@
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf000, bus 0-63
+bus 0
+extent `pcimem' (0x0 - 0x), flags=0
+ 0x0 - 0x9
+ 0xc - 0x9f9f
+ 0xfeb0 - 0x
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (P0P1)
 acpiprt2 at acpi0: bus 2 (RP01)


Dmesg from unmodified kernel

OpenBSD 5.9-beta (GENERIC.MP) #2: Thu Jan  7 19:16:41 CET 2016

r...@r2d2.my.domain:/usr/originalKernel/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 632704 (6018MB)
avail mem = 6115713024 (5832MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6df0 (39 entries)
bios0: vendor Acer version "V2.21" date 12/16/2013
bios0: Acer Aspire E1-531G
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT SSDT 
SSDT SSDT
acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S0) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(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) Pentium(R) CPU B960 @ 2.20GHz, 2195.31 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
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) Pentium(R) CPU B960 @ 2.20GHz, 2195.02 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus 3 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (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 -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(350@104 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@104 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpibat0 at acpi0: BAT1 model "Li_Ion_4000mA " serial 684 type Lion oem "SONY "
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpibtn2 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 2195 MHz: speeds: 2200, 2100, 2000, 1900, 1800, 1700, 
1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at 

Re: Mesa has broken r300/r600 (gallium) dri DSO

[Lampshade]

My answer is based on
OpenBSD-current dated 18-12-2015
amd64

Re: virtualization support

[Lampshade]

Sorry for newbie question, but I am curious 
and this hipervisor is new thing so there is no man pages yet.

I have read general classification of hypervisors on Wikipedia
and there are types: Type-1 and Type-2. 
I have also read about KVM on cern.ch's Wiki.
https://twiki.cern.ch/twiki/bin/view/Virtualization/KVM

What is the type of this hipervisor: Type-1 or Type-2? 
Is this hypervisor more similar to "micro"-hypervisor or to monolithic 
hypervisor?

I am interested in short answers, even if they were slightly oversimplified.