Re: panic - init died
On Sun, Mar 22, 2015 at 8:54 AM, Mages Simon wrote: > we got some Problems with init. > > "init died (signal 11 exit 0)" > > after using reboot(8) without any flags. > > after some investigation i saw that in reboot(8) > at line 241 folling code starts: ... > Every process gets a SIGKILL and becomes a Zombie until > init calls wait(2) on every one of those. But a Zombie > doesn't respond to signals, so after the first iterration > the loop will just wait. After the loop reboot(2) is > called, if processes are still there or not. > > In case every Zombie is finally dead everythings fine > because init is sleeping and the call to vfs_shutdown, > which frees all pages, doesn't affect init. > > But if there are still zombies arround which init tries > to clean up und then reboot(2) is called and frees all > page then init gets a SIGSEGV. Init tries to handle it > but the signal handler for SIGSEGV is also freed allready. ... If the kernel's shutdown handling reaches a point where page faults will themselves fail, then continuing to run user processes should stop. If the VM system is going to pull the rug from under processes, then I'm think that scheduling threads to run is just looking for trouble. Maybe we should stop scheduling non-kernel threads before that point? Philip Guenther
Re: Remove useless lock around opendir/readdir
On Fri, Mar 27, 2015 at 2:50 AM, Carlos MartÃn Nieto wrote: > A call to opendir thread-safe and the readdir calls only share the buffer > within the same directory stream, which is local to this function. Therefore > this lock does not buy us anything. committed, thanks Philip Guenther
Re: Proposed small change for ping(8) -- updated diff
On Mon, Mar 30, 2015 at 9:19 AM, Gregory Edigarov wrote: > After discussing with Sven Falempin changed the message to "Packet timed > out" to be more exact > updated diff: What's the output when ping packets or their replies are reordered? Philip Guenther
Re: [proposal] dump -U by default
On Fri, Apr 3, 2015 at 7:14 AM, Manuel Giraud wrote: > The following patch replaces the -U flag with a -D flag that forces > usage of device name in /etc/dumpdates. The default is now to use DUID. > > Why?: > - dump identification would better be unique > - dumpdates is less human readable but not that less if need be I don't think this the right direction, simply adding a different option. To quote what I wrote back in mid March: I wonder if it could be made the default by first searching for an entry with DUID and lower dump level, and falling back to a device name entry if no matching DUID entry was found or if they were just for higher dump levels. Once you do a level zero for a DUID it'll never look for a device entry again, but during the transition I think that strategy would find the same device entries that it would otherwise have found. This will require more invasive work, but will to the Right Thing for both device and DUID users and will silently and correctly handle the device->DUID transition. Philip Guenther
Re: UPDATE: xf86-input-synaptics 1.8.2
On Sun, Mar 29, 2015 at 04:50:24PM +0500, Alexandr Shadchin wrote: > Hi, > > This diff updates xf86-input-synaptics to the latest release. > Tested on amd64. > > Comments ? OK ? I've been running it for one week on my 2 machines with touchpads. No problem. ok matthieu@. > > -- > Alexandr Shadchin > > Index: ChangeLog > === > RCS file: /cvs/xenocara/driver/xf86-input-synaptics/ChangeLog,v > retrieving revision 1.9 > diff -u -p -r1.9 ChangeLog > --- ChangeLog 24 Jan 2015 17:43:59 - 1.9 > +++ ChangeLog 29 Mar 2015 11:26:05 - > @@ -1,3 +1,70 @@ > +commit 6f8d4bac14ac8f3fd2714f0a8a9e37c5136a4013 > +Author: Peter Hutterer > +Date: Fri Mar 27 11:26:55 2015 +1000 > + > +synaptics 1.8.2 > + > +Signed-off-by: Peter Hutterer > + > +commit 15caf2b53407379f8e677d48a022f4b46b97d83a > +Author: Peter Hutterer > +Date: Tue Mar 24 15:41:39 2015 +1000 > + > +eventcomm: ignore fake and broken MT devices > + > +An MT device without X/Y is not a touchpad. And neither are fake MT > devices. > + > +Signed-off-by: Peter Hutterer > +Reviewed-by: Hans de Goede > +(cherry picked from commit fc9f490a2c87e6f87b0f483cd6bf5f526dddbb8d) > + > +commit ef8daaf696584f7c1d3e9f192de18b5b9f923bdc > +Author: Peter Hutterer > +Date: Mon Mar 23 11:38:15 2015 +1000 > + > +eventcomm: prevent possibly division by zero > + > +This came up as a kernel bug, but it's valid to create uinput devices > with a > +min == max range for x/y. Technically valid, but effectively useless, so > catch > +it, complain and hobble on along. > + > +Signed-off-by: Peter Hutterer > +Reviewed-by: Hans de Goede > +(cherry picked from commit 30866b97be6939b895327b930154ef758eed7ff8) > + > +commit 90c6d7fc60f3db1bd9db1c7702062fcaef3b3352 > +Author: Gabriele Mazzotta > +Date: Thu Jan 15 22:04:17 2015 +0100 > + > +Add a delay between the second button down-up event of double taps > + > +Some applications ignore the second tap of double taps because of the > +lack of a delay between the button down and button up events. > + > +Prevent this by replacing the transition from TS_2B to TS_START with a > +transition from TS_2B to TS_SINGLETAP that emits only a button down > +event. The button up event will be emitted when transitioning from > +TS_SINGLETAP to TS_START. > + > +In addition, decrease the default value of MaxDoubleTapTime from 180 ms > +to 100 ms in order to make double taps faster. > + > +Signed-off-by: Gabriele Mazzotta > +Signed-off-by: Peter Hutterer > +(cherry picked from commit 37d34f0356cc556dd8a49ec5d1ed64d49417a9b2) > + > +commit 649b77f0ce617fd1ec073b281636e304e80b56c0 > +Author: Gabriele Mazzotta > +Date: Thu Jan 15 22:04:16 2015 +0100 > + > +Update machine state diagram > + > +The diagram didn't entirely reflect the current state of the code. > + > +Signed-off-by: Gabriele Mazzotta > +Signed-off-by: Peter Hutterer > +(cherry picked from commit a357647d3fb918b94efbda98138fb0240a949ef2) > + > commit d50c4bab8ae2836a0f38b29a5d22be2e950e4d08 > Author: Peter Hutterer > Date: Thu Sep 18 07:40:13 2014 +1000 > Index: Makefile.in > === > RCS file: /cvs/xenocara/driver/xf86-input-synaptics/Makefile.in,v > retrieving revision 1.10 > diff -u -p -r1.10 Makefile.in > --- Makefile.in 15 Jan 2015 01:30:40 - 1.10 > +++ Makefile.in 29 Mar 2015 11:26:05 - > @@ -74,8 +74,8 @@ subdir = . > DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \ > $(srcdir)/Makefile.in $(srcdir)/config.h.in \ > $(srcdir)/xorg-synaptics.pc.in $(top_srcdir)/configure COPYING \ > - ChangeLog INSTALL config.guess config.sub depcomp install-sh \ > - ltmain.sh missing > + ChangeLog INSTALL compile config.guess config.sub depcomp \ > + install-sh ltmain.sh missing > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > am__aclocal_m4_deps = $(top_srcdir)/configure.ac > am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ > Index: compile > === > RCS file: compile > diff -N compile > --- /dev/null 1 Jan 1970 00:00:00 - > +++ compile 29 Mar 2015 11:26:05 - > @@ -0,0 +1,347 @@ > +#! /bin/sh > +# Wrapper for compilers which do not understand '-c -o'. > + > +scriptversion=2012-10-14.11; # UTC > + > +# Copyright (C) 1999-2014 Free Software Foundation, Inc. > +# Written by Tom Tromey . > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2, or (at your option) > +# any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WA
Re: pfi_kif leaks for PBR rules
Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote: > > is missing at pfr_destroy_kentry(). We created patch against OpenBSD CURRENT. > We have no OpenBSD boxes around, where we could verify our fix. > You are aware that OpenBSD supports both host and guest roles of Sparc system virtualization ? Quite easy to install, I might add, it's very simple to setup. As a host of virtual guests, it also supports a bit of modern Sparc hardware, out-of-the-box. Chris
db mmap
If we've gotten by this long without mmap, I think we can keep going a little
longer. Enabling this code would requre more testing than it's worth.
Index: btree/btree.h
===
RCS file: /cvs/src/lib/libc/db/btree/btree.h,v
retrieving revision 1.6
diff -u -p -r1.6 btree.h
--- btree/btree.h 2 Jun 2003 20:18:33 - 1.6
+++ btree/btree.h 5 Apr 2015 14:40:39 -
@@ -367,7 +367,6 @@ typedef struct _btree {
#defineR_CLOSEFP 0x00040 /* opened a file pointer */
#defineR_EOF 0x00100 /* end of input file reached. */
#defineR_FIXLEN0x00200 /* fixed length records */
-#defineR_MEMMAPPED 0x00400 /* memory mapped file. */
#defineR_INMEM 0x00800 /* in-memory file */
#defineR_MODIFIED 0x01000 /* modified file */
#defineR_RDONLY0x02000 /* read-only file */
Index: recno/rec_close.c
===
RCS file: /cvs/src/lib/libc/db/recno/rec_close.c,v
retrieving revision 1.11
diff -u -p -r1.11 rec_close.c
--- recno/rec_close.c 5 Aug 2005 13:03:00 - 1.11
+++ recno/rec_close.c 5 Apr 2015 14:40:25 -
@@ -69,8 +69,6 @@ __rec_close(DB *dbp)
/* Committed to closing. */
status = RET_SUCCESS;
- if (F_ISSET(t, R_MEMMAPPED) && munmap(t->bt_smap, t->bt_msize))
- status = RET_ERROR;
if (!F_ISSET(t, R_INMEM)) {
if (F_ISSET(t, R_CLOSEFP)) {
Index: recno/rec_open.c
===
RCS file: /cvs/src/lib/libc/db/recno/rec_open.c,v
retrieving revision 1.11
diff -u -p -r1.11 rec_open.c
--- recno/rec_open.c5 Aug 2005 13:03:00 - 1.11
+++ recno/rec_open.c5 Apr 2015 14:40:04 -
@@ -138,39 +138,10 @@ slow: if ((t->bt_rfp = fdopen(rfd, "r"
if (fstat(rfd, &sb))
goto err;
- /*
-* Kluge -- we'd like to test to see if the file is too
-* big to mmap. Since, we don't know what size or type
-* off_t's or size_t's are, what the largest unsigned
-* integral type is, or what random insanity the local
-* C compiler will perpetrate, doing the comparison in
-* a portable way is flatly impossible. Hope that mmap
-* fails if the file is too large.
-*/
if (sb.st_size == 0)
F_SET(t, R_EOF);
else {
-#ifdef MMAP_NOT_AVAILABLE
- /*
-* XXX
-* Mmap doesn't work correctly on many current
-* systems. In particular, it can fail subtly,
-* with cache coherency problems. Don't use it
-* for now.
-*/
- t->bt_msize = sb.st_size;
- if ((t->bt_smap = mmap(NULL, t->bt_msize,
- PROT_READ, MAP_FILE | MAP_PRIVATE, rfd,
- (off_t)0)) == MAP_FAILED)
- goto slow;
- t->bt_cmap = t->bt_smap;
- t->bt_emap = t->bt_smap + sb.st_size;
- t->bt_irec = F_ISSET(t, R_FIXLEN) ?
- __rec_fmap : __rec_vmap;
- F_SET(t, R_MEMMAPPED);
-#else
goto slow;
-#endif
}
}
}
Re: copy'n'paste like typo in pf.c
On Sun, Apr 05, 2015 at 11:48:21AM +0200, Alexandr Nedvedicky wrote: > Hello, > > when we ran PF sources through coverity we got an error > as follows: > > 8310 if (ri->r->dst.addr.type == PF_ADDR_TABLE) > 8311 pfr_update_stats(ri->r->dst.addr.p.tbl, > 8312 &s->key[(s->direction == PF_IN)]-> > 8313 addr[(s->direction == PF_IN)], > > > CID 38100 (#1 of 1): Copy-paste error (COPY_PASTE_ERROR)copy_paste_error: src > in ri->r->src.neg looks like a copy-paste error. > > Should it say dst instead? > 8314pd, ri->r->action, ri->r->src.neg); > 8315} > 8316} > > (note: line numbers won't match line numbers in OpenBSD). > > It seems to me coveirty is right. Patch against CURRENT is attached. > > kind regards > sasha > > > - cut here to get patch -- > Warning: Permanently added 'anoncvs.ca.openbsd.org' (ECDSA) to the list of > known hosts. > Index: pf.c > === > RCS file: /cvs/src/sys/net/pf.c,v > retrieving revision 1.909 > diff -u -r1.909 pf.c > --- pf.c18 Mar 2015 12:23:15 - 1.909 > +++ pf.c5 Apr 2015 09:46:46 - > @@ -6277,7 +6277,7 @@ > > pfr_update_stats(ri->r->dst.addr.p.tbl, > &s->key[(s->direction == PF_IN)]-> > addr[(s->direction == PF_IN)], > - pd, ri->r->action, > ri->r->src.neg); > + pd, ri->r->action, > ri->r->dst.neg); > } > } > if (r->src.addr.type == PF_ADDR_TABLE) > > Index: pf.c > === > RCS file: /cvs/src/sys/net/pf.c,v > retrieving revision 1.909 > diff -u -r1.909 pf.c > --- pf.c 18 Mar 2015 12:23:15 - 1.909 > +++ pf.c 5 Apr 2015 09:47:18 - > @@ -6277,7 +6277,7 @@ > pfr_update_stats(ri->r->dst.addr.p.tbl, > &s->key[(s->direction == PF_IN)]-> > addr[(s->direction == PF_IN)], > - pd, ri->r->action, ri->r->src.neg); > + pd, ri->r->action, ri->r->dst.neg); > } > } > if (r->src.addr.type == PF_ADDR_TABLE) This looks correct. OK florian@ -- I'm not entirely sure you are real.
Re: [PATCH] bsd.port.mk - make relation between GH_TAGNAME & GH_COMMIT more apparent (prevent actual bug regression)
On Sun, Apr 5, 2015, at 01:31 PM, Stuart Henderson wrote:
> On 2015-04-04, Landry Breuil wrote:
> > On Sat, Apr 04, 2015 at 11:07:11PM +0200, Adam Wolk wrote:
> >> Hi tech@
> >>
> >> I'm the maintainer of www/otter-browser and I got caught while packaging
> >> otter-browser 0.9.04. Upstream asked us to point at a different commit
> >> then the tagged revision so we did:
> >>
> >> GH_TAGNAME = v0.9.04
> >> # This is the actual tagged revision
> >> # GH_COMMIT = 869d29d19719b3057e137a79d4a10025d2c920f6
> >> # but we were asked by upstream to release from the following commit
> >> # as it's considered an important fix affecting the majority of users
> >> GH_COMMIT =23d7ee6f9cd636e750687a01975b177c1c9c2e53
> >>
> >> This port was reviewed with an ok by two people and underwent further
> >> changes later on.
> >>
> >> I didn't notice that the port actually packaged GH_TAGNAME contents
> >> instead of GH_COMMIT.
> >
> > GH_COMMIT is meaningless in terms of "package version", which expects a
> > correctly structured version, hence GH_TAGNAME being usually used in
> > combination with GH_PROJECT.
>
> Pretty much all ports with GH_TAGNAME are also setting GH_COMMIT, but
> GH_COMMIT doesn't do anything there. I think we were hoping it would
> fetch a specific commitid in case the tag was slided, but it doesn't
> look like github supports that.
>
I can confirm this. That's how I got burned with otter. Ports 'tell you'
that they
are downloading from that 'tag' pluus the GH_COMMIT you set making you
think it's actually downloading the proper changeset.
In reality, github does redirects behind the scene and points at the
tagged
revision.
> I think we should remove the existing ones and make it an error to
> specify both GH_TAGNAME and GH_COMMIT. Thoughts? If people think this
> is a good idea I'll do the ports mop-up.
>
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1288
> diff -u -p -r1.1288 bsd.port.mk
> --- bsd.port.mk 4 Jan 2015 05:47:07 - 1.1288
> +++ bsd.port.mk 5 Apr 2015 11:30:41 -
> @@ -1168,6 +1168,9 @@ MASTER_SITE_OVERRIDE ?= No
> .endif
>
> .if !empty(GH_ACCOUNT) && !empty(GH_PROJECT)
> +. if !empty(GH_COMMIT) && !empty(GH_TAGNAME)
> +ERRORS += "Fatal: specifying both GH_TAGNAME and GH_COMMIT is invalid"
> +. endif
> . if ${GH_TAGNAME} == master
> ERRORS += "Fatal: using master as GH_TAGNAME is invalid"
> . endif
>
>
I think it is a good idea. I would also suggest changing the docs to no
longer
suggest that it is good practice to set both.
Index: bsd.port.mk.5
===
RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v
retrieving revision 1.415
diff -u -p -r1.415 bsd.port.mk.5
--- bsd.port.mk.5 3 Apr 2015 10:19:22 - 1.415
+++ bsd.port.mk.5 5 Apr 2015 12:26:41 -
@@ -1701,8 +1701,7 @@ Yields a suitable default for
Account name of the GitHub user hosting the project.
.It Ev GH_COMMIT
SHA1 commit id to fetch.
-It is good practice to always specify
-the commit id, even if ${GH_TAGNAME} was specified.
+It is an error to specify ${GH_COMMIT} when ${GH_TAGNAME} is specified.
.It Ev GH_PROJECT
Name of the project on GitHub.
.It Ev GH_TAGNAME
Re: [PATCH] bsd.port.mk - make relation between GH_TAGNAME & GH_COMMIT more apparent (prevent actual bug regression)
On 2015-04-04, Landry Breuil wrote:
> On Sat, Apr 04, 2015 at 11:07:11PM +0200, Adam Wolk wrote:
>> Hi tech@
>>
>> I'm the maintainer of www/otter-browser and I got caught while packaging
>> otter-browser 0.9.04. Upstream asked us to point at a different commit
>> then the tagged revision so we did:
>>
>> GH_TAGNAME = v0.9.04
>> # This is the actual tagged revision
>> # GH_COMMIT = 869d29d19719b3057e137a79d4a10025d2c920f6
>> # but we were asked by upstream to release from the following commit
>> # as it's considered an important fix affecting the majority of users
>> GH_COMMIT =23d7ee6f9cd636e750687a01975b177c1c9c2e53
>>
>> This port was reviewed with an ok by two people and underwent further
>> changes later on.
>>
>> I didn't notice that the port actually packaged GH_TAGNAME contents
>> instead of GH_COMMIT.
>
> GH_COMMIT is meaningless in terms of "package version", which expects a
> correctly structured version, hence GH_TAGNAME being usually used in
> combination with GH_PROJECT.
Pretty much all ports with GH_TAGNAME are also setting GH_COMMIT, but
GH_COMMIT doesn't do anything there. I think we were hoping it would
fetch a specific commitid in case the tag was slided, but it doesn't
look like github supports that.
I think we should remove the existing ones and make it an error to
specify both GH_TAGNAME and GH_COMMIT. Thoughts? If people think this
is a good idea I'll do the ports mop-up.
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1288
diff -u -p -r1.1288 bsd.port.mk
--- bsd.port.mk 4 Jan 2015 05:47:07 - 1.1288
+++ bsd.port.mk 5 Apr 2015 11:30:41 -
@@ -1168,6 +1168,9 @@ MASTER_SITE_OVERRIDE ?= No
.endif
.if !empty(GH_ACCOUNT) && !empty(GH_PROJECT)
+. if !empty(GH_COMMIT) && !empty(GH_TAGNAME)
+ERRORS += "Fatal: specifying both GH_TAGNAME and GH_COMMIT is invalid"
+. endif
. if ${GH_TAGNAME} == master
ERRORS += "Fatal: using master as GH_TAGNAME is invalid"
. endif
pfi_kif leaks for PBR rules
Hello,
while testing PBR on Solaris we found out the pfi_kif instances
are not removed from pfi_ifs table. We took a look at crashdump
and have seen pfik_route counter at those object is still
non-zero, while all rules were gone.
looking at sources we can see the 'pfik_route' (PFI_KIF_REF_ROUTE)
reference is being grabbed in pfr_create_kentry():
840 case PFRKE_ROUTE:
841 if (ad->pfra_ifname[0])
842 ke->pfrke_rkif = pfi_kif_get(ad->pfra_ifname);
843 if (ke->pfrke_rkif)
844 pfi_kif_ref(ke->pfrke_rkif, PFI_KIF_REF_ROUTE);
845 break;
846 default:
847 panic("unknown pfrke_type %d", ke->pfrke_type);
848 break;
however we have not found any matching pfi_kif_ref() command, which
would remove the reference created by pfr_create_kentry(). It seems
to us the call to
pfi_kif_unref(ke->pfrke_rkif, PFI_KIF_REF_ROUTE)
is missing at pfr_destroy_kentry(). We created patch against OpenBSD CURRENT.
We have no OpenBSD boxes around, where we could verify our fix.
also for your info: IPF in Solaris is on its death row. PF in 11.3
release will be available as optional firewall. We hope to make PF
default (and only firewall) in Solaris 12. You've made excellent job,
your PF is crystal-clear design.
kind regards
sasha
--- cut here to get a patch ---
Index: pf_table.c
===
RCS file: /cvs/src/sys/net/pf_table.c,v
retrieving revision 1.106
diff -u -r1.106 pf_table.c
--- pf_table.c 14 Mar 2015 03:38:51 - 1.106
+++ pf_table.c 5 Apr 2015 09:59:58 -
@@ -877,6 +877,17 @@
{
if (ke->pfrke_counters)
pool_put(&pfr_kcounters_pl, ke->pfrke_counters);
+
+ switch (ke->pfrke_type) {
+ case PFRKE_COST:
+ /* FALLTHROUGH */
+ case PFRKE_ROUTE:
+ if (ke->pfrke_rkif != NULL) {
+ pfi_kif_unref(ke->pfrke_rkif, PFI_KIF_REF_ROUTE);
+ }
+ break;
+ default:
+ }
pool_put(&pfr_kentry_pl[ke->pfrke_type], ke);
}
Index: pf_table.c
===
RCS file: /cvs/src/sys/net/pf_table.c,v
retrieving revision 1.106
diff -u -r1.106 pf_table.c
--- pf_table.c 14 Mar 2015 03:38:51 - 1.106
+++ pf_table.c 5 Apr 2015 10:00:07 -
@@ -877,6 +877,17 @@
{
if (ke->pfrke_counters)
pool_put(&pfr_kcounters_pl, ke->pfrke_counters);
+
+ switch (ke->pfrke_type) {
+ case PFRKE_COST:
+ /* FALLTHROUGH */
+ case PFRKE_ROUTE:
+ if (ke->pfrke_rkif != NULL) {
+ pfi_kif_unref(ke->pfrke_rkif, PFI_KIF_REF_ROUTE);
+ }
+ break;
+ default:
+ }
pool_put(&pfr_kentry_pl[ke->pfrke_type], ke);
}
copy'n'paste like typo in pf.c
Hello, when we ran PF sources through coverity we got an error as follows: 8310 if (ri->r->dst.addr.type == PF_ADDR_TABLE) 8311 pfr_update_stats(ri->r->dst.addr.p.tbl, 8312 &s->key[(s->direction == PF_IN)]-> 8313 addr[(s->direction == PF_IN)], CID 38100 (#1 of 1): Copy-paste error (COPY_PASTE_ERROR)copy_paste_error: src in ri->r->src.neg looks like a copy-paste error. Should it say dst instead? 8314pd, ri->r->action, ri->r->src.neg); 8315} 8316} (note: line numbers won't match line numbers in OpenBSD). It seems to me coveirty is right. Patch against CURRENT is attached. kind regards sasha - cut here to get patch -- Warning: Permanently added 'anoncvs.ca.openbsd.org' (ECDSA) to the list of known hosts. Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.909 diff -u -r1.909 pf.c --- pf.c18 Mar 2015 12:23:15 - 1.909 +++ pf.c5 Apr 2015 09:46:46 - @@ -6277,7 +6277,7 @@ pfr_update_stats(ri->r->dst.addr.p.tbl, &s->key[(s->direction == PF_IN)]-> addr[(s->direction == PF_IN)], - pd, ri->r->action, ri->r->src.neg); + pd, ri->r->action, ri->r->dst.neg); } } if (r->src.addr.type == PF_ADDR_TABLE) Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.909 diff -u -r1.909 pf.c --- pf.c18 Mar 2015 12:23:15 - 1.909 +++ pf.c5 Apr 2015 09:47:18 - @@ -6277,7 +6277,7 @@ pfr_update_stats(ri->r->dst.addr.p.tbl, &s->key[(s->direction == PF_IN)]-> addr[(s->direction == PF_IN)], - pd, ri->r->action, ri->r->src.neg); + pd, ri->r->action, ri->r->dst.neg); } } if (r->src.addr.type == PF_ADDR_TABLE)
Re: Compiling ports tree on older architecture question
On Sun, Apr 05, 2015 at 12:23:38AM -0400, ian kremlin wrote: > Hello tech! > > A friend is borrowing one of my machines to build the entire pkgsrc > tree, a task that entails compiling more than 15k individual programs. > This has taken 3 days, even on my modern and prepared amd64 machine! (to > my surprise). This has me curious: > > > Every OpenBSD release includes an immediately-accessible source for > prebuilt binary packages, meaning a similar feat involving building an > entire tree of ports must be performed. How is this handled on platforms > like vax or hppa? How long does it take using ostensibly decades-old > machines? Pending hardware & kernel reliability.. have some numbers: macppc: 3 hosts (Xserve G4, 2 MP running SP), around 15 days for ~8400 pkgs alpha: 2 hosts (DS20L MP running SP + DS10L), around 18/20 days for ~6900 pkgs sparc64: 3 SP hosts (2 v210 +, 1 v215), around 17 days for ~8300 pkgs hppa: 2 MP hosts (J6000 + J6700), around 9/10 days for ~6700 pkgs Landry
Re: Compiling ports tree on older architecture question
I do the 32bit sparc packages builds. We hvae a cluster of 5 machines, and they take roughly 3 weeks to build if there are no crashes or other issues. Right now thought, not all machines are able to build, so it will be closer to 5 weeks. On 2015 Apr 05 (Sun) at 00:23:38 -0400 (-0400), ian kremlin wrote: :Hello tech! : :A friend is borrowing one of my machines to build the entire pkgsrc :tree, a task that entails compiling more than 15k individual programs. :This has taken 3 days, even on my modern and prepared amd64 machine! (to :my surprise). This has me curious: : : :Every OpenBSD release includes an immediately-accessible source for :prebuilt binary packages, meaning a similar feat involving building an :entire tree of ports must be performed. How is this handled on platforms :like vax or hppa? How long does it take using ostensibly decades-old :machines? : : :Ian : -- The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers.
