crash on urtwn removal

2015-04-26 Thread Remi Locherer
>Synopsis:  crash on urtwn removal
>Environment:
System  : OpenBSD 5.7
Details : OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25 
20:12:31 MDT 2015
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

>Description:
Since a couple of month every now and then I'm getting a 
"urtwn0: device timeout". Usually I deal with it by unlugging the 
urtwn device and plug it in again, then run "sh /etc/netstart urtwn0".

Sometimes the systems crashes when I unplug the urtwn device. 

Photos from ddb after such a crash:

https://relo.ch/crash_on_urtwn_removal-trace_part1.jpg
https://relo.ch/crash_on_urtwn_removal-trace_part2.jpg
https://relo.ch/crash_on_urtwn_removal-ps_part1.jpg
https://relo.ch/crash_on_urtwn_removal-ps_part2.jpg
https://relo.ch/crash_on_urtwn_removal-ps_part3.jpg


dmesg:
OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25 20:12:31 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3760242688 (3586MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.41 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.16 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 a

Re: crash on urtwn removal

2015-04-26 Thread Stefan Sperling
On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
>   Since a couple of month every now and then I'm getting a 
>   "urtwn0: device timeout". Usually I deal with it by unlugging the 
>   urtwn device and plug it in again, then run "sh /etc/netstart urtwn0".

Is ifconfig down/up (or just 'sh /etc/netstart urtwn0') not enough?
That is essentially what the driver should be doing in this situation.
However, USB wifi drivers which need to load firmware currently don't
reset properly when transmit times out -- they simply do nothing instead
of resetting the interface.


>   Sometimes the systems crashes when I unplug the urtwn device. 
> 
>   Photos from ddb after such a crash:
> 
>   https://relo.ch/crash_on_urtwn_removal-trace_part1.jpg
>   https://relo.ch/crash_on_urtwn_removal-trace_part2.jpg
>   https://relo.ch/crash_on_urtwn_removal-ps_part1.jpg
>   https://relo.ch/crash_on_urtwn_removal-ps_part2.jpg
>   https://relo.ch/crash_on_urtwn_removal-ps_part3.jpg

Can you please recompile your kernel with
  makeoptions DEBUG="-g"
in the config when reproducing crashes? That's slightly more convenient
for us to debug since ddb output will contain line numbers.

Something is going wrong in the IPv6 code. This problem is not specific
to urtwn(4). The relevant part of the trace is:

Stopped at find_pfxlist_reachable_router+0x15: movq 0x10(%eax),%rdi

find_pfxlist_reachable_router()
pfxlist_onlink_check()
prelist_remove()
nd6_purge()
in6_ifdetach()
if_detach()
urtwn_detach()
config_detach()
usbd_detach()
uhub_explore()
uhub_explore()
usb_explore()
usb_task_thread()

> dmesg:
> OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25 20:12:31 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3881746432 (3701MB)
> avail mem = 3760242688 (3586MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
> bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013
> bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI 
> MSDM UEFI UEFI
> acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
> PXSX(S4) RP07(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.41 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.16 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (P0P1)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus -1 (RP02)
> acpiprt4 at acpi0: bus -1 (RP03)
> acpiprt5 at acpi0: bus 2 (RP04)
> acpiprt6 at acpi0:

Re: OpenBSD <= 5.6 Multiple Local Kernel Panics (malformed ELF executable in user-land)

2015-04-26 Thread sam
On Sat, 25 Apr 2015 22:42:41 -0700
Philip Guenther  wrote:

> On Thu, 9 Apr 2015, Alejandro Hernández wrote:
> > Last year I reported a local kernel panic in 5.5 <...> however,
> > I?ve found three more affecting <= 5.6 in sys/uvm/uvm_map.c.
> > Attached the poc code and the output of trace and ps of one of the
> > panics.
> 
> Thank you for this report.  As far as we could tell, there was a
> single cause to all three cases in the supplied proof-of-concept
> code; a fix for that has been committed to -current.
> 
> 
> Philip Guenther
> guent...@openbsd.org
> 

Hi,

Will this be in the errata for 5.7?

Thank you!



Re: typo in pf.conf - allow X11 connections from external interface

2015-04-26 Thread Danilo Falcão
Closed means the range 6000:6009 isn't  filtered when I want only 22 to be
open.

nmap just pointed that out


On Sun, Apr 26, 2015 at 4:40 AM, Philip Guenther 
wrote:

> On Sat, 25 Apr 2015, Danilo Falcão wrote:
> > There's a typo in the original pf.conf (OpenBSD 5.6)
> >
> > - Original /etc/pf.conf
> >
> > *# By default, do not permit remote connections to X11*
> > *block return in on ! lo0 proto tcp to port 6000:6010*
> >
> > - Result (nmap)
> >
> > rembrandt:~ root# nmap -P0 jumbo.falcao.org
> >
> > Starting Nmap 6.47 (
> https://urldefense.proofpoint.com/v2/url?u=http-3A__nmap.org&d=BQIBaQ&c=Vxt5e0Osvvt2gflwSlsJ5DmPGcPvTRKLJyp031rXjhg&r=UiBcMWGRBqfiBnuYGz_BdxeNkPmhNSwQ-rm1SvEkgxQ&m=IrU_JuBx6x14pzbhUnGvSKewVdPd8tmQ19IXPnawzOs&s=cCLwZOay3p8UrDWTOCPNUa7hlF_zEFUkYeG8RsZur74&e=
> ) at 2015-04-26 04:24 CEST
> > Nmap scan report for jumbo.falcao.org (184.107.114.200)
> > Host is up (0.14s latency).
> > Not shown: 990 filtered ports
> > PORT STATE  SERVICE
> > 22/tcp   open   ssh
> > 6000/tcp closed X11
> > 6001/tcp closed X11:1
> > 6002/tcp closed X11:2
> > 6003/tcp closed X11:3
> > 6004/tcp closed X11:4
> > 6005/tcp closed X11:5
> > 6006/tcp closed X11:6
> > 6007/tcp closed X11:7
> > 6009/tcp closed X11:9
> >
> > Nmap done: 1 IP address (1 host up) scanned in 11.52 seconds
> > rembrandt:~ root#
> >
> > If I remove the "!", then all is fine. Hope it helps
>
>
>
> Please explain what you think the output of nmap *means*, particularly the
> word "closed".
>


Re: typo in pf.conf - allow X11 connections from external interface

2015-04-26 Thread Stuart Henderson
On 2015/04/26 12:48, Danilo Falcão wrote:
> Closed means the range 6000:6009 isn't  filtered when I want only 22 to be
> open.

That's incorrect.

> > > *block return in on ! lo0 proto tcp to port 6000:6010*

This rule says:

"Block TCP packets to port 6000-6010 coming in on any interface other than lo0,
and return an ICMP port unreachable message when anybody tries".

Some people might prefer it without the "port unreachable" message in which case
they can change "return" to "drop".

By removing the !, you have changed it to blocking 6000-6010 on the
loopback but permitting them on all other interfaces.




Re: typo in pf.conf - allow X11 connections from external interface

2015-04-26 Thread Danilo Falcão
bingo!

after changing "return" to "drop" it shows now the expected result
(filtered)

current line: block drop in on ! lo0 proto tcp to port 6000:6010

thanks guys

-dfs

On Sun, Apr 26, 2015 at 12:53 PM, Stuart Henderson 
wrote:

> On 2015/04/26 12:48, Danilo Falcão wrote:
> > Closed means the range 6000:6009 isn't  filtered when I want only 22 to
> be
> > open.
>
> That's incorrect.
>
> > > > *block return in on ! lo0 proto tcp to port 6000:6010*
>
> This rule says:
>
> "Block TCP packets to port 6000-6010 coming in on any interface other than
> lo0,
> and return an ICMP port unreachable message when anybody tries".
>
> Some people might prefer it without the "port unreachable" message in
> which case
> they can change "return" to "drop".
>
> By removing the !, you have changed it to blocking 6000-6010 on the
> loopback but permitting them on all other interfaces.
>
>


Re: crash on urtwn removal

2015-04-26 Thread Remi Locherer
On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
> On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
> > Since a couple of month every now and then I'm getting a 
> > "urtwn0: device timeout". Usually I deal with it by unlugging the 
> > urtwn device and plug it in again, then run "sh /etc/netstart urtwn0".
> 
> Is ifconfig down/up (or just 'sh /etc/netstart urtwn0') not enough?

No, it's not enough. After the first timeout message on the console I
executed "sh /etc/netstart urtwn0". The result was:

Console log for mistral.relo.ch
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951684 > 4
usb_transfer_complete: actlen > len 4294951044 > 4
usb_transfer_complete: actlen > len 4294951300 > 4
usb_transfer_complete: actlen > len 4294951308 > 4
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951300 > 4
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951308 > 4
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951948 > 4
usb_transfer_complete: actlen > len 4294951684 > 4
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951304 > 2
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951300 > 4
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951682 > 2
usb_transfer_complete: actlen > len 4294951300 > 4
urtwn0: device timeout
usb_transfer_complete: actlen > len 4294951300 > 4
usb_transfer_complete: actlen > len 4294951172 > 4
urtwn0: device timeout

My /etc/hostname.urtwn0:

nwid tsunami wpakey XXX
dhcp
inet6 autoconf
!pkill -9 -lf wifinwid
!/etc/wifinwid \$if &

The script is the one from here:
http://undeadly.org/cgi?action=article&sid=20130208141628


> That is essentially what the driver should be doing in this situation.
> However, USB wifi drivers which need to load firmware currently don't
> reset properly when transmit times out -- they simply do nothing instead
> of resetting the interface.
> 
> 
> > Sometimes the systems crashes when I unplug the urtwn device. 
> > 
> > Photos from ddb after such a crash:
> > 
> > https://relo.ch/crash_on_urtwn_removal-trace_part1.jpg
> > https://relo.ch/crash_on_urtwn_removal-trace_part2.jpg
> > https://relo.ch/crash_on_urtwn_removal-ps_part1.jpg
> > https://relo.ch/crash_on_urtwn_removal-ps_part2.jpg
> > https://relo.ch/crash_on_urtwn_removal-ps_part3.jpg
> 
> Can you please recompile your kernel with
>   makeoptions DEBUG="-g"
> in the config when reproducing crashes? That's slightly more convenient
> for us to debug since ddb output will contain line numbers.

I'll do that and report back.

> 
> Something is going wrong in the IPv6 code. This problem is not specific
> to urtwn(4). The relevant part of the trace is:
> 
> Stopped at find_pfxlist_reachable_router+0x15: movq 0x10(%eax),%rdi
> 
> find_pfxlist_reachable_router()
> pfxlist_onlink_check()
> prelist_remove()
> nd6_purge()
> in6_ifdetach()
> if_detach()
> urtwn_detach()
> config_detach()
> usbd_detach()
> uhub_explore()
> uhub_explore()
> usb_explore()
> usb_task_thread()



relayd crash on load/reload

2015-04-26 Thread trondd

Relayd is crashing on configuration reload.

I am running a snapshot from 4/18 but running the relayd source from CVS 
as of 4/26.


I am running "relayd -d -f /etc/relayd.conf".  It will also crash when 
daemonized.


Run "relayctl reload", sometimes takes 2 or three invocations.

Output:
# relayd -d -f /etc/relayd.conf
startup
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
hce exiting, pid 10254
fatal: parent: Broken pipe
ca exiting, pid 16426
ca exiting, pid 25491
pfe exiting, pid 26479
ca exiting, pid 15412
relay exiting, pid 17354
relay exiting, pid 23961

Also, sometimes get the core dump:

# relayd -d -f /etc/relayd.conf
startup
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
pfe exiting, pid 4832
ca exiting, pid 32218
ca exiting, pid 22794
ca exiting, pid 18534
Segmentation fault (core dumped)
hce exiting, pid 2281
relay exiting, pid 11139
relay exiting, pid 13802
relay exiting, pid 31645


# gdb relayd

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.

This GDB was configured as "amd64-unknown-openbsd5.7"...
(gdb) run -d -f /etc/relayd.conf
Starting program: /usr/src/usr.sbin/relayd/relayd -d -f /etc/relayd.conf
startup
[New process 8136]
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
protocol 1: name test1
flags: used, relay flags:
tcp flags: nodelay, sack, socket buffer size
type: http
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)
adding 1 hosts from table test1:8080 (no check)

Program received signal SIGSEGV, Segmentation fault.
0x183478b09b5b in table_inherit (tb=0x1836a6b04000) at parse.y:3128
3128TAILQ_INSERT_TAIL(&conf->sc_hosts, h, 
globalentry);

(gdb) bt
#0  0x183478b09b5b in table_inherit (tb=0x1836a6b04000) at 
parse.y:3128

#1  0x183478b0b429 in yyparse () at parse.y:705
#2  0x183478b0f227 in load_config (filename=Variable "filename" is 
not available.

) at parse.y:2653
#3  0x183478b29b61 in parent_reload (env=0x18369c987000, reset=0, 
filename=0x7f7c883e "/etc/relayd.conf") at relayd.c:367
#4  0x183478b29e4e in parent_dispatch_pfe (fd=Variable "fd" is not 
available.

) at relayd.c:449
#5  0x183478b1c41a in proc_dispatch (fd=6, event=Variable "event" is 
not available.

) at proc.c:481
#6  0x183776d79218 in event_base_loop (base=0x1836cb881c00, 
flags=Variable "flags" is not available.

) at /usr/src/lib/libevent/event.c:350
#7  0x183478b2a36d in main (argc=Variable "argc" is not available.
) at relayd.c:278
(gdb)


relayd.conf:

# $OpenBSD: relayd.conf,v 1.3 2014/12/12 10:05:09 reyk Exp $
#
# Macros
#
ext_addr="192.168.1.1"
webhost1="10.0.0.1"
webhost2="10.0.0.2"
sshhost1="10.0.0.3"

#
# Global Options
#
# interval 10
# timeout 1000
# prefork 5

#
# Each table will be mapped to a pf table.
#
table  { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL/TLS 
acceleration

#
http protocol test1 {
# Various TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}

relay www1 {
listen on 127.0.0.1 port 80
protocol test1

forward to  port 8080
}

dmesg:

OpenBSD 5.7-current (RAMDISK_CD) #853: Sat Apr 18 15:21:00 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4242014208 (4045MB)
avail mem = 4111736832 (3921MB)
mainbu