Re: Grammar and style edits to installation guide

2019-07-09 Thread Ian McWilliam
Isn't Unix a trademark of the Open Group? Hence the usage of Unix-like or Un*x..


Ian McWilliam



From: owner-t...@openbsd.org  on behalf of Jason 
McIntyre 
Sent: Tuesday, 9 July 2019 4:14 PM
To: tech@openbsd.org
Subject: Re: Grammar and style edits to installation guide

On Tue, Jul 09, 2019 at 07:43:50AM +0200, Otto Moerbeek wrote:
> On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote:
>
> I don't know our stance on Unix vs Un*x. I'll leave this to some
> native speaker, like jmc@ who knows all about commas (and much more)
> :-)
>
>-Otto
>

hi.

i'm fairly sure Un*x is meant to denote the various flavours of unix,
and is probably pretty widespread in our docs. however i haven;t checked
that. i don;t really see a reason to change it unless we've somehow
decided that it doesn;t make sense and we make such changes wholesale.

i'll try to comment on the rest of the diff inline..

> I'll leave this to jmc or some other native speaker. S
> > Otto Moerbeek  wrote:
> > > On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote:
> > >
> > > > I noticed one thing that bothered me and decided to look for other
> > > > things that bothered me. Changes were made without reference to the code
> > > > of the installation program and without checking that the installer
> > > > behaves as documented. I believe the included changes are harmless in
> > > > that respect. I'm happy to provide explanations of any given line edit
> > > > on request, but I hope they are self-explanatory. `make allarchs` ran
> > > > without issues and I don't seem to have broken any formatting.
> > > >
> > > > Regards,
> > > > Evan Silberman
> > > >
> > > >
> > > > Index: m4.common
> > > > ===
> > > > RCS file: /cvs/src/distrib/notes/m4.common,v
> > > > retrieving revision 1.127
> > > > diff -u -p -r1.127 m4.common
> > > > --- m4.common   23 Aug 2017 02:59:45 -  1.127
> > > > +++ m4.common   8 Jul 2019 05:36:28 -
> > > > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > > >  dnl Describes the serial terminal setup.
> > > >  define({:-OpenBSDInstallPart3-:},
> > > >  {:-Once the kernel has loaded, you will be presented with the
> > > > -   OpenBSD kernel boot messages which contain information about
> > > > -   the hardware that was detected and supported by OpenBSD.
> > > > +   OpenBSD kernel boot messages, which contain information about
> > > > +   the supported hardware that was detected by OpenBSD.
> > >
> > > This is not true. OpenBSD does print information about hardware
> > > detected but not supported. e.g.:
> > >
> > > "usb3_phy0" at mainbus0 not configured
> > >
> > >-Otto
> >
> > Below version corrects this as well as changing a few remaining instances of
> > 'UN*X' to 'Unix'.
> >
> >
> > Index: INSTALL
> > ===
> > RCS file: /cvs/src/distrib/notes/INSTALL,v
> > retrieving revision 1.53
> > diff -u -p -r1.53 INSTALL
> > --- INSTALL 24 Jun 2019 01:21:46 -  1.53
> > +++ INSTALL 8 Jul 2019 17:24:49 -
> > @@ -7,7 +7,7 @@ INSTALLATION NOTES for OpenBSD/MACHINE O
> >  What is OpenBSD?
> >  
> >
> > -OpenBSD is a fully functional, multi-platform UN*X-like Operating
> > +OpenBSD is a fully functional, multi-platform Unix-like Operating
> >  System based on Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite.
> >  There are several operating systems in this family, but OpenBSD
> >  differentiates itself by putting security and correctness first.  The
> > @@ -137,7 +137,7 @@ Using online OpenBSD documentation:
> >  ---
> >
> >  Documentation is available if you first install the manual pages
> > -distribution set.  Traditionally, the UN*X "man pages" (documentation)
> > +distribution set.  Traditionally, the Unix "man pages" (documentation)
> >  are denoted by 'name(section)'.  Some examples of this are
> >
> >  intro(1),
> > Index: m4.common
> > ===
> > RCS file: /cvs/src/distrib/notes/m4.common,v
> > retrieving revision 1.127
> > diff -u -p -r1.127 m4.common
> > --- m4.common   23 Aug 2017 02:59:45 -00

Re: ld.so speedup (part 2)

2019-04-27 Thread Ian McWilliam



On 28/4/19, 12:56 am, "owner-t...@openbsd.org on behalf of Otto Moerbeek"
 wrote:

>On Sat, Apr 27, 2019 at 04:43:14PM +0200, Otto Moerbeek wrote:
>
>> On Sat, Apr 27, 2019 at 04:37:23PM +0200, Antoine Jacoutot wrote:
>> 
>> > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote:
>> > > The diff below speeds up ld.so library intialisation where the
>>dependency
>> > > tree is broad and deep, such as samba's smbd which links over 100
>>libraries.
>> > > 
>> > > See for example
>>https://marc.info/?l=openbsd-misc=155007285712913=2
>> > > 
>> > > See https://marc.info/?l=openbsd-tech=155637285221396=2 for
>>part 1
>> > > that speeds up library loading.
>> > > 
>> > > The timings below are for /usr/local/sbin/smbd --version:
>> > > 
>> > > Timing without either diff  : 6m45.67s real  6m45.65s user
>>0m00.02s system
>> > > Timing with part 1 diff only: 4m42.88s real  4m42.85s user
>>0m00.02s system
>> > > Timing with part 2 diff only: 2m02.61s real  2m02.60s user
>>0m00.01s system
>> > > Timing with both diffs  : 0m00.03s real  0m00.03s user
>>0m00.00s system
>> > > 
>> > > Note that these timings are for a build of a recent samba master
>>tree
>> > > (linked with kerberos) which is probably slower than the OpenBSD
>>port.
>> > > 
>> > > Nathanael
>> > 
>> > Wow. Tried your part1 and part2 diffs and the difference is indeed
>>insane!
>> > mail/evolution always took 10+ seconds to start for me and now it's
>>almost
>> > instant...
>> > Crazy... But this sounds too good to be true ;-)
>> > What are the potential regressions?
>> 
>> Speaking off regression tests, we have quite en extensive collection.
>> The tests in libexec/ld.so should all pass.
>
>And the do on amd64
>
>> 
>>  -Otto
>> 
>> 

The results look good but it still doesn¹t resolve the root cause of the
issue.
Using both patches on old hardware helps speed up the process but I still
see the rc script timeout before smbd is loaded causing the rest of the
samba processes to fail to load. This did not happen under 6.4 (amd64) so
the change of linker / compiler update is still potentially where the
problem may lie. 

Starting smbd with both patches
 0m46.55s real 0m46.47s user 0m00.07s system


Would still be good to see this work committed though.

Ian McWilliam

OpenBSD 6.5 (GENERIC.MP) #0: Mon Apr 15 16:28:00 AEST 2019

ianm@ianm-openbsd65.localdomain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6424494080 (6126MB)
avail mem = 6220148736 (5931MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (55 entries)
bios0: vendor Award Software International, Inc. version "F10d" date
07/22/2010
bios0: Gigabyte Technology Co., Ltd. GA-MA790X-DS4
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT HPET MCFG APIC
acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
USB5(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4)
PCE7(S4) PCE8(S4) PCE9(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9750 Quad-Core Processor, 2411.28 MHz, 10-02-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDT
SCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,
OSVW,IBS,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu0: AMD erratum 721 detected and fixed
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, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) 9750 Quad-Core Processor, 2410.99 MHz, 10-02-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL
USH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDT
SCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,
OSVW,IBS,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu1: ITLB 32 4KB 

Re: Removing PF

2019-03-31 Thread Ian McWilliam
"peeing on, or even integration into baby mulching
machines or atomic bombs to be dropped on Australia"

That's a lot of missing features to implement in one release cycle.

Ian McWilliam


From: owner-t...@openbsd.org  on behalf of Claudio 
Jeker 
Sent: Monday, 1 April 2019 4:01 PM
To: tech@openbsd.org
Subject: Removing PF

There have been internal discussions about OpenBSD also removing the pf
packet filter after the upcoming 6.5 release. Instead a switch to
using David Gwynne's new bpf filter will happen.
The benefits outweigh the drawbacks and the missing features will be
readily implemented in time for the 6.6 release.

--
:wq Claudio



Re: [PATCH] Update default QoS markers for ssh

2018-04-10 Thread Ian McWilliam
Just for the record the latest OpenBSD snapshot with the changed ssh / sshd 
causes ssh connections to fail

across a VMWare Fusion 10 NAT network.


ssh into the box you get a banner sent before the connection is closed.

ssh out of the like updating a CVS tree gets you...


Obtaining OpenBSD-current src tree.

packet_write_wait: Connection to 130.102.79.219 port 22: Broken pipe

cvs [update aborted]: end of file from server (consult above messages if any)

Finished obtaining OpenBSD-current src tree.


Adding


IPQoS lowdelay


to both the ssh_config / ssh_config make this work as before.


Machines on the Internal network can SSH into and out amongst each other but 
going across the NAT boundary to the real world fails.

With the state of VMWare (the company) I doubt there will be a fix for Fusion 
anytime soon.


Leaving this here for the archives.


Ian McWilliam



From: owner-t...@openbsd.org <owner-t...@openbsd.org> on behalf of Stuart 
Henderson <s...@spacehopper.org>
Sent: Monday, 2 April 2018 12:06 AM
To: Job Snijders
Cc: tech@openbsd.org
Subject: Re: [PATCH] Update default QoS markers for ssh

On 2018/04/01 13:29, Job Snijders wrote:
> On Sun, Apr 01, 2018 at 11:29:55AM +0100, Stuart Henderson wrote:
> > On 2018/03/31 16:10, Job Snijders wrote:
> > > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low
> > > Latency Data) for interactive session traffic, and CS1 ("Lower
> > > Effort") for non-interactive traffic. This applies to both IPv4 and
> > > IPv6.
> >
> > I think this is the right thing to do, but needs handling in
> > conjunction with changes to PF, which has dual queue-setting
> > (IPTOS_LOWDELAY packets go in one queue along with empty TCP ACKs,
> > other packets can go in another lower priority queue).
> >
> > Since firewalls are often updated less often than hosts I think it
> > would be better if the PF side was done first with some time to give
> > people chance to update, though it doesn't need to be too long (they
> > can set qos in sshd_config if they want to retain the old setting).
> >
> > A few other pieces use IPTOS_LOWDELAY (pfsync, carp, vxlan, etherip)
> > which I think would want switching too.
>
> What we're looking at is some kind of "migrate TOS to DSCP" project.
> There is a few tens of files where TOS values need to be examined and an
> appropiate DSCP value choosen.

Yes, that's clearly a much bigger scope. But if we're starting with ssh
those should be on the radar too IMO.

>I'm not sure I'd go as far as blindly
> replacing IPTOS_LOWDELAY with IPTOS_DSCP_AF21, but perhaps as a
> transition that is what is needed in some places.

Indeed. For some of these uses (like carp) something like CS7 seems
more appropriate. ssh seems a great place to start gaining more
experience with this - in particular any breakage can be handled
more easily than things like carp (since ssh already has config
options for this).

> We can start by treating IPTOS_LOWDELAY and IPTOS_DSCP_AF21 similarly in
> pf (see untested patch below), and then accept patches that migrate from
> TOS to DSCP?

That approach generally makes sense to me. It seems that some other
codepoints should probably also be treated as higher priority but
I'm not quite sure which yet...

> As far as I understand, out-of-the-box pf doesn't do anything with TOS
> values, so users wlil have to have explicitly configured something on
> the firewall or clients anyhow?

Yes, the firewall needs to have queues enabled and traffic assigned with
"set queue (foo, bar)" syntax.

> Kind regards,
>
> Job
>
>  share/man/man5/pf.conf.5 | 12 +---
>  sys/net/pf.c |  8 +---
>  2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git share/man/man5/pf.conf.5 share/man/man5/pf.conf.5
> index 13e23423daa..f5a65e1b0d4 100644
> --- share/man/man5/pf.conf.5
> +++ share/man/man5/pf.conf.5
> @@ -679,7 +679,9 @@ interface, the queueing priority will also be written as 
> the priority
>  code point in the 802.1Q VLAN header.
>  If two priorities are given, TCP ACKs with no data payload and packets
>  which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  will be assigned to the second one.
>  Packets with a higher priority number are processed first,
>  and packets with the same priority are processed
> @@ -702,7 +704,9 @@ section.
>  Packets matching this rule will be assigned to the specified
>  .Ar queue .
>  If two queues are given, packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  and TCP ACKs with no data payload will be assigned to the second one.

Re: tcpdump: drop atalk support

2017-05-30 Thread Ian McWilliam
EtherTalk (Appletalk over Ethernet) was removed in Mac OS X v10.6 in 2009.
You never know what might be flying across your network

Ian McWilliam

From: owner-t...@openbsd.org <owner-t...@openbsd.org> on behalf of Henning 
Brauer <hb-openbsdt...@ml.bsws.de>
Sent: Tuesday, 30 May 2017 7:59:40 PM
To: tech@openbsd.org
Subject: Re: tcpdump: drop atalk support

* Theo de Raadt <dera...@openbsd.org> [2017-05-30 10:56]:
> > How about just dropping support for /etc/appletalk.names, which as far
> > as I can tell was never used, and drop the manpage bit, reducing it by
> > 10%. Most of the text in the manpage is outdated anyway, talking about
> > /etc/atalk.names - support for which was removed in 2004 with the
> > privsep work. Something like this:
>
> Sure sure.
>
> My main objection to full removal was that you see a numbered packet
> flying over your network and don't know what catagory it is in.
> Suddenly google search is neccessary because tcpdump is going out
> of the way to not help.  So it should help, answering the minimum
> question of "what type is that packet, should I worry".

agreed.
can we limit this to just being able to identify appletalk?

note that this is ethertype appletalk, not appletalk over ip. afaik
that means pre-macosx.

--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/



ntpd && pledge

2016-07-06 Thread Ian Mcwilliam
Seems changes to pledge have made ntpd abort.

ntpd(67855): syscall 5 "rpath"
ntpd(81479): syscall 5 "rpath"

Jul  7 10:29:23 ianm-openbsd ntpd[76119]: constraint 2404:6800:4006:800::2004; 
terminated with signal 6 (Abort trap)

Ian McWilliam


Insufficient checks in IPv6 socket binding and UDP IPv6 option processing missing in OpenSBD_5_9 cvs tree

2016-03-19 Thread Ian Mcwilliam
http://ftp.openbsd.org/pub/OpenBSD/patches/5.9/common/002_in6bind.patch.sig

002: SECURITY FIX: March 16, 2016   All architectures
Insufficient checks in IPv6 socket binding and UDP IPv6 option processing allow 
a local user to send UDP packets with a source (IPv6 address + port) already 
reserved by another user. 

This hasn't been committed to OpenBSD_5_9. Maybe an oversight.

Ian McWilliam


Re: [calendar] United States holiday migrations

2016-01-27 Thread Ian Mcwilliam
Just for the record

 01/30   Australia Day in Australia

should be

 01/26   Australia Day in Australia

If someone so wishes to fix it.

Ian McWilliam


From: owner-t...@openbsd.org [owner-t...@openbsd.org] on behalf of Craig 
Skinner [skin...@britvault.co.uk]
Sent: Thursday, 28 January 2016 10:06 AM
To: tech@openbsd.org
Subject: [calendar] United States holiday migrations

Hi folks,

NOOP;- relocate USA state/national holidays from calendar.holiday
into existing sparse calendar.usholiday file.

As they're now in the USA holiday file, strip state names from holiday
names where the state is named in the day itself.

e.g: 'Oklahoma Day in Oklahoma' becomes 'Oklahoma Day'.
e.g: 'Youth Day in Oklahoma' remains unchanged.


Index: calendar.holiday
===
RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.holiday,v
retrieving revision 1.35
diff -u -p -r1.35 calendar.holiday
--- calendar.holiday20 Jan 2016 19:12:28 -  1.35
+++ calendar.holiday27 Jan 2016 22:52:23 -
@@ -27,16 +27,12 @@
 01/15  Arbor Day in Jordan
 01/16  Martyrs Day in Benin
 01/18  Revolution Day in Tunisia
-01/19  Confederate Heroes Day in Texas
 01/19  Ethopian Epiphany in Ethiopia
 01/19  Nameday of Archbishop Makarios in Cyprus
 01/20  Army Day in Mali
 01/20  National Heroes Day in Guinea-Bissau
-01/MonThirdRobert E. Lee's Birthday in Alabama & Mississippi (3rd Monday)
-01/MonThirdLee-Jackson Day in Virginia (3rd Monday)
 01/21  Our Lady of Altagracia in Dominican Republic
 01/23  Feast of St. Ildefonsus
-01/23  National Handwriting Day
 01/24  Economic Liberation Day in Togo
 01/26  Republic Day in India
 01/30  Australia Day in Australia
@@ -60,11 +56,9 @@
 03/01  Samil Independence Movement Day in South Korea
 03/01  St. David's Day, Cardiff
 03/02  Peasants Day in Burma
-03/02  Texas Independence day
 03/02  Victory of Adowa in Ethiopia
 03/03  Girl's Day in Japan
 03/03  Throne Day in Morocco
-03/04  Vermont Admission Day (admitted as 14th state in 1791)
 03/05  Independence Day in Equatorial Guinea
 03/06  Lantern Day, Bejing
 03/07* Purim - Feast of Lots
@@ -76,39 +70,31 @@
 03/09  Decoration Day in Liberia
 03/09  Falgun Purnima Day in Nepal
 03/10  Labor Day in South Korea
-03/11  Johnny Appleseed Day; anniversary of the death of John Chapman
 03/12  Commonwealth Day in Swaziland
 03/12  Independence Day in Mauritius
 03/12  Moshoeshoe's Birthday in Lesotho
 03/12  Renovation Day in Gabon
 03/13  National Day in Grenada
 03/15  Day of the 1848 revolution in Hungary
-03/16  Black Press Day; first Black newspaper founded in 1827
-03/17  Evacuation Day in Suffolk County, Massachusetts
 03/17  St. Patrick's Day
 03/19  St. Joseph's Day in Colombia, Costa Rica, Holy See, Liechtenstein,
Bavaria, San Marino, Spain, Venezuela
 03/19  Tree Planting Day in Lestho
 03/20  Independence Day in Tunsia
-03/20  Youth Day in Oklahoma
 03/21  Afghan New Year in Afghanistan
 03/21  Juarez' Birthday in Mexico
 03/22  Abolition Day in Puerto Rico
 03/23  Pakistan Day in Pakistan
 03/25  Greek Independence Day in Cyprus
 03/25  Lady Day (a.k.a. the Feast of the Annunciation)
-03/25  Maryland Day in Maryland
 03/25  National Holiday in Greece
-03/MonLast Seward's Day in Alaska (last Monday)
 03/26  Independence Day in Bangladesh
-03/26  Prince Jonah Kuhio Kalanianaole Day in Hawaii
 03/27  Armed Forces Day in Burma
 03/29  Death of President Barthelemy Boganda in Central African Republic
 03/29  Memorial Day in Madagascar
 03/31  National Day in Malta
 04/01  Youth Day in Benin
 04/02  Malvinas Day in Argentina
-04/02  Pascua Florida Day in Florida
 04/04  Ching Ming Festival in Hong Kong
 04/04  Liberation Day in Hungary
 04/04  National Day in Senegal
@@ -123,7 +109,6 @@
 04/13  Songkran Day in Thailand
 04/14  Day of the Americas in Honduras
 04/15  Bengali New Year in Bangladesh
-04/MonThirdPatriot's Day in Maine & Massachusetts (3rd Monday)
 04/16  De Diego's Birthday (celebrated in Puerto Rico)
 04/16  Holy Week (5 days) in Venezuela
 04/16  Tourist Week (5 days) in Uruguay
@@ -131,39 +116,28 @@
 04/18  Independence Day in Chile, Zimbabwe
 04/19  Declaration of Independence in Venezuela
 04/19  Republic Day in Sierra Leone
-04/21  San Jacinto Day in Texas
-04/22  Arbor Day in Nebraska & Delaware
-04/22  Oklahoma Day in Oklahoma
 04/24  Victory Day in Togo
 04/24* Pesach - First Day of Passover - Festival of Freedom
 04/25* ANZAC Day in Australia, New Zealand, and various other influenced places
 04/25  Liberation Day in Italy
 04/25  National Flag Day in Swaziland
-04/26  Confederate Memorial Day in Florida & Georgia
 04/26  Union Day in Tanzania
 04/27  Day of Uprising Against Occupation in Slovenia
 04/27  Independence Day in Togo
-04/MonLast Arbor Day in Wyoming (last Monday)
-04/MonLast Confederate Memorial Day in Alabama & Mississippi (last Monday)
 04/30  The Worker

Re: ntpd setting date incorrectly

2015-12-16 Thread Ian Mcwilliam
Patch works.

hw.sensors.vmt0.timedelta0=0.000109 secs, OK, Thu Dec 17 09:29:31.932


Dec 17 09:29:19 ianm-openbsd ntpd[882]: ntp engine ready
Dec 17 09:29:20 ianm-openbsd ntpd[5528]: set local clock to Thu Dec 17 09:29:20 
AEDT 2015 (offset 0.937695s)
Dec 17 09:29:20 ianm-openbsd savecore: no core dump
Dec 17 09:29:21 ianm-openbsd apmd: battery status: absent. external power 
status: connected. estimated battery life 0%
Dec 17 09:29:22 ianm-openbsd ntpd[882]: constraint reply from 216.58.220.132: 
offset -0.635569
Dec 17 09:29:42 ianm-openbsd ntpd[882]: peer 129.250.35.251 now valid
Dec 17 09:29:43 ianm-openbsd ntpd[882]: peer 121.0.0.42 now valid
Dec 17 09:29:43 ianm-openbsd ntpd[882]: peer 121.0.0.41 now valid
Dec 17 09:29:48 ianm-openbsd ntpd[882]: peer 202.127.210.36 now valid
Dec 17 09:30:47 ianm-openbsd ntpd[12574]: adjusting local clock by 0.054113s

I'll keep an eye out for any further issues.

Thanks.

Ian McWilliam


From: Martin Pieuchot [m...@openbsd.org]
Sent: Thursday, 17 December 2015 1:31 AM
To: Mike Belopuhov
Cc: Ian Mcwilliam; tech@openbsd.org
Subject: Re: ntpd setting date incorrectly

On 16/12/15(Wed) 14:56, Mike Belopuhov wrote:
> On Wed, Dec 16, 2015 at 03:53 +0000, Ian Mcwilliam wrote:
> >
> > Disable sensors * in ntpd.conf and time is good again.
> >
> > I see this on boot up when things go strange.
> >
> > hw.sensors.vmt0.timedelta0=1450237689.498077 secs, OK, Tue Nov 29 
> > 18:36:38.371
> >
> > I wonder if it's related to this change? Thoughts?
> >
>
> Bah, I've noticed that, but forgot to mention this to mpi@.
> Martin, what has prompted you to change the behaviour here?
> It's the only spot in that commit that has changed the
> mountroot to a startup hook.

Because this driver is using the same function for a hook and a timer,
both taking (void *) pointer.

I don't understand for which reason this driver is using a hook, but
tell me if this works.

Index: dev/pv/vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.6
diff -u -p -r1.6 vmt.c
--- dev/pv/vmt.c11 Dec 2015 16:07:01 -  1.6
+++ dev/pv/vmt.c16 Dec 2015 14:29:54 -
@@ -208,6 +208,7 @@ void vmt_shutdown(void *);
 voidvmt_update_guest_info(struct vmt_softc *);
 voidvmt_update_guest_uptime(struct vmt_softc *);

+voidvmt_tick_hook(struct device *self);
 voidvmt_tick(void *);
 voidvmt_resume(void);

@@ -364,9 +365,7 @@ vmt_attach(struct device *parent, struct
sensor_attach(>sc_sensordev, >sc_sensor);
sensordev_install(>sc_sensordev);

-   timeout_set(>sc_tick, vmt_tick, sc);
-   if (startuphook_establish(vmt_tick, sc) == NULL)
-   DPRINTF("%s: unable to establish tick\n", DEVNAME(sc));
+   config_mountroot(self, vmt_tick_hook);

timeout_set(>sc_tclo_tick, vmt_tclo_tick, sc);
timeout_add_sec(>sc_tclo_tick, 1);
@@ -467,6 +466,15 @@ vmt_update_guest_info(struct vmt_softc *

sc->sc_set_guest_os = 1;
}
+}
+
+void
+vmt_tick_hook(struct device *self)
+{
+   struct vmt_softc *sc = (struct vmt_softc *)self;
+
+   timeout_set(>sc_tick, vmt_tick, sc);
+   vmt_tick(sc);
 }

 void


Re: ntpd setting date incorrectly

2015-12-15 Thread Ian Mcwilliam

Disable sensors * in ntpd.conf and time is good again.

I see this on boot up when things go strange.

hw.sensors.vmt0.timedelta0=1450237689.498077 secs, OK, Tue Nov 29 18:36:38.371

I wonder if it's related to this change? Thoughts?

===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- src/sys/dev/pv/vmt.c2015/08/27 19:51:36 1.5
+++ src/sys/dev/pv/vmt.c2015/12/11 16:07:01 1.6
@@ -1,4 +1,4 @@
-/* $OpenBSD: vmt.c,v 1.5 2015/08/27 19:51:36 deraadt Exp $ */
+/* $OpenBSD: vmt.c,v 1.6 2015/12/11 16:07:01 mpi Exp $ */
 
 /*
  * Copyright (c) 2007 David Crawshaw <da...@zentus.com>
@@ -365,7 +365,7 @@
sensordev_install(>sc_sensordev);
 
timeout_set(>sc_tick, vmt_tick, sc);
-   if (mountroothook_establish(vmt_tick, sc) == NULL)
+   if (startuphook_establish(vmt_tick, sc) == NULL)
DPRINTF("%s: unable to establish tick\n", DEVNAME(sc));
 
timeout_set(>sc_tclo_tick, vmt_tclo_tick, sc);


Ian McWilliam

________
From: Ian Mcwilliam
Sent: Tuesday, 15 December 2015 12:04 PM
To: tech@openbsd.org
Subject: ntpd setting date incorrectly

Not sure what has changed in the last couple of days but apparently I need to 
get back from the future.

This is an OpenBSD VM running under VMWare Fusion Professional Version 8.0.2 
(3164312) Mac OS X 10.11.2


Dec 14 17:22:44 ianm-openbsd ntpd[13773]: peer 121.0.0.41 now valid
Dec 14 17:22:46 ianm-openbsd ntpd[13773]: peer 192.189.54.17 now valid
Dec 14 17:22:49 ianm-openbsd ntpd[13773]: peer 54.252.165.245 now valid
Dec 14 17:22:49 ianm-openbsd ntpd[13773]: peer 54.252.129.186 now valid
Dec 14 17:23:44 ianm-openbsd ntpd[19417]: adjusting local clock by 45.252476s

Machine shutdown

Machine rebooted next day

Dec 15 09:26:00 ianm-openbsd ntpd[1991]: ntp engine ready

time correct until

Nov 27 07:52:36 ianm-openbsd ntpd[21778]: set local clock to Sun Nov 27 
07:52:36 AEDT 2061 (offset 1450131996.187864s)
Nov 27 07:52:36 ianm-openbsd savecore: no core dump
Nov 27 07:52:37 ianm-openbsd apmd: battery status: absent. external power 
status: connected. estimated battery life 0%
Nov 27 07:53:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131950.806132s
Nov 27 07:55:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131950.410569s
Nov 27 07:56:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131949.960758s
Nov 27 07:58:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131949.511029s
Nov 27 07:59:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131949.061268s
Nov 27 08:01:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131948.611426s
Nov 27 08:02:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131948.161660s
Nov 27 08:04:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131947.711849s
Nov 27 08:05:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131947.262024s
Nov 27 08:07:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131946.812191s
Nov 27 08:07:32 ianm-openbsd dhclient[21622]: DHCPDISCOVER on em0 - interval 1
Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPDISCOVER on em0 - interval 1
Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPOFFER from 172.16.28.254 
(00:50:56:f1:c4:f7)
Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPREQUEST on em0 to 
255.255.255.255
Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPACK from 172.16.28.254 
(00:50:56:f1:c4:f7)
Nov 27 08:07:33 ianm-openbsd dhclient[21622]: bound to 172.16.28.141 -- renewal 
in 900 seconds.
Nov 27 08:08:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131946.362273s

manually setting the date/time shows that things appear fine until next reboot.

Nov 27 08:57:27 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131932.766352s
Nov 27 08:58:57 ianm-openbsd ntpd[11805]: adjusting local clock by 
-1450131932.316650s
Dec 15 10:34:21 ianm-openbsd ntpd[11805]: adjusting local clock by 33.548572s
Dec 15 10:34:21 ianm-openbsd ntpd[1991]: clock is now synced
Dec 15 10:35:52 ianm-openbsd ntpd[11805]: adjusting local clock by 33.107247s
Dec 15 10:35:52 ianm-openbsd ntpd[1991]: clock is now unsynced
Dec 15 10:37:21 ianm-openbsd ntpd[11805]: adjusting local clock by 32.662256s
Dec 15 10:38:51 ianm-openbsd ntpd[11805]: adjusting local clock by 32.212314s
Dec 15 10:40:21 ianm-openbsd ntpd[11805]: adjusting local clock by 31.762446s
Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.17: 
offset 30.905949
Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.20: 
offset 30.905572
Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.19: 
offset 30.903128
Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.18: 
offset 30.900721
Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint

ntpd setting date incorrectly

2015-12-14 Thread Ian Mcwilliam
IE" rev 0x01
pci18 at ppb17 bus 18
ppb18 at pci0 dev 23 function 0 "VMware PCIE" rev 0x01
pci19 at ppb18 bus 19
ppb19 at pci0 dev 23 function 1 "VMware PCIE" rev 0x01
pci20 at ppb19 bus 20
ppb20 at pci0 dev 23 function 2 "VMware PCIE" rev 0x01
pci21 at ppb20 bus 21
ppb21 at pci0 dev 23 function 3 "VMware PCIE" rev 0x01
pci22 at ppb21 bus 22
ppb22 at pci0 dev 23 function 4 "VMware PCIE" rev 0x01
pci23 at ppb22 bus 23
ppb23 at pci0 dev 23 function 5 "VMware PCIE" rev 0x01
pci24 at ppb23 bus 24
ppb24 at pci0 dev 23 function 6 "VMware PCIE" rev 0x01
pci25 at ppb24 bus 25
ppb25 at pci0 dev 23 function 7 "VMware PCIE" rev 0x01
pci26 at ppb25 bus 26
ppb26 at pci0 dev 24 function 0 "VMware PCIE" rev 0x01
pci27 at ppb26 bus 27
ppb27 at pci0 dev 24 function 1 "VMware PCIE" rev 0x01
pci28 at ppb27 bus 28
ppb28 at pci0 dev 24 function 2 "VMware PCIE" rev 0x01
pci29 at ppb28 bus 29
ppb29 at pci0 dev 24 function 3 "VMware PCIE" rev 0x01
pci30 at ppb29 bus 30
ppb30 at pci0 dev 24 function 4 "VMware PCIE" rev 0x01
pci31 at ppb30 bus 31
ppb31 at pci0 dev 24 function 5 "VMware PCIE" rev 0x01
pci32 at ppb31 bus 32
ppb32 at pci0 dev 24 function 6 "VMware PCIE" rev 0x01
pci33 at ppb32 bus 33
ppb33 at pci0 dev 24 function 7 "VMware PCIE" rev 0x01
pci34 at ppb33 bus 34
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
uhidev0 at uhub1 port 1 configuration 1 interface 0 "VMware VMware Virtual USB 
Mouse" rev 1.10/1.02 addr 2
uhidev0: iclass 3/0
ums0 at uhidev0: 16 buttons, Z and W dir
wsmouse1 at ums0 mux 0
uhidev1 at uhub1 port 1 configuration 1 interface 1 "VMware VMware Virtual USB 
Mouse" rev 1.10/1.02 addr 2
uhidev1: iclass 3/0
ums1 at uhidev1: 16 buttons, Z and W dir
wsmouse2 at ums1 mux 0
uhub2 at uhub1 port 2 "VMware VMware Virtual USB Hub" rev 1.10/1.00 addr 3
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (66043ec868a376cc.a) swap on sd0b dump on sd0b


Ian McWilliam


Re: Pledge shutdown halt

2015-11-18 Thread Ian McWilliam

On 18/11/2015 5:31 PM, Theo de Raadt wrote:

What ttys are you guys rebooting from.  Is it seen on console?  Or... is it
only seen from xterm...?


ssh session. I'll have to check the console tomorrow. No X configured to 
run on the box.


Ian McWilliam



Re: Pledge shutdown halt

2015-11-18 Thread Ian McWilliam
 

- Original Message -
From: "Ian McWilliam" 
To:"Theo de Raadt" , 
Cc:
Sent:Wed, 18 Nov 2015 20:09:58 +1100
Subject:Re: Pledge shutdown halt

 On 18/11/2015 5:31 PM, Theo de Raadt wrote:
 > What ttys are you guys rebooting from. Is it seen on console? Or...
is it
 > only seen from xterm...?
 >
 >
 ssh session. I'll have to check the console tomorrow. No X configured
to 
 run on the box.

 Ian McWilliam

Rebuilt kernel + userland from todays sources.

OpenBSD 5.8-current (GENERIC.MP) #0: Thu Nov 19 10:32:02 AEDT 2015

 
  r...@ianm-openbsd.xxx.edu.au:/usr/src/sys/arch/amd64/compile/GENERIC.MP
The message is no longer displayed on reboot / shutdown on ssh session
or console.
Ian McWilliam


Pledge shutdown halt

2015-11-17 Thread Ian McWilliam

Anybody see this on shutdown? 

shutdown -hp now

*** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au

 ***                                         
                                 

System going down IMMEDIATELY 

System shutdown time has arrived 

halt: revoke: Inappropriate ioctl for device

Kernel and userland built today

OpenBSD 5.8-current (GENERIC.MP) #0: Wed Nov 18 14:15:33 AEDT 2015

 
  r...@ianm-openbsd.xxx.edu.au:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Machine still shuts down and powers off.

Ian McWilliam


pledge csh nice = death

2015-10-18 Thread Ian McWilliam


Oct 19 11:55:52 ianm-openbsd /bsd: csh(29463): syscall 96 

Oct 19 11:55:52 ianm-openbsd /bsd: csh(6081): syscall 96 

Oct 19 11:55:52 ianm-openbsd /bsd: csh(18068): syscall 96 

Oct 19 11:57:14 ianm-openbsd /bsd: csh(31019): syscall 96 

Oct 19 11:57:14 ianm-openbsd /bsd: csh(20634): syscall 96 

Oct 19 11:57:14 ianm-openbsd /bsd: csh(6171): syscall 96

96 STD { int sys_setpriority(int which, id_t who, int prio); }

Some of my csh scripts set 'nice' priorities on some things they do.

Ian McWilliam


Re: Unlock the reaper

2015-07-09 Thread Ian McWilliam

On 9/07/2015 7:20 AM, Stuart Henderson wrote:

On 2015/07/08 20:00, Max Fillinger wrote:

On Wed, Jul 08, 2015 at 03:53:46PM +0200, Mark Kettenis wrote:

I'm looking for testers for this diff.  This should be safe to run on
amd64, i386 and sparc64.  But has been reported to lock up i386
machines.  I can't reproduce this on any of my own systems.  So I'm
looking for help.  I'm looking for people that are able to build a
kernel with this diff and the MP_LOCKDEBUG option enabled
(uncommented) in their GENERIC.MP kernel, run it on an MP machine and
put some load on it to see if it locks up and/or panics.

Being able to move forward with this would make OpenBSD run
significantly better on MP systems.

Thanks,

Mark

I just finished compiling the kernel for amd64; I might test i386 later.
What kind of load would be required to give useful feedback? Would
building the userland or some of the bigger ports be a useful test?

Building base with the reaper unlock diff on i386 doesn't seem to
trigger problems, or at least I haven't run into them in a few attempts.

I do see problems when building ports on a dpb cluster, quite quickly
in some cases - I just did a run and one node locked after 261s, another
after 756s (dpb master stayed up FWIW).

If you're trying to reproduce, make sure you set ddb.console=1 and
check that you can break into ddb under normal conditions. If you
manage to trigger a hang, see if you can break into ddb and get
the usual things (backtrace, ps, sh reg, etc).

I've been unable to get into ddb after a hang, including on this
most recent run with MP_LOCKDEBUG.

Nothing particular special was being built during the last hang;
from dpb term-report, the last entry before i386-2- appeared
(indicating that the host is no longer contactable) showed these

archivers/libzip
audio/libogg
archivers/lzo2

Looking at build logs (which are streamed over ssh and logged
on the dpb master) lzo2 and libzip were compiling (cc from base)
and libogg was doing pkg_create/gzip when contact was lost.
So I don't think it's going to be triggered by any particular
ports, there is nothing out of the ordinary about these, and
no funny autoconf checks were occurring at the time.

The main other build-related active process would be sshd,
and since pkg_create was running it would also most likely
have been writing to nfs at the time.



My money is on - nfs.

Ian McWilliam



Re: samba4 slow startup, shared libs?

2015-06-22 Thread Ian Mcwilliam

For reference: https://bugzilla.samba.org/show_bug.cgi?id=11355



Ian McWilliam


From: Ian Mcwilliam
Sent: Friday, 19 June 2015 10:03 AM
To: Jérémie Courrèges-Anglas
Cc: Stuart Henderson; Mark Kettenis; tech@openbsd.org
Subject: RE: samba4 slow startup, shared libs?

Sweet. I'll knockup a patch and send it upstream shortly.


Ian McWilliam


From: Jérémie Courrèges-Anglas [j...@wxcvbn.org]
Sent: Thursday, 18 June 2015 8:11 PM
To: Ian Mcwilliam
Cc: Stuart Henderson; Mark Kettenis; tech@openbsd.org
Subject: Re: samba4 slow startup, shared libs?

Ian Mcwilliam i.mcwill...@uws.edu.au writes:

 Curiously from

 --- samba-4.0.3/wscript   Tue Dec  4 21:07:44 2012
 +++ samba-4.0.26/wscript  Mon Dec  8 18:46:38 2014


 -if sys.platform != openbsd4:
 +if not sys.platform.startswith(openbsd):
  conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed', 
 testflags=True)

Here's the output of LD_DEBUG=1 time samba-tool:

ritchie /usr/ports/net/samba4$ tail before after
== before ==
doing dtors obj 0x76bdc238000 @0x76c004b0a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0x76bb7b3b000 @0x76bfbc6e740: 
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0x76bb7b3b800 @0x76b8c3331b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0x76c1ede3400 @0x76bbadbc950: [/usr/lib/libc.so.79.0]
doing dtors obj 0x76c1ede3000 @0x76c333c5a40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0x76bdc238800 @0x76c0159b340: [/usr/lib/libm.so.9.0]
  251.92 real   251.96 user 0.19 sys
doing dtors
 doing dtors obj 0xf0ae0f94c00 @0xf0b5ec96950: [/usr/lib/libc.so.79.0]

== after ==
doing dtors obj 0xa6021425000 @0xa60bf833a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0xa6021425800 @0xa603fca0740: 
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0xa6034d7e800 @0xa60c0c911b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0xa60a5bcf400 @0xa604a3e0950: [/usr/lib/libc.so.79.0]
doing dtors obj 0xa60a5bcf000 @0xa60eb3eba40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0xa6021425400 @0xa610ba86340: [/usr/lib/libm.so.9.0]
1.49 real 1.24 user 0.22 sys
doing dtors
doing dtors obj 0x4e7a8e11c00 @0x4e767f81950: [/usr/lib/libc.so.79.0]

(with wip samba-4.1.18)

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: samba4 slow startup, shared libs?

2015-06-18 Thread Ian Mcwilliam
Sweet. I'll knockup a patch and send it upstream shortly.


Ian McWilliam


From: Jérémie Courrèges-Anglas [j...@wxcvbn.org]
Sent: Thursday, 18 June 2015 8:11 PM
To: Ian Mcwilliam
Cc: Stuart Henderson; Mark Kettenis; tech@openbsd.org
Subject: Re: samba4 slow startup, shared libs?

Ian Mcwilliam i.mcwill...@uws.edu.au writes:

 Curiously from

 --- samba-4.0.3/wscript   Tue Dec  4 21:07:44 2012
 +++ samba-4.0.26/wscript  Mon Dec  8 18:46:38 2014


 -if sys.platform != openbsd4:
 +if not sys.platform.startswith(openbsd):
  conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed', 
 testflags=True)

Here's the output of LD_DEBUG=1 time samba-tool:

ritchie /usr/ports/net/samba4$ tail before after
== before ==
doing dtors obj 0x76bdc238000 @0x76c004b0a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0x76bb7b3b000 @0x76bfbc6e740: 
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0x76bb7b3b800 @0x76b8c3331b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0x76c1ede3400 @0x76bbadbc950: [/usr/lib/libc.so.79.0]
doing dtors obj 0x76c1ede3000 @0x76c333c5a40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0x76bdc238800 @0x76c0159b340: [/usr/lib/libm.so.9.0]
  251.92 real   251.96 user 0.19 sys
doing dtors
 doing dtors obj 0xf0ae0f94c00 @0xf0b5ec96950: [/usr/lib/libc.so.79.0]

== after ==
doing dtors obj 0xa6021425000 @0xa60bf833a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0xa6021425800 @0xa603fca0740: 
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0xa6034d7e800 @0xa60c0c911b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0xa60a5bcf400 @0xa604a3e0950: [/usr/lib/libc.so.79.0]
doing dtors obj 0xa60a5bcf000 @0xa60eb3eba40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0xa6021425400 @0xa610ba86340: [/usr/lib/libm.so.9.0]
1.49 real 1.24 user 0.22 sys
doing dtors
doing dtors obj 0x4e7a8e11c00 @0x4e767f81950: [/usr/lib/libc.so.79.0]

(with wip samba-4.1.18)

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: samba4 slow startup, shared libs?

2015-06-11 Thread Ian Mcwilliam
Curiously from

--- samba-4.0.3/wscript Tue Dec  4 21:07:44 2012
+++ samba-4.0.26/wscriptMon Dec  8 18:46:38 2014


-if sys.platform != openbsd4:
+if not sys.platform.startswith(openbsd):
 conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed', 
testflags=True)



--- samba-4.0.3/buildtools/wafadmin/Tools/config_c.py   Tue Oct  2 18:24:39 2012
+++ samba-4.0.26/buildtools/wafadmin/Tools/config_c.py  Wed May 28 03:20:37 2014
@@ -73,6 +73,19 @@
app('CCFLAGS_' + uselib, x)
app('CXXFLAGS_' + uselib, x)
app('LINKFLAGS_' + uselib, x)
+   #
+   # NOTE on special treatment of -Wl,-R and -Wl,-rpath:
+   #
+   # It is important to not put a library provided RPATH
+   # into the LINKFLAGS but in the RPATH instead, since
+   # the provided LINKFLAGS get prepended to our own internal
+   # RPATH later, and hence can potentially lead to linking
+   # in too old versions of our internal libs.
+   #
+   elif x.startswith('-Wl,-R'):
+   app('RPATH_' + uselib, x[6:])
+   elif x.startswith('-Wl,-rpath,'):
+   app('RPATH_' + uselib, x[11:])
elif x.startswith('-Wl'):
app('LINKFLAGS_' + uselib, x)
elif x.startswith('-m') or x.startswith('-f'):


There is also a bunch of PIE related changes too, I'll post if people think 
they may be relevant.



Ian McWilliam


From: owner-t...@openbsd.org [owner-t...@openbsd.org] on behalf of Stuart 
Henderson [st...@openbsd.org]
Sent: Wednesday, 10 June 2015 9:48 PM
To: Mark Kettenis
Cc: tech@openbsd.org
Subject: Re: samba4 slow startup, shared libs?

On 2015/06/05 13:27, Mark Kettenis wrote:
  Date: Fri, 5 Jun 2015 11:15:38 +0100
  From: Stuart Henderson st...@openbsd.org
 
  net/samba4 is in the ports tree but not currently enabled in the build,
  we're still only using samba 3.x for various reasons, but unfortunately
  samba 3 is getting decreasingly useful as more Windows setups move to
  newer versions.
 
  One of the issues is that startup of samba4 on OpenBSD is very slow
  indeed, seemingly before control is transferred to the program. From
  the LD_DEBUG output with timestamps (using the very handy ts(1) from
  moreutils):
 
  # LD_DEBUG=1 smbd -D 21 | ts %.s
  ..snip..
  1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1'
  1433498513.546323 loading: libnettle.so.1.2 required by 
  /usr/local/lib/libhogweed.so.1.1
  1433498513.546339 loading: libgmp.so.9.0 required by 
  /usr/local/lib/libhogweed.so.1.1
  1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of 
  /usr/local/lib/libhogweed.so.1.1
  1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of 
  /usr/local/lib/libhogweed.so.1.1
  1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0'
  1433498584.125659  flags /usr/libexec/ld.so = 0x0
  1433498584.125783 obj /usr/libexec/ld.so has smbd as head
  1433498584.149165 relocation took 0.023504
  1433498584.149215   StartEnd  Type Open Ref 
  GrpRef Name
  1433498584.149249   04bec650 04bec691 exe  10   0   
 smbd
  1433498584.149272   04c19b74e000 04c19bb6 rlib 0107   0 
   /usr/lib/libpthread.so.19.0
  1433498584.149293   04c18f3df000 04c18f812000 rlib 075   0  
  /usr/local/lib/libsamba-util.so.0.0
  ..snip..
 
  - a 74 second delay after examining: '/usr/local/lib/libgmp.so.9.0'.
  Does anyone have suggestions for finding out what's going on here?
  Full text snipped from the above is at 
  http://junkpile.org/samba4-lddebug.txt

 My first guess would have been that it is spending a lot of time on
 initial relocations.  But the line:

   1433498584.149165 relocation took 0.023504

 pretty much rules that out.  My suggestion would be to add a few more
 DL_DEB() statements inside of ld.so/loader.c:_dl_boot(), starting just
 after the _dl_load_dep_libs() call in that function and try to narrow
 it down.


The part taking the biggest chunk of time is _dl_cache_grpsym_list()
with its recursive calls (64 seconds).

1433936487.139917 _dl_cache_grpsym_list:
1433936551.414114 _dl_cache_grpsym_list:done

ctors for libpthread are fairly slow too (35 seconds) but I think
that's out of ld.so's hands.

...
1433936551.538493 _dl_debug_state done
1433936551.538508 doing ctors obj 0x138a43269400 @0x138a74fe0ca0: 
[/usr/lib/libpthread.so.19.0]
1433936587.157910 doing ctors obj 0x138ae5e30800 @0x138af0447f80: 
[/usr/local/lib/samba/libreplace.so.0.0]
...




Re: Byte range implementation for httpd(8)

2015-05-03 Thread Ian Mcwilliam
This might be what your thinking of.

https://httpd.apache.org/security/CVE-2011-3192.txt

Description:


A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server prior to version
2.2.20:

 http://seclists.org/fulldisclosure/2011/Aug/175

An attack tool is circulating in the wild. Active use of this tool has
been observed.

The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.



Ian McWilliam


From: owner-t...@openbsd.org [owner-t...@openbsd.org] on behalf of Florian 
Obser [flor...@openbsd.org]
Sent: Monday, 4 May 2015 4:34 AM
To: tech@openbsd.org
Cc: Sunil Nimmagadda
Subject: Re: Byte range implementation for httpd(8)

On Sun, May 03, 2015 at 08:14:25PM +0200, Sebastian Benoit wrote:
 one question though: whats the reasoning behind MAX_RANGES 4? nginx seems to
 have a default of unlimited (which i think questionable), but what is

Wasn't there a cve about this last year or so? You can try to burn cpu
and io on the server by requesting stupid ranges, like one byte at a
time, backwards for the whole file or something...

 reasonably seen on the internet?

my best guess is one range, from some byte position to the end, when
you resume a transfer.

--
I'm not entirely sure you are real.



X dist set needs an update........

2014-07-22 Thread Ian Mcwilliam
XETCLIST=`mktemp /tmp/_xetcsum.XX` || exit 1;  sort 
distrib/sets/lists/xetc/{mi,md.amd64}  ${XETCLIST};  cd /usr/xf4-dest   
xargs sha256 -h /usr/xf4-dest/usr/share/sysmerge/xetcsum  ${XETCLIST} || true; 
 rm -f ${XETCLIST}
cd distrib/sets   env MACHINE=amd64 ksh ./maketars 56 5.6   { env 
MACHINE=amd64 ksh ./checkflist 5.6 || true ; }
xbase: pax: Unable to access ./usr/X11R6/lib/libpixman-1.so.32.4: No such file 
or directory
done.
xetc: done.
xserv: done.
xshare: done.
xfont: done.
done.
958a959
 ./usr/X11R6/include/intel_aub.h
5877c5878
 ./usr/X11R6/lib/libpixman-1.so.32.4
---
 ./usr/X11R6/lib/libpixman-1.so.32.6
cd /usr/release;  cksum -a sha256 x*tgz  SHA256



Ian McWilliam



libssl/src/crypto/x86_64cpuid.pl Vallhalla breakage

2014-04-23 Thread Ian Mcwilliam
(cd /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/ ;  /usr/bin/perl 
./x86_64cpuid.pl)  x86_64cpuid.S
syntax error at ./x86_64cpuid.pl line 198, near print
Execution of ./x86_64cpuid.pl aborted due to compilation errors.
*** Error 255 in lib/libcrypto/crypto (arch/amd64/Makefile.inc:54 
'x86_64cpuid.S')
*** Error 1 in lib/libcrypto (bsd.subdir.mk:48 'realdepend')
*** Error 1 in lib (bsd.subdir.mk:48 'depend')
*** Error 1 in /usr/src (Makefile:78 'build')


Ian McWilliam



Index: x86_64cpuid.pl
===
RCS file: /cvs/src/lib/libssl/src/crypto/x86_64cpuid.pl,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 x86_64cpuid.pl
--- x86_64cpuid.pl      23 Apr 2014 21:53:18 -      1.9
+++ x86_64cpuid.pl      24 Apr 2014 00:18:57 -
@@ -161,7 +161,7 @@ OPENSSL_ia32_cpuid:
 .size  OPENSSL_ia32_cpuid,.-OPENSSL_ia32_cpuid
 ___
 
-print___ 
+print___;
 .globl OPENSSL_wipe_cpu
 .type  OPENSSL_wipe_cpu,\@abi-omnipotent
 .align 16



Re: sbin/iked fallout after OpenSSL valahalla slashing

2014-04-16 Thread Ian McWilliam
 

Sorry, it's a poor choice of MS outlook or Web email client here at
work.

/usr/src/usr.bin/gzsig suffers similar fallout it looks a little bit
tricker to fix.

cc -O2 -pipe    -c /usr/src/usr.bin/gzsig/ssh.c

/usr/src/usr.bin/gzsig/ssh.c:59: error: expected
specifier-qualifier-list before 'des_key_schedule'

/usr/src/usr.bin/gzsig/ssh.c: In function 'des3_init':

/usr/src/usr.bin/gzsig/ssh.c:156: error: 'struct des3_state' has no
member named 'k1'

/usr/src/usr.bin/gzsig/ssh.c:157: error: 'struct des3_state' has no
member named 'k2'

/usr/src/usr.bin/gzsig/ssh.c:160: error: 'struct des3_state' has no
member named 'k3'

/usr/src/usr.bin/gzsig/ssh.c:162: error: 'struct des3_state' has no
member named 'k3'

/usr/src/usr.bin/gzsig/ssh.c:164: error: 'struct des3_state' has no
member named 'iv1'

/usr/src/usr.bin/gzsig/ssh.c:165: error: 'struct des3_state' has no
member named 'iv2'

/usr/src/usr.bin/gzsig/ssh.c:166: error: 'struct des3_state' has no
member named 'iv3'

/usr/src/usr.bin/gzsig/ssh.c: In function 'des3_decrypt':

/usr/src/usr.bin/gzsig/ssh.c:177: error: 'struct des3_state' has no
member named 'iv1'

/usr/src/usr.bin/gzsig/ssh.c:177: error: 'struct des3_state' has no
member named 'iv2'

/usr/src/usr.bin/gzsig/ssh.c:179: error: 'struct des3_state' has no
member named 'k3'

/usr/src/usr.bin/gzsig/ssh.c:179: error: 'struct des3_state' has no
member named 'iv3'

/usr/src/usr.bin/gzsig/ssh.c:180: error: 'struct des3_state' has no
member named 'k2'

/usr/src/usr.bin/gzsig/ssh.c:180: error: 'struct des3_state' has no
member named 'iv2'

/usr/src/usr.bin/gzsig/ssh.c:181: error: 'struct des3_state' has no
member named 'k1'

/usr/src/usr.bin/gzsig/ssh.c:181: error: 'struct des3_state' has no
member named 'iv1'

*** Error 1 in /usr/src/usr.bin/gzsig (:87 'ssh.o')

I can get it down to this

ssh.o(.text+0x5ab): In function `ssh_load_private':

: undefined reference to `des_set_key'

ssh.o(.text+0x675): In function `ssh_load_private':

: undefined reference to `des_set_key'

ssh.o(.text+0x745): In function `ssh_load_private':

: undefined reference to `des_set_key'

ssh.o(.text+0x85c): In function `ssh_load_private':

: undefined reference to `des_ncbc_encrypt'

ssh.o(.text+0x938): In function `ssh_load_private':

: undefined reference to `des_ncbc_encrypt'

ssh.o(.text+0x9db): In function `ssh_load_private':

: undefined reference to `des_ncbc_encrypt'

collect2: ld returned 1 exit status
going a bit further gets me here

cc -O2 -pipe    -c /usr/src/usr.bin/gzsig/ssh.c 

/usr/src/usr.bin/gzsig/ssh.c: In function 'des3_decrypt': 

/usr/src/usr.bin/gzsig/ssh.c:179: error: incompatible type for
argument 4 of 'DES_ncbc_encrypt' 

/usr/src/usr.bin/gzsig/ssh.c:180: error: incompatible type for
argument 4 of 'DES_ncbc_encrypt' 

/usr/src/usr.bin/gzsig/ssh.c:181: error: incompatible type for
argument 4 of 'DES_ncbc_encrypt' 

*** Error 1 in /usr/src/usr.bin/gzsig (:87 'ssh.o')

I'll leave this one for you guys.

Ian McWilliam

- Original Message -
From: Bob Beck 
To:Ian McWilliam 
Cc:
Sent:Wed, 16 Apr 2014 00:10:42 -0600
Subject:Re: sbin/iked fallout after OpenSSL valahalla slashing

 not quite, because your diff was mangled, but I think
 you had it right anyway.. fix committed by miod, thanks for
 telling us. 

 On Wed, Apr 16, 2014 at 03:39:03PM +1000, Ian McWilliam wrote:
  Hoope the attached diff is a correct fix. Hit me with the cluebat
if
  not.
  
  cc -O2 -pipe ??-Wall -I/usr/src/sbin/iked -Wstrict-prototypes
  -Wmissing-prototypes -Wmissing-declarations -Wshadow
-Wpointer-arith
  -Wcast-qual -Wsign-compare -fno-pie ?? -c
  /usr/src/sbin/iked/chap_ms.c/usr/src/sbin/iked/chap_ms.c: In
function
  'mschap_des_addparity':/usr/src/sbin/iked/chap_ms.c:104: error:
  'des_cblock' undeclared (first use in this
  function)/usr/src/sbin/iked/chap_ms.c:104: error: (Each undeclared
  identifier is reported only once/usr/src/sbin/iked/chap_ms.c:104:
  error: for each function it appears
  in.)/usr/src/sbin/iked/chap_ms.c:104: error: expected expression
  before ')' token/usr/src/sbin/iked/chap_ms.c: In function
  'mschap_des_encrypt':/usr/src/sbin/iked/chap_ms.c:110: error:
  'des_cblock' undeclared (first use in this
  function)/usr/src/sbin/iked/chap_ms.c:110: error: expected ';'
before
  'des_key'/usr/src/sbin/iked/chap_ms.c:111: error:
'des_key_schedule'
  undeclared (first use in this
  function)/usr/src/sbin/iked/chap_ms.c:111: error: expected ';'
before
  'key_schedule'/usr/src/sbin/iked/chap_ms.c:113: error: 'des_key'
  undeclared (first use in this
  function)/usr/src/sbin/iked/chap_ms.c:115: error: 'key_schedule'
  undeclared (first use in this
  function)/usr/src

sbin/iked fallout after OpenSSL valahalla slashing

2014-04-15 Thread Ian McWilliam
Hoope the attached diff is a correct fix. Hit me with the cluebat if
not.

cc -O2 -pipe  -Wall -I/usr/src/sbin/iked -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith
-Wcast-qual -Wsign-compare -fno-pie   -c
/usr/src/sbin/iked/chap_ms.c/usr/src/sbin/iked/chap_ms.c: In function
'mschap_des_addparity':/usr/src/sbin/iked/chap_ms.c:104: error:
'des_cblock' undeclared (first use in this
function)/usr/src/sbin/iked/chap_ms.c:104: error: (Each undeclared
identifier is reported only once/usr/src/sbin/iked/chap_ms.c:104:
error: for each function it appears
in.)/usr/src/sbin/iked/chap_ms.c:104: error: expected expression
before ')' token/usr/src/sbin/iked/chap_ms.c: In function
'mschap_des_encrypt':/usr/src/sbin/iked/chap_ms.c:110: error:
'des_cblock' undeclared (first use in this
function)/usr/src/sbin/iked/chap_ms.c:110: error: expected ';' before
'des_key'/usr/src/sbin/iked/chap_ms.c:111: error: 'des_key_schedule'
undeclared (first use in this
function)/usr/src/sbin/iked/chap_ms.c:111: error: expected ';' before
'key_schedule'/usr/src/sbin/iked/chap_ms.c:113: error: 'des_key'
undeclared (first use in this
function)/usr/src/sbin/iked/chap_ms.c:115: error: 'key_schedule'
undeclared (first use in this
function)/usr/src/sbin/iked/chap_ms.c:116: error: expected expression
before ')' token/usr/src/sbin/iked/chap_ms.c:117: error: too few
arguments to function 'DES_ecb_encrypt'*** Error 1 in
/usr/src/sbin/iked (:87 'chap_ms.o')
? chap_ms.c.ianm? ided.diffIndex:
chap_ms.c===RCS
file: /cvs/src/sbin/iked/chap_ms.c,vretrieving revision 1.6diff -u -p
-u -p -r1.6 chap_ms.c--- chap_ms.c   8 Jan 2013 10:38:19 -    
  1.6+++ chap_ms.c   16 Apr 2014 05:30:50 -@@ -101,19 +101,19 @@
mschap_des_addparity(u_int8_t *key, u_in        des_key[6] =
get7bits(key, 42);        des_key[7] = get7bits(key, 49);
-       DES_set_odd_parity((des_cblock *)des_key);+      
DES_set_odd_parity((DES_cblock *)des_key); }
 void mschap_des_encrypt(u_int8_t *clear, u_int8_t *key, u_int8_t
*cipher) {-       des_cblock              des_key;-    
  des_key_schedule        key_schedule;+       DES_cblock  
           des_key;+       DES_key_schedule      
 key_schedule;
        mschap_des_addparity(key, des_key);
        DES_set_key(des_key, key_schedule);-      
DES_ecb_encrypt((des_cblock *)clear, (des_cblock *)cipher,+      
DES_ecb_encrypt((DES_cblock *)clear, (DES_cblock *)cipher,       
    key_schedule, 1); }



Re: Switch OpenBSD manuals to DocBook

2014-04-01 Thread Ian McWilliam

On 2/04/2014 6:21 AM, patrick keshishian wrote:

On 4/1/14, Hendrickson, Kenneth khend...@harris.com wrote:

On 4/1/2014, Patrick Keshishian wrote:

sorry to crash your party, but i think you've got something there
with the usage() example. this could reduce man executable to
a one line shell script (or a builtin):

$ cat /usr/bin/man
#!/bin/sh
while [ $# -gt 0 ] ; do $1 -h | ${PAGER:-more} ; shift ; done

Yeah?

Not for man -k (apropros).

Craps! ... maybe someone smarter can figure out a solution
for that, like run through $PATH, and recursively run man on
each executable found, pipe through fancy grep  sed ...

regardless, I don't think we should give up on this! This could
possibly be a GSoC project for someone ... even.




Can't you use the waf build infrastructure to achieve this? It's way 
more efficient.


Ian McWilliam



Re: signed packages

2014-01-22 Thread Ian McWilliam

On 23/01/2014 12:52 AM, Bob Beck wrote:

I think I'll make sure to advertise the next OpenBSD Foundation
funding campaign by suggesting that you're not actually not real
people, but a helpful-suggestions-posting-bot sponsored by the NSA..
  Or maybe it's that they've infiltrated our educational systems...
Please get our your tinfoil hats kids.

OMG there's no replies.. The NSA programmed the 'bot to not respond to
this topic!


That's probably because the NSA are now so high on magic pixie dust from 
your previous post you sent them. When they come down the 'bot will respond.


Ian McWilliam



Re: etc/mtree/special: remove nsd.conf

2013-12-03 Thread Ian McWilliam

On 3/12/2013 7:12 PM, Björn Ketelaars wrote:

/etc/nsd.conf has been moved to /var/nsd/etc/nsd.conf. /etc/changelist has been
changed accordingly, /etc/mtree/special has not. NSD's configuration file
resides in a root:_nsd owned directory with permission set at 0750. As such
there should be no need for inclusion of nsd.conf in the mtree specification for
dangerous files.

Included a small diff file.




Does a conf file really need to be executable?

Ian McWilliam



Re: kernel route 64 bit expire time

2013-10-15 Thread Ian McWilliam

On 15/10/2013 8:51 PM, Stuart Henderson wrote:

On 2013/10/15 00:43, Alexander Bluhm wrote:

Hi,

Convert the route expire timestamp in kernel and routing message
to 64 bit.  Add a small compatibility layer that allows to set
routes with old user land and new kernel.

ports-wise, here's output from a search for rt_metrics/rt_kmetrics/rt_msghdr.
for many, making sure they update (e.g. libc bump or explicit port REVISION 
bump)
is all that's needed, but others e.g. openvpn will need more work.


snip

netatalk-2.2.3/netatalk-2.2.3/etc/atalkd/route.c
53:struct rt_msghdr  rtma_rtm;
65:rtma.rtma_rtm.rtm_version = RTM_VERSION;



There is no kernel support for the old appletalk protocols. atalkd 
should not be installed anymore in the package. It was the appletalk 
routing daemon.


Ian McWilliam



CVS issue?

2013-06-24 Thread Ian McWilliam

Anybody else seeing this updating ports via cvs?

CVSROOT anon...@anoncvs1.ca.openbsd.org:/cvs

cvs update: ignoring databases/erl-couchbeam/patches (CVS/Entries missing)
Write failed: Broken pipe
cvs [update aborted]: end of file from server (consult above messages if 
any)


Ian McWilliam



Re: relayd uses more socket splicing

2012-11-02 Thread Ian McWilliam

fushed - flushed

Though if we were speaking with an extremely broad Australian accent -
I fushed the dunny., maybe what you would hear. So ends today's lesson 
on spelling.  ;-)


Ian McWilliam

On 3/11/2012 5:03 AM, Alexander Bluhm wrote:

Hi,

I have changed relayd so that it uses socket splicing also for
persistent http connections.  Before it spliced the incomming and
outgoing tcp streams only if the data should go unmodified through
the kernel until the end of stream.

With this diff, relayd can give the kernel a maximum splice length.
So it can take back control on persitent http sessions or with http
chunking.

As the diff contains a bunch of independent fixes, I will break it
into small pieces for review and commit.  But for those who want
to test the whole thing, here it is.

bluhm

Index: usr.sbin/relayd/relay.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.157
diff -u -p -r1.157 relay.c
--- usr.sbin/relayd/relay.c 19 Oct 2012 16:49:50 -  1.157
+++ usr.sbin/relayd/relay.c 2 Nov 2012 17:49:50 -
@@ -70,9 +70,6 @@ void   relay_input(struct rsession *);
  
  u_int32_t	 relay_hash_addr(struct sockaddr_storage *, u_int32_t);
  
-int		 relay_splice(struct ctl_relay_event *);

-int relay_splicelen(struct ctl_relay_event *);
-
  SSL_CTX   *relay_ssl_ctx_create(struct relay *);
  void   relay_ssl_transaction(struct rsession *,
struct ctl_relay_event *);
@@ -643,6 +640,7 @@ relay_connected(int fd, short sig, void
case RELAY_PROTO_HTTP:
/* Check the servers's HTTP response */
if (!RB_EMPTY(rlay-rl_proto-response_tree)) {
+   con-se_out.toread = TOREAD_HTTP_HEADER;
outrd = relay_read_http;
if ((con-se_out.nodes = calloc(proto-response_nodes,
sizeof(u_int8_t))) == NULL) {
@@ -681,9 +679,6 @@ relay_connected(int fd, short sig, void
bufferevent_settimeout(bev,
rlay-rl_conf.timeout.tv_sec, rlay-rl_conf.timeout.tv_sec);
bufferevent_enable(bev, EV_READ|EV_WRITE);
-
-   if (relay_splice(con-se_out) == -1)
-   relay_close(con, strerror(errno));
  }
  
  void

@@ -699,6 +694,7 @@ relay_input(struct rsession *con)
/* Check the client's HTTP request */
if (!RB_EMPTY(rlay-rl_proto-request_tree) ||
proto-lateconnect) {
+   con-se_in.toread = TOREAD_HTTP_HEADER;
inrd = relay_read_http;
if ((con-se_in.nodes = calloc(proto-request_nodes,
sizeof(u_int8_t))) == NULL) {
@@ -731,9 +727,6 @@ relay_input(struct rsession *con)
bufferevent_settimeout(con-se_in.bev,
rlay-rl_conf.timeout.tv_sec, rlay-rl_conf.timeout.tv_sec);
bufferevent_enable(con-se_in.bev, EV_READ|EV_WRITE);
-
-   if (relay_splice(con-se_in) == -1)
-   relay_close(con, strerror(errno));
  }
  
  void

@@ -741,10 +734,19 @@ relay_write(struct bufferevent *bev, voi
  {
struct ctl_relay_event  *cre = (struct ctl_relay_event *)arg;
struct rsession *con = cre-con;
+
if (gettimeofday(con-se_tv_last, NULL) == -1)
-   con-se_done = 1;
+   goto fail;
if (con-se_done)
-   relay_close(con, last write (done));
+   goto done;
+   if (relay_splice(cre-dst) == -1)
+   goto fail;
+   return;
+ done:
+   relay_close(con, last write (done));
+   return;
+ fail:
+   relay_close(con, strerror(errno));
  }
  
  void

@@ -822,11 +824,27 @@ relay_splice(struct ctl_relay_event *cre
(proto-tcpflags  TCPFLAG_NSPLICE))
return (0);
  
-	if (cre-bev-readcb != relay_read)

+   if (cre-splicelen = 0)
return (0);
  
+	if (! (cre-toread == TOREAD_UNLIMITED || cre-toread  0)) {

+   DPRINTF(%s: session %d: splice dir %d, nothing to read %lld,
+   __func__, con-se_id, cre-dir, cre-toread);
+   return (0);
+   }
+
+   /* do not splice before buffers have not been completely fushed */
+   if (EVBUFFER_LENGTH(cre-bev-input) ||
+   EVBUFFER_LENGTH(cre-dst-bev-output)) {
+   DPRINTF(%s: session %d: splice dir %d, dirty buffer,
+   __func__, con-se_id, cre-dir);
+   bufferevent_disable(cre-bev, EV_READ);
+   return (2);
+   }
+
bzero(sp, sizeof(sp));
sp.sp_fd = cre-dst-s;
+   sp.sp_max = cre-toread  0 ? cre-toread : 0;
sp.sp_idle = rlay-rl_conf.timeout;
if (setsockopt(cre-s, SOL_SOCKET, SO_SPLICE, sp, sizeof(sp)) == -1) {
log_debug(%s: session %d: splice dir %d failed: %s,
@@ -834,8 +852,11 @@ relay_splice(struct

Re: nfe driver

2011-05-28 Thread Ian McWilliam
 ignored (disabled)
pciide1 at pci0 dev 5 function 0 NVIDIA MCP55 SATA rev 0xa2: DMA
pciide1: using apic 4 int 5 for native-PCI interrupt
wd0 at pciide1 channel 1 drive 0: ST3160815AS
wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors
wd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 6
pciide2 at pci0 dev 5 function 1 NVIDIA MCP55 SATA rev 0xa2: DMA
pciide2: using apic 4 int 10 for native-PCI interrupt
pciide3 at pci0 dev 5 function 2 NVIDIA MCP55 SATA rev 0xa2: DMA
pciide3: using apic 4 int 11 for native-PCI interrupt
ppb0 at pci0 dev 6 function 0 NVIDIA MCP55 PCI-PCI rev 0xa2
pci1 at ppb0 bus 1
pciide4 at pci1 dev 7 function 0 CMD Technology SiI3512 SATA rev 0x01: DMA
pciide4: using apic 4 int 11 for native-PCI interrupt
TI TSB43AB22 FireWire rev 0x00 at pci1 dev 11 function 0 not configured
azalia0 at pci0 dev 6 function 1 NVIDIA MCP55 HD Audio rev 0xa2: apic 4 int
5
azalia0: codecs: Analog Devices AD1988B
audio0 at azalia0
nfe0 at pci0 dev 8 function 0 NVIDIA MCP55 LAN rev 0xa2: apic 4 int 10,
addres
s 00:1a:92:64:34:c3
eephy0 at nfe0 phy 1: 88E1116 Gigabit PHY, rev. 1
nfe1 at pci0 dev 9 function 0 NVIDIA MCP55 LAN rev 0xa2: apic 4 int 10,
addres
s 00:1a:92:64:48:c0
eephy1 at nfe1 phy 1: 88E1116 Gigabit PHY, rev. 1
ppb1 at pci0 dev 14 function 0 NVIDIA MCP55 PCIE rev 0xa2
pci2 at ppb1 bus 2
ppb2 at pci0 dev 15 function 0 NVIDIA MCP55 PCIE rev 0xa2
pci3 at ppb2 bus 3
vga1 at pci3 dev 0 function 0 NVIDIA GeForce 8600 GT rev 0xa1
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pchb0 at pci0 dev 24 function 0 AMD AMD64 0Fh HyperTransport rev 0x00
pchb1 at pci0 dev 24 function 1 AMD AMD64 0Fh Address Map rev 0x00
pchb2 at pci0 dev 24 function 2 AMD AMD64 0Fh DRAM Cfg rev 0x00
kate0 at pci0 dev 24 function 3 AMD AMD64 0Fh Misc Cfg rev 0x00: core rev
JH-F
3
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
it0 at isa0 port 0x2e/2: IT8716F rev 1, EC port 0x290
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 NVIDIA OHCI root hub rev 1.00/1.00 addr 1
mtrr: Pentium Pro MTRR support
umass0 at uhub0 port 9 configuration 1 interface 0 Generic Mass Storage
Device
 rev 2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: Generic, USB CF Reader, 0.00 SCSI2 0/direct
remo
vable
sd1 at scsibus1 targ 1 lun 1: Generic, USB SD Reader, 0.00 SCSI2 0/direct
remo
vable
sd2 at scsibus1 targ 1 lun 2: Generic, USB MS Reader, 0.00 SCSI2 0/direct
remo
vable
sd3 at scsibus1 targ 1 lun 3: Generic, USB SM Reader, 0.00 SCSI2 0/direct
remo
vable
uhidev0 at uhub1 port 6 configuration 1 interface 0 Microsoft Microsoft
3-Butto
n Mouse with IntelliEye(TM) rev 1.10/3.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse1 at ums0 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
root on wd0a swap on wd0b dump on wd0b


Ian McWilliam



Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

2011-05-10 Thread Ian McWilliam

On 10/05/2011 5:34 PM, Artur Grabowski wrote:

On Tue, May 10, 2011 at 5:33 AM, Jeff Licquiaj...@licquia.org  wrote:


My question to you is: do you consider the FHS to be relevant to current

and

future development of OpenBSD?  If not, is this simply due to lack of
maintenance; would your interest in the FHS be greater with more consistent
updates?

More updates will not atone for /lib64.

//art


At least /lib64  is better than winblows 64 bit systems

system32 - 64 bit dll + apps
sysWOW - 32 bit dll + apps

How's that for backwards compatibility.

Ian McWilliam



imsg_init.3 fix

2010-05-27 Thread Ian McWilliam

Slight grammar fix for imsg_init.3.

Ian McWilliam

Index: imsg_init.3
===
RCS file: /cvs/src/lib/libutil/imsg_init.3,v
retrieving revision 1.1
diff -N -u imsg_init.3
--- imsg_init.3 26 May 2010 16:44:32 -  1.1
+++ imsg_init.3 28 May 2010 00:12:21 -
@@ -248,7 +248,7 @@
 for an error.
 Received messages are returned as a
 .Em struct imsg ,
-which much be freed by
+which must be freed by
 .Fn imsg_free
 when no longer required.
 .Em struct imsg