Re: azalia audio works, then stutters until reboot

[luke350]

On 09/12/15 05:25, Alexandre Ratchov wrote:

Audio didn't properly recover after missed interrupts (which
happens on MP systems). The new audio driver (in 5.8 and -current)
is supposed to recover, at least with your hardware.

...

I'd suggest trying -current; there's a new audio driver and many
audio-related fixes. Furthermore we're not interested in debugging
the old code that we already deleted :)


Thanks, good to know.  I think I'm better suited for "-stable"
than for "-current", currently.   So I might wait for 5.8's release
then upgrade, or I'd have to figure out if it's a supported
configuration to be on -current now then switch back to -stable
just when 5.8 is released.

But is there an easy way to force my audio in 5.7 to stay on a
single core or such, if that would help in the meantime? Or
any good way to "reset" it at any time, short of rebooting?

I'm guessing not on both questions, just confirming...

Thanks again,
-Luke

Re: requesting help working around boot failures with supermicro atom board

[lists]

> Whether they are identical or not, showing us a dmesg diff with a known
> working release booted from both a working and the non-working system
> could also be helpful.

Another Supermicro X7SPA-HF-D525 board (same chipset/CPU combination)
has been having the same issue since early 2011 (the entire life span
of the system), always running a recent snapshot:

http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA-HF-D525.cfm

There is absolutely no sense in running a 2010 snapshot now, except for
experiments as suggested by Benny.

Please try and see if it makes a difference comparing reboots of the
system over SSH, on the local console, over serial console, and with
serial over LAN. I can provide test results over all these methods
given some tech suggestion / solution.

You may want to have a DMI / PCI / ACPI dumps, let me know how / if you
want these from my system too (attach brief newbie instructions please).

So far, nothing has solved it yet for me too, except power cycle via the
PSU breaker each time this happens. Never tried any other OS except
OpenBSD, thought it was the hardware (memory by the beep code) fault,
but it's not (confirmed with long runs of memtest). The system
runs for very long intervals without any other issues, except the
reboot behaviour in the original post, confirming same problem. Running
latest BIOS and IPMI firmwares.

Thanks, Dewey for testing this more extensively than I had the nerve to.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Richard Laysell  xiphosura.co.uk> writes:

> 
> On Fri, 11 Sep 2015 18:38:23 -0400 (EDT)
> "dewey.hylton  gmail.com"  gmail.com> wrote:
> 
> > hi all. i’m having difficulty with this board:
> > 
> > Supermicro X7SPE-HD-D525 rev1
> > 
> > i have several similar systems, each running an older version of
> > OpenBSD for a few years without incident. except this one …
> > 
> 
> 
> Do you have Quick Boot enabled in the BIOS?  If so, try disabling it.
> 
> I have known this cause problems (on other boards - no experience with
> this one).  Quick Boot seems to do a quick and dirty setup and
> doesn't fully initialise all of the devices.  This may be why you are
> seeing it boot OK if you remove the power - the devices then either get
> reset to their default states or the BIOS has to set them up.
> 
> Regards,
> 
> Richard

i have indeed disabled quick/quiet boot options to no avail. i've also tried
failsafe mode, ide vs ahci, acpi v1/2/3. the issue does not present with
linux, which makes me wonder whether the openbsd kernel is somehow making
some kind of hardware setting change that is not cleared on reboot. despite
this only presenting in openbsd, i still blame hardware - but am hoping
there might be some openbsd-related tweak.

thanks for the idea.

Re: azalia audio works, then stutters until reboot

[Fred]

On 09/12/15 17:56, luke...@onemodel.org wrote:

Thanks, good to know.  I think I'm better suited for "-stable"
than for "-current", currently.   So I might wait for 5.8's release
then upgrade, or I'd have to figure out if it's a supported
configuration to be on -current now then switch back to -stable
just when 5.8 is released.


-current is probably heading towards 5.9 at the moment.

Switching back from current to stable isn't a supported option, so you 
are probably better off waiting for 5.8 release on the 18 Oct 2015 - but 
if you pre-order from https://www.openbsdstore.com you might get it 
before the 18 Oct!


Cheers

Fred

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

  wrant.com> writes:

> 
> > Whether they are identical or not, showing us a dmesg diff with a known
> > working release booted from both a working and the non-working system
> > could also be helpful.
> 
> Another Supermicro X7SPA-HF-D525 board (same chipset/CPU combination)
> has been having the same issue since early 2011 (the entire life span
> of the system), always running a recent snapshot:
> 
> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA-HF-D525.cfm
> 
> There is absolutely no sense in running a 2010 snapshot now, except for
> experiments as suggested by Benny.
> 
> Please try and see if it makes a difference comparing reboots of the
> system over SSH, on the local console, over serial console, and with
> serial over LAN. I can provide test results over all these methods
> given some tech suggestion / solution.
> 
> You may want to have a DMI / PCI / ACPI dumps, let me know how / if you
> want these from my system too (attach brief newbie instructions please).
> 
> So far, nothing has solved it yet for me too, except power cycle via the
> PSU breaker each time this happens. Never tried any other OS except
> OpenBSD, thought it was the hardware (memory by the beep code) fault,
> but it's not (confirmed with long runs of memtest). The system
> runs for very long intervals without any other issues, except the
> reboot behaviour in the original post, confirming same problem. Running
> latest BIOS and IPMI firmwares.
> 
> Thanks, Dewey for testing this more extensively than I had the nerve to.

this is great information, and i've passed it along to supermicro as a "i'm
not the only one with this issue" datapoint.

since i'm apparently not alone, this looks more like a board/firmware design
issue - just curious why none of my other boards have this issue.

i'm not knowledgeable enough to provide newbie instructions on the dumps,
but if doing this makes sense to anyone here with more hardware experience
i'm certainly willing to try it.

regarding the comparison of reboots, do you mean testing reboots initiated
via different means (ssh/console/etc.)? if so, i've done that and ruled them
out. last test was a shell script with sleep/reboot commands which executed
via rc.local - meaning there was no user login prior to the failure.

thanks for this information.

ral(4) timeouts

[Jan Stary]

This is 5.8-current on an ALIX (dmesg below), used as my home router.
The upstream connection is an ethernet, the other two ethernets are
the internal network and the dmz, plus there is a ral(4) wifi.

I am experiencing errors and device timeouts on the ral.

hans@gw:~$ ifconfig ral0
ral0: flags=8843 mtu 1500
lladdr 00:11:09:0d:d3:36
priority: 4
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap)
status: active
ieee80211: nwid stare.cz chan 11 bssid 00:11:09:0d:d3:36 wpakey  wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher 
tkip 100dBm
inet 192.168.112.1 netmask 0xff00 broadcast 192.168.112.255
 
hans@gw:~$ netstat -i
NameMtu   Network Address  Ipkts IerrsOpkts Oerrs Colls
lo0 32768 3229 0 3229 0 0
lo0 32768 fe80::%lo0/ fe80::1%lo0   3229 0 3229 0 0
lo0 32768 localhost/1 localhost 3229 0 3229 0 0
lo0 32768 127/8   localhost 3229 0 3229 0 0
vr0 150000:0d:b9:12:9f:2c 34776087 0 24076275 0 0
vr0 1500  192.168.167 192.168.167.1 34776087 0 24076275 0 0
vr1 150000:0d:b9:12:9f:2d 16420441 0 27179401 0 0
vr1 1500  192.168.111 gw.stare.cz   16420441 0 27179401 0 0
vr2 150000:0d:b9:12:9f:2e  7785814 0  7597590 0 0
vr2 1500  192.168.222 192.168.222.1  7785814 0  7597590 0 0
ral0150000:11:09:0d:d3:36   488808 62712   657003 14631 0
ral01500  192.168.112 192.168.112.1   488808 62712   657003 14631 0
enc0*   00 00 0 0
pflog0  331920 0   163817 0 0


What can I do to debug this? Is there a way to tell which client
(there is two androids and a macbook) this happened to?

Thank you for your time

Jan

OpenBSD 5.8-current (GENERIC) #1092: Mon Aug 24 11:58:09 MDT 2015
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 432 
MHz
 cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem  = 133713920 (127MB)
avail mem = 118882304 (113MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/10/07, BIOS32 rev. 0 @ 0xfceb2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
mtrr: K6-family MTRR support (2 registers)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address 
00:0d:b9:12:9f:2c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:0d:b9:12:9f:2d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
00:0d:b9:12:9f:2e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
ral0 at pci0 dev 12 function 0 "Ralink RT2560" rev 0x01: irq 9, address 
00:11:09:0d:d3:36
ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 7279MB, 14909328 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0, 
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (bf940e6c7aaf2c50.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout
ral0: device timeout

Re: requesting help working around boot failures with supermicro atom board

[Richard Laysell]

On Fri, 11 Sep 2015 18:38:23 -0400 (EDT)
"dewey.hyl...@gmail.com"  wrote:

> hi all. i’m having difficulty with this board:
> 
> Supermicro X7SPE-HD-D525 rev1
> 
> i have several similar systems, each running an older version of
> OpenBSD for a few years without incident. except this one …
> 


Do you have Quick Boot enabled in the BIOS?  If so, try disabling it.

I have known this cause problems (on other boards - no experience with
this one).  Quick Boot seems to do a quick and dirty setup and
doesn't fully initialise all of the devices.  This may be why you are
seeing it boot OK if you remove the power - the devices then either get
reset to their default states or the BIOS has to set them up.

Regards,

Richard

Re: anoncvs.html.head

[Rob Pierce]

- Original Message -
> From: "Stuart Henderson" 
> To: "misc" 
> Sent: Saturday, September 12, 2015 11:58:29 AM
> Subject: Re: anoncvs.html.head

> On 2015-09-11, Rob Pierce  wrote:
>>src - Houses all source code for the OpenBSD Operating System.
>>ports - Houses the OpenBSD 
>> Ports.
>> -  www - Houses all OpenBSD web pages. (Including this one).
>> +  www - Houses all OpenBSD web pages (including this one).
> 
> I like that
> 
>>xenocara - Houses OpenBSD's active X.org v7 source tree.
>>X11 and XF4 - Houses OpenBSD's adaptation of the
>>http://www.XFree86.org/;>XFree86-3 and XFree86-4
>> @@ -122,7 +122,7 @@ with only one part of the tree.  The two
>>  which contains the files used to create the kernel, and src.tar.gz
>>  which contains all the other "userland" utilities.
>>  In general, however, you will usually want both of them installed.
>> -Assuming the downloaded files, src.tar.gz,
>> +Assuming the downloaded files src.tar.gz,
>> sys.tar.gz and xenocara.tar.gz are in /usr:
> 
> I think this was OK as it was
> 
>> 
>> -Not all people will wish to unpack all the file sets, but as the system
>> +Not all people will wish to unpack all the source file, but as the system
>>  must be kept in sync, you will generally need to set up all trees.
> 
> and this (and the new sentence doesn't quite make sense)
> 
>> 
>> -You can also just use cvs(1) to "checkout" the source repository
>> +You can also just use
>> +> href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1)
>> +to "checkout" the source repository
>>  for you. This is discussed in the next section.
> 
> OK I guess, though I don't think we need to hyperlink every instance of
> a program name
> 
>> @@ -160,16 +162,12 @@ from the errata>  For more information on these "flavors" of OpenBSD, see
>> here.
>>  
>> -Once you have decided which tree to follow, you must choose which 
>> Anonymous
>> -CVS server you are going to use.  A list of these servers is
>> -below.
>> -
>> 
>> -Once you have chosen which Anonymous CVS Server you 
>> will
>> -use, you can start using cvs. For those of you
>> +Once you have decided which tree to follow, and which > href="#CVSROOT">Anonymous CVS Server you will
> 
> Please try and keep <80 columns in the source file where sensible
> 
>> +use, you can start using > href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1).
>> For those of you
>>  who have CDs you can start with the CVS checkout that is on the CD by using
>>  the method above to get the sources onto your 
>> system.
>> -If you don't have a CD handy, use the method below to checkout the sources.
>> +If you don't have a CD handy, use the method below to checkout the sources:
>>  
>> 
>> First, start out by `get'-ing an initial tree:
>> @@ -210,9 +208,11 @@ Confirm this, and the fingerprint will t
>>  ...
>> 
>>  
>> +
>>  Note that the above format with SHA256 fingerprints was added after the
>>  release of OpenBSD 5.6; older versions only use MD5 fingerprints.
>>  
>> +
>>  Anytime afterwards, to `update' this tree:
>>  (If you are following current):
>> 
>> @@ -234,7 +234,7 @@ to merge changes in.
>>  NOTE:
>>  If you are updating a source tree that you initially fetched
>>  from a different server, or from a CD, you must
>> -add the -d [cvsroot] option to cvs.
>> +add the -d [cvsroot] option to cvs:
>> 
>>  # cd /usr/src
>>  # cvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd
>> @@ -295,11 +295,11 @@ directory, and a subsequent update will
>>  
>> 
>>  The anoncvs service gives fledgling developers a chance to learn CVS
>> -operation and get thoroughly involved in the development process
>> +operations and get thoroughly involved in the development process
> 
> "operation" already seem ok
> 
>>  before getting "commit" access -- as a result of showing useful
>>  skills and high quality results they will naturally later be given
>>  developer access.
>> -As well, people providing patches can create their "diff"s relative
>> +As well, people providing patches can create their diffs relative
>>  to the CVS tree, which will ease integration.
>>  
> > Example usages for cvs(1)

Thanks Stuart. I am preparing a new diff which I will send shortly.

Re: System clock hours behind, network hangs (amd64, -current)

[Martin Pieuchot]

On 11/09/15(Fri) 18:56, Mark Patruck wrote:
> On Fri, Sep 11, 2015 at 06:27:36PM +0200, Martin Pieuchot wrote:
> > On 11/09/15(Fri) 18:07, Mark Patruck wrote:
> > > dmesg below is currently running, but it also didn't work with a 2 week
> > > old snapshot from the local mirror. (system was freshly installed)
> > > 
> > > Note: the machine hasn't been used over the last two months, so i've
> > > double checked battery, memory, psu.
> > > 
> > > OpenBSD 5.8-current (GENERIC.MP) #0: Mon Sep  7 15:54:34 CEST 2015
> > > bu...@aquila.paccotec.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Since you build your kernel yourself, I can't tell when you did your
> > checkout and I'll bet you hit the window when rtisvalid(9) was in.
> > 
> > Could you try a -current checkout with this diff an tell me if you can
> > reproduce the problem?
> 
>   Thanks Martin. I'll report back asap.

Tree is moving fast, here's an updated diff.

> > Could you also tell me what are your nfs mounts? 
> 
>   $ cat /etc/exports
>   /share/d0 -alldirs -mapall=umedia:media -ro mso
>   /share/d1 -alldirs -mapall=umedia:media -ro mso
> 
>   $ mount | grep NFS
>   /dev/sd1a on /share/d0 type ffs (NFS exported, local, nodev, noexec, 
> nosuid, softdep)
>   /dev/sd2a on /share/d1 type ffs (NFS exported, local, nodev, noexec, 
> nosuid, softdep)
> 

Interesting, the previous report I had with similar symptoms was about a
machine using nested NFS mounts from two different servers.

Please let me know what happen with the diff below,  thanks!

Index: netinet/ip_output.c
===
RCS file: /cvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.293
diff -u -p -r1.293 ip_output.c
--- netinet/ip_output.c 11 Sep 2015 19:17:47 -  1.293
+++ netinet/ip_output.c 12 Sep 2015 07:57:24 -
@@ -170,9 +170,9 @@ reroute:
 * If there is a cached route, check that it is to the same
 * destination and is still up.  If not, free it and try again.
 */
-   if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 ||
+   if (!rtisvalid(ro->ro_rt) ||
dst->sin_addr.s_addr != ip->ip_dst.s_addr ||
-   ro->ro_tableid != m->m_pkthdr.ph_rtableid)) {
+   ro->ro_tableid != m->m_pkthdr.ph_rtableid) {
rtfree(ro->ro_rt);
ro->ro_rt = NULL;
}
@@ -194,7 +194,9 @@ reroute:
ro->ro_rt = rtalloc_mpath(>ro_dst,
>ip_src.s_addr, ro->ro_tableid);
 
-   if (ro->ro_rt == NULL) {
+   if (!rtisvalid(ro->ro_rt)) {
+   rtfree(ro->ro_rt);
+   ro->ro_rt = NULL;
ipstat.ips_noroute++;
error = EHOSTUNREACH;
goto bad;
Index: netinet6/in6_src.c
===
RCS file: /cvs/src/sys/netinet6/in6_src.c,v
retrieving revision 1.61
diff -u -p -r1.61 in6_src.c
--- netinet6/in6_src.c  11 Sep 2015 20:16:03 -  1.61
+++ netinet6/in6_src.c  12 Sep 2015 08:00:29 -
@@ -251,13 +251,12 @@ in6_selectsrc(struct in6_addr **in6src, 
 * our src addr is taken from the i/f, else punt.
 */
if (ro) {
-   if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 ||
-   !IN6_ARE_ADDR_EQUAL(>ro_dst.sin6_addr, dst))) {
+   if (!rtisvalid(ro->ro_rt) ||
+   !IN6_ARE_ADDR_EQUAL(>ro_dst.sin6_addr, dst)) {
rtfree(ro->ro_rt);
ro->ro_rt = NULL;
}
-   if (ro->ro_rt == (struct rtentry *)0 ||
-   ro->ro_rt->rt_ifp == (struct ifnet *)0) {
+   if (ro->ro_rt == NULL) {
struct sockaddr_in6 *sa6;
 
/* No route yet, so try to acquire one */
@@ -367,10 +366,9 @@ in6_selectroute(struct sockaddr_in6 *dst
 * cached destination, in case of sharing the cache with IPv4.
 */
if (ro) {
-   if (ro->ro_rt &&
-   (!(ro->ro_rt->rt_flags & RTF_UP) ||
+   if (!rtisvalid(ro->ro_rt) ||
 sin6tosa(>ro_dst)->sa_family != AF_INET6 ||
-!IN6_ARE_ADDR_EQUAL(>ro_dst.sin6_addr, dst))) {
+!IN6_ARE_ADDR_EQUAL(>ro_dst.sin6_addr, dst)) {
rtfree(ro->ro_rt);
ro->ro_rt = NULL;
}

edit UTF-8 text files under vi or mg?

[Jiri Navratil]

Hello,

Is it possible to edit UTF-8 text files under vi or mg?

I'm using some machines, where I need to touch UTF-8 encoded files only
rarely. I would prefer to avoid installation of Vim there and instead
use a "in OS included" text editor. Is that possible and how to use and
configure them?

Thank you,
Jiri

-- 
Jiri Navratil, http://kouc.navratil.cz, +420 222 767 131

Re: edit UTF-8 text files under vi or mg?

[Stuart Henderson]

On 2015-09-12, Jiri Navratil  wrote:
> Hello,
>
> Is it possible to edit UTF-8 text files under vi or mg?
>
> I'm using some machines, where I need to touch UTF-8 encoded files only
> rarely. I would prefer to avoid installation of Vim there and instead
> use a "in OS included" text editor. Is that possible and how to use and
> configure them?
>
> Thank you,
> Jiri
>

The closest thing is editors/nvi from ports.

Re: edit UTF-8 text files under vi or mg?

[Christian Weisgerber]

On 2015-09-12, Jiri Navratil  wrote:

> Is it possible to edit UTF-8 text files under vi or mg?

The editors in base do not support UTF-8 yet.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

[no subject]

[Jan Stary]

This is 5.8-current on an ALIX (dmesg below), used as my home router.
The upstream connection is an ethernet, the other two ethernets are
the internal network and the dmz, plus there is a ral(4) wifi.

I am experiencing Oerrs and device timeouts on the ral.

hans@gw:~$ ifconfig ral0
ral0: flags=8843 mtu 1500
lladdr 00:11:09:0d:d3:36
priority: 4
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap)
status: active
ieee80211: nwid stare.cz chan 11 bssid 00:11:09:0d:d3:36 wpakey  wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher 
tkip 100dBm
inet 192.168.112.1 netmask 0xff00 broadcast 192.168.112.255

hans@gw:~$ netstat -i
NameMtu   Network Address  Ipkts IerrsOpkts Oerrs Colls
lo0 32768 3229 0 3229 0 0
lo0 32768 fe80::%lo0/ fe80::1%lo0   3229 0 3229 0 0
lo0 32768 localhost/1 localhost 3229 0 3229 0 0
lo0 32768 127/8   localhost 3229 0 3229 0 0
vr0 150000:0d:b9:12:9f:2c 34776087 0 24076275 0 0
vr0 1500  192.168.167 192.168.167.1 34776087 0 24076275 0 0
vr1 150000:0d:b9:12:9f:2d 16420441 0 27179401 0 0
vr1 1500  192.168.111 gw.stare.cz   16420441 0 27179401 0 0
vr2 150000:0d:b9:12:9f:2e  7785814 0  7597590 0 0
vr2 1500  192.168.222 192.168.222.1  7785814 0  7597590 0 0
ral0150000:11:09:0d:d3:36   488808 62712   657003 14631 0
ral01500  192.168.112 192.168.112.1   488808 62712   657003 14631 0
enc0*   00 00 0 0
pflog0  331920 0   163817 0 0


What can I do to debug this? Is there a way to tell which client
(there is two androids and a macbook) this happened to?
Is the client relevant, or is this a problem of the ral itself?

Thank you for your time

Jan


OpenBSD 5.8-current (GENERIC) #1092: Mon Aug 24 11:58:09 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 432 
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem  = 133713920 (127MB)
avail mem = 118882304 (113MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/10/07, BIOS32 rev. 0 @ 0xfceb2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
mtrr: K6-family MTRR support (2 registers)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address 
00:0d:b9:12:9f:2c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:0d:b9:12:9f:2d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
00:0d:b9:12:9f:2e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
ral0 at pci0 dev 12 function 0 "Ralink RT2560" rev 0x01: irq 9, address 
00:11:09:0d:d3:36
ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 7279MB, 14909328 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0, 
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a 

Re: edit UTF-8 text files under vi or mg?

[Theo Buehler]

On Sat, Sep 12, 2015 at 11:02:13AM +0200, Jiri Navratil wrote:
> Hello,
> 
> Is it possible to edit UTF-8 text files under vi or mg?

As far as I know most base utilities do not yet have UTF-8 support, but
it might be coming soon, as announced in stsp@'s c2k15 report:

http://undeadly.org/cgi?action=article=20150722182236

where it is also mentioned that ksh(1), mg(1) and vi(1) don't
support UTF-8, yet.

> I'm using some machines, where I need to touch UTF-8 encoded files only
> rarely. I would prefer to avoid installation of Vim there and instead
> use a "in OS included" text editor. Is that possible and how to use and
> configure them?

I think nvi would be a good alternative to vim:

$ pkg_info nvi-2.1.3
Information for 
http://mirror.switch.ch/ftp/pub/OpenBSD/snapshots/packages/amd64/nvi-2.1.3.tgz

Comment:
ex/vi text editor with wide character support

Description:
Nvi is an implementation of the ex/vi text editor originally distributed as
part of the Fourth Berkeley Software Distribution (4BSD), by the University
of California, Berkeley.

Nvi supports all the historic ex/vi features except for open mode and the
lisp edit option (e.g., it has a fully implemented underlying ex mode). It
has a number of additional features as well:

* 8-bit clean data, lines and files limited by available memory
* Multiple edit buffers
* Colon command-line editing and path name completion
* Tag stacks (including support for Cscope databases)
* Extended Regular Expressions
* Infinite undo
* Horizontal scrolling
* Message catalogs
* Wide character support

Available flavors:
iconv - support conversion between different character encodings

Maintainer: Anthony J. Bentley 

WWW: https://github.com/lichray/nvi2

Re: azalia audio works, then stutters until reboot

[Alexandre Ratchov]

On Fri, Sep 11, 2015 at 11:55:29AM -0600, luke...@onemodel.org wrote:
> Short version: In OpenBSD 5.7 (with all the latest security
> patches), after some video playing, it
> starts to stutter, and doesn't recover until I reboot. Is there
> a way to "reset all the audio" back so it works, short of rebooting?
> I haven't found that in anything I've read so far, including from
> faq 13 and manpages for audioctl and mixerctl etc.

Audio didn't properly recover after missed interrupts (which
happens on MP systems). The new audio driver (in 5.8 and -current)
is supposed to recover, at least with your hardware.
 
> The only other things other than from the above-linked
> thread that I've thought of to try are:
> - upgrading to CURRENT to see if it's any different
> - debugging (I'd have to learn a lot, best with some guidance)
> - discuss & learn more here...

I'd suggest trying -current; there's a new audio driver and many
audio-related fixes. Furthermore we're not interested in debugging
the old code that we already deleted :)

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Benny Lofgren  lofgren.biz> writes:

> 
> Hi Dewey,
> 
> On 2015-09-12 00:38, dewey.hylton  gmail.com wrote:
> > hi all. i’m having difficulty with this board:
> 
> I noticed your mail somehow got posted twice, but I'm commenting on the
> first incarnation of it because the second had some characters like '\''
> mangled (UTF-8 copy/paste issue I presume).

i posted first via my normal zimbra server, which seemed to have gotten
hung up so i copied/pasted into the gmail web interface. i think the
second to show up may have been the original (via zimbra). no idea why
there's an issue. i only get daily digests via email so i'm posting this
via the gmane interface; if this doesn't work correctly i'll have to sit
down and figure out the best way to do this in the future.
> 
> > Supermicro X7SPE-HD-D525 rev1
> > i have several similar systems, each running an older version of OpenBSD
for a few years without incident.
> except this one …
> 
> You might already have tried this, but providing this information may
> give important clues to the rest of us trying to help you:
> 
> Since you say that your other similar systems are successfully running
> older versions of OpenBSD, have you tried running this new system with a
> version that you know works on the other boards?

i just installed 5.4 on this board, just as is running on its original
cluster mate (which is still running fine). same issue.

> 
> And if so, then have you tried moving on to subsequent versions in turn
> until you find the one which breaks? That is a really important piece of
> information.
> 
> Also, are those other systems "similar" or "identical"? If not
> identical, what differs? This is also important to get a grip on the
> problem.

these are identical in all ways, except for the current bios version
(which supermicro had me to update when troubleshooting). i'll attempt
to back it down to the same version present on the working board and 
see where that gets me.

> 
> Whether they are identical or not, showing us a dmesg diff with a known
> working release booted from both a working and the non-working system
> could also be helpful.

i'll post the diff below.
> 
> Regards,
> 
> /Benny

thanks for your input. i was shocked to find that linux didn't produce
this issue as well; i don't understand how a failure for a board to 
post could have anything to do with an os which is not running during
the post. that may just show how much i (don't) understand the hardware
and bios side of things.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

John E.P. Hynes  hytronix.com> writes:

> 
> Try booting the SP kernel and see if that works.  If it does, you might
> be running into a variant of an issie I've had on my SuperMicro boxen...
> 
> -John

john, i tried this (5.4 bsd.sp) and i'm seeing the same result. it didn't
occur to me to try this; thanks for the idea.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> > Whether they are identical or not, showing us a dmesg diff with a known
> > working release booted from both a working and the non-working system
> > could also be helpful.
> 
> i'll post the diff below.

the only real differences i see are:
1) bios revision
2) secondary disk attached to different sata port
3) sensors only present on working machine

i'm having a hard time finding the older bios on the supermicro site, so i'm
reaching out to them.

i'm ignoring the disk channel difference.

i'm looking into the sensors - haven't found that in the bios yet.

here's the diff:

$ diff inf1.dmesg.54i inf2.dmesg.54i.good
8,9c8,9
< bios0 at mainbus0: AT/286+ BIOS, date 07/19/13, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
< bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
---
> bios0 at mainbus0: AT/286+ BIOS, date 02/21/12, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
> bios0: vendor American Megatrends Inc. version "1.2a" date 02/21/12
18c18
< cpu0: apic clock running at 200MHz
---
> cpu0: apic clock running at 199MHz
20c20
< cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz
---
> cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
23c23
< cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz
---
> cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
26c26
< cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz
---
> cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
43c43
< bios0: ROM list: 0xc/0x8000 0xc8000/0x1000
---
> bios0: ROM list: 0xc/0x8000
57c57
< em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
0c:c4:7a:54:90:8e
---
> em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:97:49:e0
60c60
< em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
0c:c4:7a:54:90:8f
---
> em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:97:49:e1
75c75
< sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct
fixed naa.500a07510920882c
---
> sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct
fixed naa.500a075109208807
77c77
< sd1 at scsibus0 targ 2 lun 0:  SCSI3 0/direct
fixed naa.50025388500930cc
---
> sd1 at scsibus0 targ 5 lun 0:  SCSI3 0/direct
fixed naa.50025388a01274c6
107a108
> lm2 at wbsio0 port 0xca0/8: W83627DHG
109a111
> lm1: disabling sensors due to alias with lm2
118a121,138
> uhub8 at uhub5 port 1 "ATEN International product 0x8021" rev 1.10/1.00 addr 2
> uhidev2 at uhub8 port 1 configuration 1 interface 0 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev2: iclass 3/1
> ukbd1 at uhidev2: 8 variable keys, 6 key codes
> wskbd2 at ukbd1 mux 1
> wskbd2: connecting to wsdisplay0
> uhidev3 at uhub8 port 1 configuration 1 interface 1 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev3: iclass 3/1, 2 report ids
> uhid0 at uhidev3 reportid 1: input=2, output=0, feature=0
> uhid1 at uhidev3 reportid 2: input=1, output=0, feature=0
> uhidev4 at uhub8 port 1 configuration 1 interface 2 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev4: iclass 3/1
> ums1 at uhidev4: 5 buttons, Z dir
> wsmouse1 at ums1 mux 0
> uhidev5 at uhub8 port 1 configuration 1 interface 3 "ATEN International
Co. Ltd GCS1808 V3.2.313" rev 1.10/1.00 addr 3
> uhidev5: iclass 3/1
> ums2 at uhidev5: 3 buttons, Z dir
> wsmouse2 at ums2 mux 0
123c143,147
< root on sd0a (22cb25880c08c19f.a) swap on sd0b dump on sd0b
---
> root on sd0a (3a0229e574e4bfd1.a) swap on sd0b dump on sd0b

Re: anoncvs.html.head

[Stuart Henderson]

On 2015-09-11, Rob Pierce  wrote:
>src - Houses all source code for the OpenBSD Operating System.
>ports - Houses the OpenBSD 
> Ports.
> -  www - Houses all OpenBSD web pages. (Including this one).
> +  www - Houses all OpenBSD web pages (including this one).

I like that

>xenocara - Houses OpenBSD's active X.org v7 source tree.
>X11 and XF4 - Houses OpenBSD's adaptation of the
>http://www.XFree86.org/;>XFree86-3 and XFree86-4
> @@ -122,7 +122,7 @@ with only one part of the tree.  The two
>  which contains the files used to create the kernel, and src.tar.gz
>  which contains all the other "userland" utilities.
>  In general, however, you will usually want both of them installed.
> -Assuming the downloaded files, src.tar.gz,
> +Assuming the downloaded files src.tar.gz,
> sys.tar.gz and xenocara.tar.gz are in /usr:

I think this was OK as it was

> 
> -Not all people will wish to unpack all the file sets, but as the system
> +Not all people will wish to unpack all the source file, but as the system
>  must be kept in sync, you will generally need to set up all trees.

and this (and the new sentence doesn't quite make sense)

> 
> -You can also just use cvs(1) to "checkout" the source repository
> +You can also just use
> + href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1)
> +to "checkout" the source repository
>  for you. This is discussed in the next section.

OK I guess, though I don't think we need to hyperlink every instance of
a program name

> @@ -160,16 +162,12 @@ from the errata  For more information on these "flavors" of OpenBSD, see 
> here.
>  
> -Once you have decided which tree to follow, you must choose which 
> Anonymous
> -CVS server you are going to use.  A list of these servers is
> -below.
> -
> 
> -Once you have chosen which Anonymous CVS Server you 
> will
> -use, you can start using cvs. For those of you
> +Once you have decided which tree to follow, and which  href="#CVSROOT">Anonymous CVS Server you will

Please try and keep <80 columns in the source file where sensible

> +use, you can start using  href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1).
>  For those of you
>  who have CDs you can start with the CVS checkout that is on the CD by using
>  the method above to get the sources onto your system.
> -If you don't have a CD handy, use the method below to checkout the sources.
> +If you don't have a CD handy, use the method below to checkout the sources:
>  
> 
> First, start out by `get'-ing an initial tree:
> @@ -210,9 +208,11 @@ Confirm this, and the fingerprint will t
>   ...
> 
>  
> +
>  Note that the above format with SHA256 fingerprints was added after the
>  release of OpenBSD 5.6; older versions only use MD5 fingerprints.
>  
> +
>  Anytime afterwards, to `update' this tree:
>  (If you are following current):
> 
> @@ -234,7 +234,7 @@ to merge changes in.
>  NOTE:
>  If you are updating a source tree that you initially fetched
>  from a different server, or from a CD, you must
> -add the -d [cvsroot] option to cvs.
> +add the -d [cvsroot] option to cvs:
> 
>   # cd /usr/src
>   # cvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd
> @@ -295,11 +295,11 @@ directory, and a subsequent update will 
>  
> 
>  The anoncvs service gives fledgling developers a chance to learn CVS
> -operation and get thoroughly involved in the development process
> +operations and get thoroughly involved in the development process

"operation" already seem ok

>  before getting "commit" access -- as a result of showing useful
>  skills and high quality results they will naturally later be given
>  developer access.
> -As well, people providing patches can create their "diff"s relative
> +As well, people providing patches can create their diffs relative
>  to the CVS tree, which will ease integration.
>  
> Example usages for cvs(1)

Re: mysterious ulimit values

[luke350]

On 09/11/15 16:47, Chris Cappuccio wrote:

You [made an error] when you put pound signs in there. Just delete
those lines, or uncomment them and use appropriate values. Remove the
commented line with no values entirely. The commented lines prevent
the rest of default: class from being read.


Ah, you're right. Thanks for pointing it out.
Best regards,
Luke

Re: requesting help working around boot failures with supermicro atom board

[Benny Lofgren]

Hi Dewey,

On 2015-09-12 00:38, dewey.hyl...@gmail.com wrote:
> hi all. i’m having difficulty with this board:

I noticed your mail somehow got posted twice, but I'm commenting on the
first incarnation of it because the second had some characters like '\''
mangled (UTF-8 copy/paste issue I presume).

> Supermicro X7SPE-HD-D525 rev1
> i have several similar systems, each running an older version of OpenBSD for 
> a few years without incident. except this one …

You might already have tried this, but providing this information may
give important clues to the rest of us trying to help you:

Since you say that your other similar systems are successfully running
older versions of OpenBSD, have you tried running this new system with a
version that you know works on the other boards?

And if so, then have you tried moving on to subsequent versions in turn
until you find the one which breaks? That is a really important piece of
information.

Also, are those other systems "similar" or "identical"? If not
identical, what differs? This is also important to get a grip on the
problem.

Whether they are identical or not, showing us a dmesg diff with a known
working release booted from both a working and the non-working system
could also be helpful.


Regards,

/Benny

> 
> running OpenBSD 5.7 i386, from cold start it boots just fine and runs until 
> rebooted. once rebooted, however, prior to anything being displayed (i assume 
> this is early in the bios post phase) i get one very long beep. super micro 
> tells me this indicates inability to correctly initialize the memory. okay, 
> so i’ve changed memory for known working components and have the same issue. 
> at this point, the only thing that gets me booting again is to remove power 
> and then restore power. it then boots fine from cold start, and fails on the 
> next reboot (as in, “reboot” from the command line). once in long-beep 
> failure mode, neither the hardware reset button nor the power button can make 
> the machine boot again. the only thing that works is removing power. every 
> once in a while it will reboot successfully, only to fail in the same manner 
> on the next attempt.
> 
> super micro has had me flash bios, clear cmos, boot from different devices 
> and with nothing connected, etc. the results are the same: when rebooting 
> from openbsd, next boot fails until power is removed/restored. super micro 
> blames openbsd.
> 
> i installed linux (same hardware, overwrite openbsd 5.7) and scheduled a 
> reboot every 5 minutes and left it overnight. i logged 554 successful reboots.
> 
> i have since installed the latest available openbsd amd64 snapshot, and am 
> seeing the same failures.
> 
> i’m wondering if something could be disabled (boot -c ?) or if something else 
> raises a red flag and might have a workaround. this has me stumped. i would 
> very much appreciate a clue stick. 
> 
> dmesg follows:
> 
> OpenBSD 5.8-current (GENERIC.MP) #1364: Wed Sep  9 17:32:01 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4277665792 (4079MB)
> avail mem = 4144070656 (3952MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
> acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) 
> USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) 
> P0P6(S4) P0P7(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.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,DTES64,MWAIT,DS-CPL,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 199MHz
> cpu0: mwait min=64, max=64, C-substates=0.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 512KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu2: 512KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: 

Re: System clock hours behind, network hangs (amd64, -current)

[Mark Patruck]

On Sat, Sep 12, 2015 at 11:07:07AM +0200, Martin Pieuchot wrote:
> On 11/09/15(Fri) 18:56, Mark Patruck wrote:
> > On Fri, Sep 11, 2015 at 06:27:36PM +0200, Martin Pieuchot wrote:
> > > On 11/09/15(Fri) 18:07, Mark Patruck wrote:
> > > > dmesg below is currently running, but it also didn't work with a 2 week
> > > > old snapshot from the local mirror. (system was freshly installed)
> > > > 
> > > > Note: the machine hasn't been used over the last two months, so i've
> > > > double checked battery, memory, psu.
> > > > 
> > > > OpenBSD 5.8-current (GENERIC.MP) #0: Mon Sep  7 15:54:34 CEST 2015
> > > > bu...@aquila.paccotec.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > > Since you build your kernel yourself, I can't tell when you did your
> > > checkout and I'll bet you hit the window when rtisvalid(9) was in.
> > > 
> > > Could you try a -current checkout with this diff an tell me if you can
> > > reproduce the problem?
> > 
> > Thanks Martin. I'll report back asap.
> 
> Tree is moving fast, here's an updated diff.

No issues with the last kernel after app. 17 hours.

> > > Could you also tell me what are your nfs mounts? 
> > 
> > $ cat /etc/exports
> > /share/d0 -alldirs -mapall=umedia:media -ro mso
> > /share/d1 -alldirs -mapall=umedia:media -ro mso
> > 
> > $ mount | grep NFS
> > /dev/sd1a on /share/d0 type ffs (NFS exported, local, nodev, noexec, 
> > nosuid, softdep)
> > /dev/sd2a on /share/d1 type ffs (NFS exported, local, nodev, noexec, 
> > nosuid, softdep)
> > 
> 
> Interesting, the previous report I had with similar symptoms was about a
> machine using nested NFS mounts from two different servers.

Well, i don't think it's nfs related. Also a ping, nfs, sftp
transfer stalls/hangs for 1-2 seconds + (and that's really weird)
the clock is minutes behind within few hours though ntp is running.

> Please let me know what happen with the diff below,  thanks!

Thanks. New kernel running...

-- 
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74  F644 0D3C F66F F286 5E51

http://www.wrapped.cx

Re: System clock hours behind, network hangs (amd64, -current)

[Martin Pieuchot]

On 12/09/15(Sat) 14:45, Mark Patruck wrote:
> On Sat, Sep 12, 2015 at 11:07:07AM +0200, Martin Pieuchot wrote:
> > On 11/09/15(Fri) 18:56, Mark Patruck wrote:
> > > On Fri, Sep 11, 2015 at 06:27:36PM +0200, Martin Pieuchot wrote:
> > > > On 11/09/15(Fri) 18:07, Mark Patruck wrote:
> > > > > dmesg below is currently running, but it also didn't work with a 2 
> > > > > week
> > > > > old snapshot from the local mirror. (system was freshly installed)
> > > > > 
> > > > > Note: the machine hasn't been used over the last two months, so i've
> > > > > double checked battery, memory, psu.
> > > > > 
> > > > > OpenBSD 5.8-current (GENERIC.MP) #0: Mon Sep  7 15:54:34 CEST 2015
> > > > > 
> > > > > bu...@aquila.paccotec.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > 
> > > > Since you build your kernel yourself, I can't tell when you did your
> > > > checkout and I'll bet you hit the window when rtisvalid(9) was in.
> > > > 
> > > > Could you try a -current checkout with this diff an tell me if you can
> > > > reproduce the problem?
> > > 
> > >   Thanks Martin. I'll report back asap.
> > 
> > Tree is moving fast, here's an updated diff.
> 
>   No issues with the last kernel after app. 17 hours.

Which kernel?  Is it with or without the diff?  Could you send the
dmesg?

> > > > Could you also tell me what are your nfs mounts? 
> > > 
> > >   $ cat /etc/exports
> > >   /share/d0 -alldirs -mapall=umedia:media -ro mso
> > >   /share/d1 -alldirs -mapall=umedia:media -ro mso
> > > 
> > >   $ mount | grep NFS
> > >   /dev/sd1a on /share/d0 type ffs (NFS exported, local, nodev, noexec, 
> > > nosuid, softdep)
> > >   /dev/sd2a on /share/d1 type ffs (NFS exported, local, nodev, noexec, 
> > > nosuid, softdep)
> > > 
> > 
> > Interesting, the previous report I had with similar symptoms was about a
> > machine using nested NFS mounts from two different servers.
> 
>   Well, i don't think it's nfs related. Also a ping, nfs, sftp
>   transfer stalls/hangs for 1-2 seconds + (and that's really weird)
>   the clock is minutes behind within few hours though ntp is running.

Is it with the new kernel or did you saw that previously?


> > Please let me know what happen with the diff below,  thanks!
> 
>   Thanks. New kernel running...

With or without the diff?  Would you mind sharing dmesg?

Thanks for your help!
Martin

Re: System clock hours behind, network hangs (amd64, -current)

[Mark Patruck]

On Sat, Sep 12, 2015 at 03:09:54PM +0200, Martin Pieuchot wrote:
> On 12/09/15(Sat) 14:45, Mark Patruck wrote:
> > On Sat, Sep 12, 2015 at 11:07:07AM +0200, Martin Pieuchot wrote:
> > > On 11/09/15(Fri) 18:56, Mark Patruck wrote:
> > > > On Fri, Sep 11, 2015 at 06:27:36PM +0200, Martin Pieuchot wrote:
> > > > > On 11/09/15(Fri) 18:07, Mark Patruck wrote:
> > > > > > dmesg below is currently running, but it also didn't work with a 2 
> > > > > > week
> > > > > > old snapshot from the local mirror. (system was freshly installed)
> > > > > > 
> > > > > > Note: the machine hasn't been used over the last two months, so i've
> > > > > > double checked battery, memory, psu.
> > > > > > 
> > > > > > OpenBSD 5.8-current (GENERIC.MP) #0: Mon Sep  7 15:54:34 CEST 2015
> > > > > > 
> > > > > > bu...@aquila.paccotec.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > > 
> > > > > Since you build your kernel yourself, I can't tell when you did your
> > > > > checkout and I'll bet you hit the window when rtisvalid(9) was in.
> > > > > 
> > > > > Could you try a -current checkout with this diff an tell me if you can
> > > > > reproduce the problem?
> > > > 
> > > > Thanks Martin. I'll report back asap.
> > > 
> > > Tree is moving fast, here's an updated diff.
> > 
> > No issues with the last kernel after app. 17 hours.
> 
> Which kernel?  Is it with or without the diff?  Could you send the
> dmesg?

Userland + kernel inc your diff 17 hours ago

### dmesg
OpenBSD 5.8-current (GENERIC.MP) #0: Fri Sep 11 20:19:14 CEST 2015
bu...@aquila.paccotec.de:/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792 (4079MB)
avail mem = 4144062464 (3952MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) 
USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) 
P0P6(S4) P0P7(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.26 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,DTES64,MWAIT,DS-CPL,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 200MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 3
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:91:cd:d0
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:91:cd:d1
uhci0 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci4 at ppb3 bus 4
vga1 at pci4 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 3.0Gb/s
ahci0: port 2: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed 
naa.50025388a03f4c8d
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
sd1 

Re: anoncvs.html.head

[Benny Lofgren]

Hi Rob,

On 2015-09-12 01:15, Rob Pierce wrote:
> This diff is a resend against the correct file:
>  - some punctuation, line spacing and minor grammar fixes
>  - "file sets" has a special meaning, so don't refer to src.tar.gz, 
> xenocara.tar.gc,ports.tar.gz as "file sets"
>  - cvs(1) hrefs
>  - "diffs" is already used earlier on the page, so don't quote it
> Index: anoncvs.html.head
> ===
> RCS file: /cvs/www/build/mirrors/anoncvs.html.head,v
> retrieving revision 1.42
> diff -u -p -r1.42 anoncvs.html.head
> --- anoncvs.html.head 2 Sep 2015 13:11:30 -   1.42
> +++ anoncvs.html.head 11 Sep 2015 22:10:15 -

Just a few comments inline below. I think you posted this or a similar
diff to tech@ the other day, so maybe this is in the wrong place, but
I'll leave the comment as well in misc@ to avoid confusion.


...
> @@ -135,11 +135,13 @@ Assuming the downloaded files, src.t
>  
>  
>  
> -Not all people will wish to unpack all the file sets, but as the system
> +Not all people will wish to unpack all the source file, but as the system

I think "source files" (plural), alternatively "all of the source file"
depending on your intention?

>  must be kept in sync, you will generally need to set up all trees.
>  
>  
> -You can also just use cvs(1) to "checkout" the source repository
> +You can also just use
> + href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1)
> +to "checkout" the source repository

Is that the correct URL? The use of "sektion" (which is a Swedish,
Danish or German spelling :-) ) instead of "sec" caught my eye.

When I do the same search directly from www.openbsd.org I get this:

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/cvs.1?query=cvs=1

(I realize that the link you used is the same one already used elsewhere
in this page. But even if I copy and paste that link into my browser,
the web server redirects it to the one I pasted here. Maybe there is
some legacy stuff going on here, perhaps a server side change not yet
reflected in all of the html pages?)

>  for you. This is discussed in the next section.
>  
>  
> @@ -160,16 +162,12 @@ from the errata  For more information on these "flavors" of OpenBSD, see 
>  here.
>  
> -Once you have decided which tree to follow, you must choose which 
> Anonymous
> -CVS server you are going to use.  A list of these servers is
> -below.
> -
>  
> -Once you have chosen which Anonymous CVS Server you 
> will
> -use, you can start using cvs. For those of you
> +Once you have decided which tree to follow, and which  href="#CVSROOT">Anonymous CVS Server you will
> +use, you can start using  href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1).
>  For those of you

I don't know about you or the developers, but personally I kind of
prefer the original wording and paragraph division, except I would
change the second paragraph's repetitious use of "Once you have..." to
something like "When you have..." instead.


And maybe remove the second href to the cvs server list. I don't know
about official policy here, but having several identical links so close
to each other in a text always confuses me and makes me click on all of
them, only to be annoyed I end up in the same place. :-)

One objection to this would be that people who only read the second
paragraph in this example would miss the link altogether. I would then
contend that if you don't have the habit and patience of reading ALL the
relevant parts of a given piece of documentation, you're not going to do
well with OpenBSD (or computing in general) anyway...


Also, while here, maybe it would make more sense to write "If you have
CDs" rather than "For those of you who have CDs", since the rest of the
page is phrased such that the reader is addressed with "you" rather than
as a teacher would address a lecture hall full of students.

>  who have CDs you can start with the CVS checkout that is on the CD by using
>  the method above to get the sources onto your system.
> -If you don't have a CD handy, use the method below to checkout the sources.
> +If you don't have a CD handy, use the method below to checkout the sources:
>  
>  
>  First, start out by `get'-ing an initial tree:
> @@ -210,9 +208,11 @@ Confirm this, and the fingerprint will t
>   ...
>  
>  
> +
>  Note that the above format with SHA256 fingerprints was added after the
>  release of OpenBSD 5.6; older versions only use MD5 fingerprints.
>  
> +
>   Anytime afterwards, to `update' this tree:
>   (If you are following current):
>  
> @@ -234,7 +234,7 @@ to merge changes in.
>   NOTE:
>  If you are updating a source tree that you initially fetched
>  from a different server, or from a CD, you must
> -add the -d [cvsroot] option to cvs.
> +add the -d [cvsroot] option to cvs:
>  
>   # cd /usr/src
>   # cvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd
> @@ -295,11 +295,11 @@ directory, 

Re: anoncvs.html.head

[Rob Pierce]

Thanks Benny. I will review again and resubmit.

Some responses in-line below.

- Original Message -
> From: "Benny Lofgren" 
> To: "misc" 
> Sent: Saturday, September 12, 2015 8:01:58 AM
> Subject: Re: anoncvs.html.head

> Hi Rob,
> 
> On 2015-09-12 01:15, Rob Pierce wrote:
>> This diff is a resend against the correct file:
>>  - some punctuation, line spacing and minor grammar fixes
>>  - "file sets" has a special meaning, so don't refer to src.tar.gz,
>>  xenocara.tar.gc,ports.tar.gz as "file sets"
>>  - cvs(1) hrefs
>>  - "diffs" is already used earlier on the page, so don't quote it
>> Index: anoncvs.html.head
>> ===
>> RCS file: /cvs/www/build/mirrors/anoncvs.html.head,v
>> retrieving revision 1.42
>> diff -u -p -r1.42 anoncvs.html.head
>> --- anoncvs.html.head2 Sep 2015 13:11:30 -   1.42
>> +++ anoncvs.html.head11 Sep 2015 22:10:15 -
> 
> Just a few comments inline below. I think you posted this or a similar
> diff to tech@ the other day, so maybe this is in the wrong place, but
> I'll leave the comment as well in misc@ to avoid confusion.
> 
> 
> ...
>> @@ -135,11 +135,13 @@ Assuming the downloaded files, src.t
>>  
>>  
>>  
>> -Not all people will wish to unpack all the file sets, but as the system
>> +Not all people will wish to unpack all the source file, but as the system
> 
> I think "source files" (plural), alternatively "all of the source file"
> depending on your intention?

Yes, I missed that - thanks.

> 
>>  must be kept in sync, you will generally need to set up all trees.
>>  
>>  
>> -You can also just use cvs(1) to "checkout" the source repository
>> +You can also just use
>> +> href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1)
>> +to "checkout" the source repository
> 
> Is that the correct URL? The use of "sektion" (which is a Swedish,
> Danish or German spelling :-) ) instead of "sec" caught my eye.
> 
> When I do the same search directly from www.openbsd.org I get this:
> 
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/cvs.1?query=cvs=1
> 
> (I realize that the link you used is the same one already used elsewhere
> in this page. But even if I copy and paste that link into my browser,
> the web server redirects it to the one I pasted here. Maybe there is
> some legacy stuff going on here, perhaps a server side change not yet
> reflected in all of the html pages?)

I will look into that. I must admit that I tend to grab existing text to
complete an href, but in the future I will do the lookup and grab the
actual URL. I was wondering were sektion came from!

>>  for you. This is discussed in the next section.
>>  
>>  
>> @@ -160,16 +162,12 @@ from the errata>  For more information on these "flavors" of OpenBSD, see
>>  here.
>>  
>> -Once you have decided which tree to follow, you must choose which 
>> Anonymous
>> -CVS server you are going to use.  A list of these servers is
>> -below.
>> -
>>  
>> -Once you have chosen which Anonymous CVS Server you 
>> will
>> -use, you can start using cvs. For those of you
>> +Once you have decided which tree to follow, and which > href="#CVSROOT">Anonymous CVS Server you will
>> +use, you can start using > href="http://www.openbsd.org/cgi-bin/man.cgi?query=cvssektion=1format=html;>cvs(1).
>> For those of you
> 
> I don't know about you or the developers, but personally I kind of
> prefer the original wording and paragraph division, except I would
> change the second paragraph's repetitious use of "Once you have..." to
> something like "When you have..." instead.

Ok. I should stay away from "style" changes, and stick to obvious corrections
and/or functional text changes. This just seemed a bit awkward to me.

> 
> 
> And maybe remove the second href to the cvs server list. I don't know
> about official policy here, but having several identical links so close
> to each other in a text always confuses me and makes me click on all of
> them, only to be annoyed I end up in the same place. :-)
> 
> One objection to this would be that people who only read the second
> paragraph in this example would miss the link altogether. I would then
> contend that if you don't have the habit and patience of reading ALL the
> relevant parts of a given piece of documentation, you're not going to do
> well with OpenBSD (or computing in general) anyway...

Not sure how to consistently handle this one, but I agree the pages can
get cluttered with hrefs. I was just trying to be consistent with current
practice (which seemed to be every time).

> Also, while here, maybe it would make more sense to write "If you have
> CDs" rather than "For those of you who have CDs", since the rest of the
> page is phrased such that the reader is addressed with "you" rather than
> as a teacher would address a lecture hall full of students.

Ok.
 
> 
>>  who have CDs you can start with the CVS 

Re: requesting help working around boot failures with supermicro atom board

[John E.P. Hynes]

Try booting the SP kernel and see if that works.  If it does, you might
be running into a variant of an issie I've had on my SuperMicro boxen...

-John

On 09/11/2015 06:38 PM, dewey.hyl...@gmail.com wrote:
> hi all. i’m having difficulty with this board:
> 
> Supermicro X7SPE-HD-D525 rev1
> 
> i have several similar systems, each running an older version of OpenBSD for 
> a few years without incident. except this one …
> 
> running OpenBSD 5.7 i386, from cold start it boots just fine and runs until 
> rebooted. once rebooted, however, prior to anything being displayed (i assume 
> this is early in the bios post phase) i get one very long beep. super micro 
> tells me this indicates inability to correctly initialize the memory. okay, 
> so i’ve changed memory for known working components and have the same issue. 
> at this point, the only thing that gets me booting again is to remove power 
> and then restore power. it then boots fine from cold start, and fails on the 
> next reboot (as in, “reboot” from the command line). once in long-beep 
> failure mode, neither the hardware reset button nor the power button can make 
> the machine boot again. the only thing that works is removing power. every 
> once in a while it will reboot successfully, only to fail in the same manner 
> on the next attempt.
> 
> super micro has had me flash bios, clear cmos, boot from different devices 
> and with nothing connected, etc. the results are the same: when rebooting 
> from openbsd, next boot fails until power is removed/restored. super micro 
> blames openbsd.
> 
> i installed linux (same hardware, overwrite openbsd 5.7) and scheduled a 
> reboot every 5 minutes and left it overnight. i logged 554 successful reboots.
> 
> i have since installed the latest available openbsd amd64 snapshot, and am 
> seeing the same failures.
> 
> i’m wondering if something could be disabled (boot -c ?) or if something else 
> raises a red flag and might have a workaround. this has me stumped. i would 
> very much appreciate a clue stick. 
> 
> dmesg follows:
> 
> OpenBSD 5.8-current (GENERIC.MP) #1364: Wed Sep  9 17:32:01 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4277665792 (4079MB)
> avail mem = 4144070656 (3952MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
> acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) 
> USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) 
> P0P6(S4) P0P7(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.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,DTES64,MWAIT,DS-CPL,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 199MHz
> cpu0: mwait min=64, max=64, C-substates=0.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 512KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu2: 512KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu3: 512KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 1, remapped to apid 4
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 4 (P0P1)
> acpiprt2 at acpi0: bus 1 (P0P4)
> acpiprt3 at acpi0: bus 2 (P0P8)
> acpiprt4 at acpi0: bus 3 (P0P9)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpicpu2 at acpi0: C1(@1 halt!)
> acpicpu3 at acpi0: C1(@1 halt!)
> 

Re: System clock hours behind, network hangs (amd64, -current)

[Mark Patruck]

On Sat, Sep 12, 2015 at 03:09:54PM +0200, Martin Pieuchot wrote:
> > > Interesting, the previous report I had with similar symptoms was about a
> > > machine using nested NFS mounts from two different servers.
> > 
> > Well, i don't think it's nfs related. Also a ping, nfs, sftp
> > transfer stalls/hangs for 1-2 seconds + (and that's really weird)
> > the clock is minutes behind within few hours though ntp is running.
> 
> Is it with the new kernel or did you saw that previously?

Sorry...missed that one. With the kernel+your diff from 17 hours ago
i had no issues at all, but as the error showed up between 5-48 hours
after reboot, i'll have to wait to make sure everything works normally.

-- 
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74  F644 0D3C F66F F286 5E51

http://www.wrapped.cx