Re: OpenBSD guest hangs in vmd on -current host

[Ted Unangst]

Mike Larkin wrote:
> On Tue, Jul 18, 2017 at 09:36:12PM -0700, Max Parmer wrote:
> > 
> > >Synopsis:  OpenBSD guest hangs in vmd on -current host
> > >Category:  system
> > >Environment:
> > System  : OpenBSD 6.1
> > Details : OpenBSD 6.1-current (GENERIC.MP) #99: Mon Jul 17 16:53:49 
> > MDT 2017
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > When running an OpenBSD guest under vmd after a short time the guest 
> > will hang, the
> > corresponding vmd process will hit and stay at 99.9% CPU usage.
> > 
> > Examination with ktrace shows a pattern similar to the past reports 
> > from tedu@[1] and
> > Gregor Best[2] with the process spinning on kevent and gettime, excerpt:
> >  15607 vmd  RET   kevent 1  
> >  15607 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x121dae4dbd20) 
> >  
> >  15607 vmd  STRU  struct timespec { 20180.643241450 }   
> >  
> >  15607 vmd  RET   clock_gettime 0   
> >  15607 vmd  CALL  kevent(5,0,0,0x121da5f22000,64,0x121dae4dbcf0)
> >  
> >  15607 vmd  STRU  struct timespec { 0.002255000 }
> > 
> > I first encountered this issue on the snapshot from Jul 15th and was 
> > able to reproduce
> > several times under that snapshot and the subsequent snapshots from the 
> > 16th and 17th.
> > 
> > Typically the VM will run normally for a short time before hanging, and 
> > it seems to
> > occur both with /bsd and /bsd.rd. Typing seems to trigger it.
> > 
> 
> I bet I botched this with the serial port "improvement" done last month. I'll
> take a look tonight, thanks for the info.

to perhaps give you a hint, it looks, from the outside, like there's a byte to
be read, but vmd is in the "don't want bytes now" state, but has gotten out of
sync with libevent, which keeps calling the byte ready function, which keeps
doing nothing. but that's blind stabbing.

Console freeze OpenBSD 6.1 release and curent on proxmox ve 5.0

[Tom Smyth]

Hello
Just an Update,
Proxmox5.0 running on AMD Opteron G2 2435  Based systems
 are NOT affected by the bug

So the Bug seems to only affect Intel systems (well)
IvyBridge Xeon e5 2660-v2 or Xeon X5650 based systems


the OPenBSD 6.1 Release and OpenBSD Current systems
running on proxmox 5.0 ve run fine without the Standard
VGA Display...on Intel systems
(ie they are operating on serial console only)

I hope this helps

Re:

[Stefan Sperling]

On Wed, Jul 19, 2017 at 12:02:39PM -0500, Abel Abraham Camarillo Ojeda wrote:
> On Wed, Jul 19, 2017 at 11:52 AM, Stefan Sperling  wrote:
> > On Wed, Jul 19, 2017 at 11:48:39AM -0500, Abel Abraham Camarillo Ojeda 
> > wrote:
> >> On Wed, Jul 19, 2017 at 11:28 AM, Stefan Sperling  wrote:
> >> > On Wed, Jul 19, 2017 at 11:21:09AM -0500, Abel Abraham Camarillo Ojeda 
> >> > wrote:
> >> >> urtwn0: timeout waiting for firmware readiness
> >> >> urtwn0: timeout waiting for firmware readiness
> >> >> urtwn0: timeout waiting for firmware readiness
> >> >
> >> > I have the same RTL8188EU adapter you use, and it works for me.
> >> > Since the same adapter also works for you in another machine,
> >> > I suspect there is a USB support issue with your affected machine.
> >> > Perhaps the device is not getting sufficient power to operate?
> >>
> >> That would be OpeBSD + machine specific?
> >
> > Yes, perhaps. OpenBSD and Windows do not use the same device drivers.
> 
> Any Idea about how to debug/get more info on this?

No, sorry. I am not an expert on USB.

Re:

[Abel Abraham Camarillo Ojeda]

On Wed, Jul 19, 2017 at 11:52 AM, Stefan Sperling  wrote:
> On Wed, Jul 19, 2017 at 11:48:39AM -0500, Abel Abraham Camarillo Ojeda wrote:
>> On Wed, Jul 19, 2017 at 11:28 AM, Stefan Sperling  wrote:
>> > On Wed, Jul 19, 2017 at 11:21:09AM -0500, Abel Abraham Camarillo Ojeda 
>> > wrote:
>> >> urtwn0: timeout waiting for firmware readiness
>> >> urtwn0: timeout waiting for firmware readiness
>> >> urtwn0: timeout waiting for firmware readiness
>> >
>> > I have the same RTL8188EU adapter you use, and it works for me.
>> > Since the same adapter also works for you in another machine,
>> > I suspect there is a USB support issue with your affected machine.
>> > Perhaps the device is not getting sufficient power to operate?
>>
>> That would be OpeBSD + machine specific?
>
> Yes, perhaps. OpenBSD and Windows do not use the same device drivers.

Any Idea about how to debug/get more info on this?

Thank you.

>
>> Same urtwn0 card works in the same machine under windows 10
>> (just test it right now)
>>
>> Thanks.
>>
>> >
>> > What is the equivalent debug output you get for iwm?

Re:

[Abel Abraham Camarillo Ojeda]

On Wed, Jul 19, 2017 at 11:51 AM, Stefan Sperling  wrote:
> On Wed, Jul 19, 2017 at 11:38:00AM -0500, Abel Abraham Camarillo Ojeda wrote:
>> nwid aglaya chan 6 bssid c4:6e:1f:f3:2c:d0 95% HT-MCS7
>> privacy,short_preamble,short_slottime,wpa1
>
> WPA1 is disabled by default in OpenBSD. Set your AP to WPA2.

Sorry about that, it works now:

# ifconfig iwm0 scan
iwm0: flags=8802 mtu 1500
lladdr e4:b3:18:a4:88:b9
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect mode 11b)
status: no network
ieee80211: nwid ""
nwid aglaya chan 6 bssid c4:6e:1f:f3:2c:d0 94% HT-MCS7
privacy,short_preamble,short_slottime,wpa2,wpa1
nwid Wifi-Repeater chan 7 bssid 00:e0:20:53:b4:de 52%
HT-MCS15 privacy,short_slottime,wpa2
nwid INFINITUM6CFC_2.4 chan 11 bssid f4:9e:ef:5f:3f:a3
49% HT-MCS23 privacy,short_slottime,wpa2
nwid HOME-61AF chan 11 bssid 88:f7:c7:93:61:af 47%
HT-MCS23 privacy,short_slottime,wpa2,wpa1
nwid 0x chan 11 bssid
8a:f7:c7:93:61:a0 46% HT-MCS23
privacy,short_preamble,short_slottime,wpa2
nwid Totalplay-547C chan 3 bssid 04:9f:ca:27:da:64 43%
HT-MCS15 privacy,short_slottime,radio_measurement,wpa2,wpa1
nwid 0x
chan 6 bssid d0:4d:2c:1c:8e:1d 43% HT-MCS15
privacy,spectrum_mgmt,short_slottime,wpa2
nwid TOTALPLAY_04B743 chan 1 bssid a4:08:f5:04:b7:43
35% 54M privacy,spectrum_mgmt,short_slottime,radio_measurement,wpa1
nwid INFINITUM6CFC_5
chan 100 bssid f4:9e:ef:5f:3f:a7 31% HT-MCS76
privacy,spectrum_mgmt,short_slottime,wpa2
#
# ifconfig iwm0 nwid aglaya wpakey pass up
#
# ifconfig iwm0
iwm0: flags=8843 mtu 1500
lladdr e4:b3:18:a4:88:b9
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (HT-MCS0 mode 11n)
status: active
ieee80211: nwid aglaya chan 6 bssid c4:6e:1f:f3:2c:d0 100%
wpakey XXX wpaprotos wpa2 wpaakms psk wpac
iphers ccmp wpagroupcipher ccmp
#
# dhclient iwm0
DHCPDISCOVER on iwm0 - interval 1
DHCPOFFER from 172.16.0.1 (bc:ae:c5:78:22:a7)
DHCPREQUEST on iwm0 to 255.255.255.255
DHCPACK from 172.16.0.1 (bc:ae:c5:78:22:a7)
bound to 172.16.0.12 -- renewal in 21600 seconds.
#


Thanks!

Any idea about the em0/urtwn0 issues?

Re:

[Stefan Sperling]

On Wed, Jul 19, 2017 at 11:48:39AM -0500, Abel Abraham Camarillo Ojeda wrote:
> On Wed, Jul 19, 2017 at 11:28 AM, Stefan Sperling  wrote:
> > On Wed, Jul 19, 2017 at 11:21:09AM -0500, Abel Abraham Camarillo Ojeda 
> > wrote:
> >> urtwn0: timeout waiting for firmware readiness
> >> urtwn0: timeout waiting for firmware readiness
> >> urtwn0: timeout waiting for firmware readiness
> >
> > I have the same RTL8188EU adapter you use, and it works for me.
> > Since the same adapter also works for you in another machine,
> > I suspect there is a USB support issue with your affected machine.
> > Perhaps the device is not getting sufficient power to operate?
> 
> That would be OpeBSD + machine specific?

Yes, perhaps. OpenBSD and Windows do not use the same device drivers.

> Same urtwn0 card works in the same machine under windows 10
> (just test it right now)
> 
> Thanks.
> 
> >
> > What is the equivalent debug output you get for iwm?

Re:

[Stefan Sperling]

On Wed, Jul 19, 2017 at 11:38:00AM -0500, Abel Abraham Camarillo Ojeda wrote:
> nwid aglaya chan 6 bssid c4:6e:1f:f3:2c:d0 95% HT-MCS7
> privacy,short_preamble,short_slottime,wpa1

WPA1 is disabled by default in OpenBSD. Set your AP to WPA2.

Re:

[Abel Abraham Camarillo Ojeda]

On Wed, Jul 19, 2017 at 11:28 AM, Stefan Sperling  wrote:
> On Wed, Jul 19, 2017 at 11:21:09AM -0500, Abel Abraham Camarillo Ojeda wrote:
>> urtwn0: timeout waiting for firmware readiness
>> urtwn0: timeout waiting for firmware readiness
>> urtwn0: timeout waiting for firmware readiness
>
> I have the same RTL8188EU adapter you use, and it works for me.
> Since the same adapter also works for you in another machine,
> I suspect there is a USB support issue with your affected machine.
> Perhaps the device is not getting sufficient power to operate?

That would be OpeBSD + machine specific?
Same urtwn0 card works in the same machine under windows 10
(just test it right now)

Thanks.

>
> What is the equivalent debug output you get for iwm?

Re:

[Abel Abraham Camarillo Ojeda]

On Wed, Jul 19, 2017 at 11:28 AM, Stefan Sperling  wrote:
> On Wed, Jul 19, 2017 at 11:21:09AM -0500, Abel Abraham Camarillo Ojeda wrote:
>> urtwn0: timeout waiting for firmware readiness
>> urtwn0: timeout waiting for firmware readiness
>> urtwn0: timeout waiting for firmware readiness
>
> I have the same RTL8188EU adapter you use, and it works for me.
> Since the same adapter also works for you in another machine,
> I suspect there is a USB support issue with your affected machine.
> Perhaps the device is not getting sufficient power to operate?
>
> What is the equivalent debug output you get for iwm?

# ifconfig iwm0
iwm0: flags=8802 mtu 1500
lladdr e4:b3:18:a4:88:b9
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect
status: no network
ieee80211: nwid ""
#
# ifconfig iwm0 debug
# ifconfig iwm0 scan
iwm0: flags=8806 mtu 1500
lladdr e4:b3:18:a4:88:b9
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect
status: no network
ieee80211: nwid ""
nwid aglaya chan 6 bssid c4:6e:1f:f3:2c:d0 95% HT-MCS7
privacy,short_preamble,short_slottime,wpa1
nwid INFINITUM6CFC_2.4 chan 11 bssid f4:9e:ef:5f:3f:a3
49% HT-MCS23 privacy,short_slottime,wpa2
nwid Wifi-Repeater chan 7 bssid 00:e0:20:53:b4:de 49%
HT-MCS15 privacy,short_slottime,wpa2
nwid 0x chan 11 bssid
8a:f7:c7:93:61:a0 47% HT-MCS23
privacy,short_preamble,short_slottime,wpa2
nwid HOME-61AF chan 11 bssid 88:f7:c7:93:61:af 46%
HT-MCS23 privacy,short_slottime,wpa2,wpa1
nwid 0x
chan 6 bssid d0:4d:2c:1c:8e:1d 46% HT-MCS15
privacy,spectrum_mgmt,short_slottime,wpa2
nwid Totalplay-547C chan 3 bssid 04:9f:ca:27:da:64 43%
HT-MCS15 privacy,short_slottime,radio_measurement,wpa2,wpa1
nwid TOTALPLAY_04B743 chan 1 bssid a4:08:f5:04:b7:43
34% 54M privacy,spectrum_mgmt,short_slottime,radio_measurement,wpa1
nwid INFINITUM6CFC_5 chan 100 bssid f4:9e:ef:5f:3f:a7
31% HT-MCS76 privacy,spectrum_mgmt,short_slottime,wpa2
#
# ifconfig iwm0 nwid aglaya wpakey pass up
# ifconfig iwm0
iwm0: flags=8847 mtu
1500
lladdr e4:b3:18:a4:88:b9
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect mode 11b)
status: no network
ieee80211: nwid aglaya wpakey
0x62ea87bf30259f00edef48071266f42c09d7ce455c785a7655b45feafa078db2
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
#

# dmesg | sed -n '/^root/,$p'
root on sd0a (cc67f9c965a785a3.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
iwm0: hw rev 0x200, fw ver 16.242414.0, address e4:b3:18:a4:88:b9
iwm0: begin active scan
iwm0: received beacon from a4:08:f5:04:b7:43 rssi 23 mode auto
iwm0: end active scan
iwm0: end active scan
iwm0: received beacon from 04:9f:ca:27:da:64 rssi 29 mode auto
iwm0: received beacon from c4:6e:1f:f3:2c:d0 rssi 62 mode auto
iwm0: received beacon from 00:e0:20:53:b4:de rssi 33 mode auto
iwm0: received beacon from d0:4d:2c:1c:8e:1d rssi 31 mode auto
iwm0: received beacon from c4:6e:1f:f3:2c:d0 rssi 63 mode auto
iwm0: received beacon from 00:e0:20:53:b4:de rssi 34 mode auto
iwm0: received beacon from c4:6e:1f:f3:2c:d0 rssi 64 mode auto
iwm0: received beacon from 00:e0:20:53:b4:de rssi 33 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a3 rssi 34 mode auto
iwm0: received beacon from 88:f7:c7:93:61:af rssi 31 mode auto
iwm0: received beacon from 8a:f7:c7:93:61:a0 rssi 32 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a3 rssi 33 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a3 rssi 33 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a7 rssi 21 mode auto
iwm0: begin active scan
iwm0: received beacon from a4:08:f5:04:b7:43 rssi 24 mode auto
iwm0: received beacon from 04:9f:ca:27:da:64 rssi 30 mode auto
iwm0: received beacon from c4:6e:1f:f3:2c:d0 rssi 63 mode auto
iwm0: received beacon from d0:4d:2c:1c:8e:1d rssi 31 mode auto
iwm0: received beacon from c4:6e:1f:f3:2c:d0 rssi 63 mode auto
iwm0: received beacon from c4:6e:1f:f3:2c:d0 rssi 64 mode auto
iwm0: received beacon from 00:e0:20:53:b4:de rssi 33 mode auto
iwm0: received beacon from 88:f7:c7:93:61:af rssi 31 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a3 rssi 32 mode auto
iwm0: received beacon from 88:f7:c7:93:61:af rssi 31 mode auto
iwm0: received beacon from 8a:f7:c7:93:61:a0 rssi 31 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a7 rssi 21 mode auto
iwm0: received beacon from f4:9e:ef:5f:3f:a7 rssi 21 mode auto
iwm0: end active scan
iwm0: end active scan
#

Re:

[Stefan Sperling]

On Wed, Jul 19, 2017 at 11:21:09AM -0500, Abel Abraham Camarillo Ojeda wrote:
> urtwn0: timeout waiting for firmware readiness
> urtwn0: timeout waiting for firmware readiness
> urtwn0: timeout waiting for firmware readiness

I have the same RTL8188EU adapter you use, and it works for me.
Since the same adapter also works for you in another machine,
I suspect there is a USB support issue with your affected machine.
Perhaps the device is not getting sufficient power to operate?

What is the equivalent debug output you get for iwm?

Re:

[Abel Abraham Camarillo Ojeda]

On Wed, Jul 19, 2017 at 11:06 AM, Stefan Sperling  wrote:
> On Wed, Jul 19, 2017 at 12:47:51AM -0500, Abel Abraham Camarillo Ojeda wrote:
>> Also I'm unable to use another wifi card that works on other OpenBSD machine:
>
> Please run: ifconfig urtwn0 debug
> And then repeat this test:
>
>> # ifconfig urtwn0 nwid aglaya wpakey pass up;
>
> Show us the additional debug info which will be written to /var/log/messages.
>
> With successful association you should see additional messages such as:
>
> urtwn0: associated with fe:e1:ba:d0:87:4b ssid "mywifi" channel 8 start 1Mb 
> short preamble short slot time
> urtwn0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU
> urtwn0: received assoc_resp from fe:e1:ba:d0:87:4b rssi -15 mode 11g
> urtwn0: received msg 1/4 of the 4-way handshake from fe:e1:ba:d0:87:4b
> urtwn0: sending msg 2/4 of the 4-way handshake to fe:e1:ba:d0:87:4b
> urtwn0: received msg 3/4 of the 4-way handshake from fe:e1:ba:d0:87:4b
> urtwn0: sending msg 4/4 of the 4-way handshake to fe:e1:ba:d0:87:4b

(magically now ethernet is working)

# ifconfig urtwn0 debug;
# ifconfig urtwn0 nwid aglaya wpakey pass up
$ dmesg | tail
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (cc67f9c965a785a3.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
iwm0: hw rev 0x200, fw ver 16.242414.0, address e4:b3:18:a4:88:b9
urtwn0: timeout waiting for firmware readiness
urtwn0: timeout waiting for firmware readiness
urtwn0: timeout waiting for firmware readiness
$

# ifconfig urtwn0
urtwn0: flags=8803 mtu 1500
lladdr e8:de:27:a3:d6:d9
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect
status: no network
ieee80211: nwid aglaya wpakey XXX wpaprotos wpa2 wpaakms psk
wpaciphers ccmp wpagroupcipher ccmp

Thanks

Re:

[Stefan Sperling]

On Wed, Jul 19, 2017 at 12:47:51AM -0500, Abel Abraham Camarillo Ojeda wrote:
> Also I'm unable to use another wifi card that works on other OpenBSD machine:
 
Please run: ifconfig urtwn0 debug
And then repeat this test:

> # ifconfig urtwn0 nwid aglaya wpakey pass up;

Show us the additional debug info which will be written to /var/log/messages.

With successful association you should see additional messages such as:

urtwn0: associated with fe:e1:ba:d0:87:4b ssid "mywifi" channel 8 start 1Mb 
short preamble short slot time
urtwn0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU
urtwn0: received assoc_resp from fe:e1:ba:d0:87:4b rssi -15 mode 11g
urtwn0: received msg 1/4 of the 4-way handshake from fe:e1:ba:d0:87:4b
urtwn0: sending msg 2/4 of the 4-way handshake to fe:e1:ba:d0:87:4b
urtwn0: received msg 3/4 of the 4-way handshake from fe:e1:ba:d0:87:4b
urtwn0: sending msg 4/4 of the 4-way handshake to fe:e1:ba:d0:87:4b

Re: OpenBSD guest hangs in vmd on -current host

[Ted Unangst]

Max Parmer wrote:
> 
> >Synopsis:OpenBSD guest hangs in vmd on -current host
> >Category:system
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1-current (GENERIC.MP) #99: Mon Jul 17 16:53:49 
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When running an OpenBSD guest under vmd after a short time the guest 
> will hang, the
>   corresponding vmd process will hit and stay at 99.9% CPU usage.
>   
>   Examination with ktrace shows a pattern similar to the past reports 
> from tedu@[1] and
>   Gregor Best[2] with the process spinning on kevent and gettime, excerpt:
>15607 vmd  RET   kevent 1  
>15607 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x121dae4dbd20) 
>  
>15607 vmd  STRU  struct timespec { 20180.643241450 }   
>  
>15607 vmd  RET   clock_gettime 0   
>15607 vmd  CALL  kevent(5,0,0,0x121da5f22000,64,0x121dae4dbcf0)
>  
>15607 vmd  STRU  struct timespec { 0.002255000 }
> 
>   I first encountered this issue on the snapshot from Jul 15th and was 
> able to reproduce
>   several times under that snapshot and the subsequent snapshots from the 
> 16th and 17th.

i didn't dig into vmd to see where it's spinning, but if you run vmd with env
EVENT_NOKQUEUE=1 then I haven't observed the problem.

ifconfig'ing an IPv6 pflow address stopped working

[pjp]

>Synopsis:  ifconfig'ing pflow address stopped working at one point
>Category:  system
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1 (GENERIC.MP) #8: Tue Jun 27 08:50:26 CEST 2017
 
rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I got errors with ifconfig'ing the following hostname.if:

venus$ more /etc/hostname.pflow0
flowsrc [2001:db8:0:10::202] flowdst [2001:db8:0:10::352]:12345 pflowproto 5

>How-To-Repeat:
give it a try, it won't work with my attached patch.
>Fix:
We're ifconfig'ing addresses only so why resolve?  AI_NUMERICHOST is added as
a hint. Then it worked for me.
? ifconfig.patch
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.340
diff -u -p -u -r1.340 ifconfig.c
--- ifconfig.c  21 Mar 2017 07:24:36 -  1.340
+++ ifconfig.c  19 Jul 2017 10:03:33 -
@@ -4510,6 +4510,7 @@ pflow_addr(const char *val, struct socka
bzero(, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM; /*dummy*/
+   hints.ai_flags = AI_NUMERICHOST;
 
if ((error = getaddrinfo(ip, port, , )) != 0)
errx(1, "error in parsing address string: %s",


dmesg:
OpenBSD 6.1 (GENERIC.MP) #8: Tue Jun 27 08:50:26 CEST 2017

rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130575360 (2031MB)
avail mem = 2061385728 (1965MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 1.60GHz, 1600.22 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 1.60GHz, 1599.99 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
cpu0: unknown Enhanced SpeedStep CPU, msr 0x0613101a0600101a
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1600, 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel E600 Host" rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
"Intel EG20T USB Client" rev 0x02 at pci2 dev 2 function 4 not configured
sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdhc0: SDHC 1.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdhc1: SDHC 1.0, 50 MHz base clock
sdmmc1 at sdhc1: 4-bit, sd high-speed, mmc high-speed
ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 1: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.500151795931e477
sd0: 76319MB, 512 bytes/sector, 156301488 sectors, thin
ohci3 at pci2 dev 8 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ohci4 at pci2 dev 8 function 1 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ohci5 at pci2 dev 8 function 2 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ehci1 at pci2 dev 8 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 16
usb1 at ehci1: USB revision