ps: remove emul support
It's all "native".
Index: bin/ps/extern.h
===
RCS file: /cvs/src/bin/ps/extern.h,v
retrieving revision 1.19
diff -u -p -r1.19 extern.h
--- bin/ps/extern.h 10 Jan 2016 14:04:16 - 1.19
+++ bin/ps/extern.h 26 Mar 2016 07:37:47 -
@@ -47,7 +47,6 @@ __BEGIN_DECLS
voidcommand(const struct kinfo_proc *, VARENT *);
voidcputime(const struct kinfo_proc *, VARENT *);
int donlist(void);
-voidemulname(const struct kinfo_proc *, VARENT *);
double getpcpu(const struct kinfo_proc *);
double getpmem(const struct kinfo_proc *);
voidgname(const struct kinfo_proc *, VARENT *);
Index: bin/ps/keyword.c
===
RCS file: /cvs/src/bin/ps/keyword.c,v
retrieving revision 1.43
diff -u -p -r1.43 keyword.c
--- bin/ps/keyword.c30 Dec 2015 14:59:10 - 1.43
+++ bin/ps/keyword.c26 Mar 2016 07:37:47 -
@@ -100,7 +100,6 @@ VAR var[] = {
{"cputime", "", "time"},
{"cwd", "CWD", NULL, LJUST, curwd, CWDLEN},
{"dsiz", "DSIZ", NULL, 0, dsize, 4},
- {"emul", "EMUL", NULL, LJUST, emulname, KI_EMULNAMELEN - 1},
{"etime", "ELAPSED", "start"},
{"f", "F", NULL, 0, pvar, 7, 0, POFF(p_flag), INT32, "x"},
{"flags", "", "f"},
Index: bin/ps/print.c
===
RCS file: /cvs/src/bin/ps/print.c,v
retrieving revision 1.66
diff -u -p -r1.66 print.c
--- bin/ps/print.c 10 Jan 2016 14:04:16 - 1.66
+++ bin/ps/print.c 26 Mar 2016 07:37:47 -
@@ -672,13 +672,3 @@ pvar(const struct kinfo_proc *kp, VARENT
else
printval((char *)kp + v->off, v);
}
-
-void
-emulname(const struct kinfo_proc *kp, VARENT *ve)
-{
- VAR *v;
-
- v = ve->var;
-
- (void)printf("%-*s", (int)v->width, kp->p_emul);
-}
Index: bin/ps/ps.1
===
RCS file: /cvs/src/bin/ps/ps.1,v
retrieving revision 1.104
diff -u -p -r1.104 ps.1
--- bin/ps/ps.1 17 Mar 2016 07:18:33 - 1.104
+++ bin/ps/ps.1 26 Mar 2016 07:37:47 -
@@ -209,8 +209,6 @@ CPU ID (zero on single processor systems
Current working directory.
.It Cm dsiz
Data size, in Kilobytes.
-.It Cm emul
-Name of system call emulation environment.
.It Cm flags
Alias:
.Cm f .
--
Michal Mazurek
Miscellaneous Xenocara quirks
Hello!
Here are five miscellaneous Xenocara quirks caught up.
The first three were also found on upstream, but the last two seem to be
specific to your distro.
Thanks,
Tiago Silva
--- /app/xcmsdb/xcmsdb.cFri Apr 17 05:49:30 2015
+++ /app/xcmsdb/xcmsdb.cSat Mar 26 03:39:46 2016
@@ -71,8 +71,8 @@
"-query query Screen Color
Characterization Data\n"
"-remove remove Screen Color
Characterization Data\n"
#ifdef GRAY
-"-color use color as default\n");
-"-grayuse gray-scale as default\n");
+"-color use color as default\n"
+"-grayuse gray-scale as default\n"
#endif /* GRAY */
"-version print program version\n"
"\n");
--- /driver/x86-video-ast/src/ast_accel.c Wed Aug 19 01:24:48 2015
+++ /driver/x86-video-ast/src/ast_accel.c Sat Mar 26 04:21:48 2016
@@ -273,7 +273,7 @@
infoPtr->ClippingFlags = HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY |
HARDWARE_CLIP_MONO_8x8_FILL|
HARDWARE_CLIP_COLOR_8x8_FILL |
-HARDWARE_CLIP_SOLID_LINE |
+HARDWARE_CLIP_SOLID_FILL |
HARDWARE_CLIP_DASHED_LINE |
HARDWARE_CLIP_SOLID_LINE;
}
--- /lib/libXmu/src/ShapeWidg.c Sun Sep 08 04:28:18 2013
+++ /lib/libXmu/src/ShapeWidg.c Sat Mar 26 04:14:17 2016
@@ -201,7 +201,7 @@
GC gc;
unsigned long mask;
- if (width < 3 || width < 3)
+ if (width < 3 || height < 3)
return;
width += w->core.border_width << 1;
height += w->core.border_width << 1;
--- /app/xlockmore/modes/life.c Sun Nov 26 17:13:23 2006
+++ /app/xlockmore/modes/life.c Sat Mar 26 04:53:58 2016
@@ -1641,7 +1641,7 @@
hsp = 0;
vsp = (int) (lp->nrows - (lp->ncols - temp) *
1.35) / 2;
}
- switch NRAND(4) {
+ switch (NRAND(4)) {
case 0: /* Upper left */
break;
case 1: /* Upper right */
--- /dist/Mesa/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c Sat Feb
21 08:18:05 2015
+++ /dist/Mesa/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c Sat Mar
26 04:59:30 2016
@@ -231,12 +231,12 @@
BEGIN_NV04(push, NV50_3D(SCISSOR_HORIZ(i)), 2);
PUSH_DATA (push, (maxx << 16) | minx);
PUSH_DATA (push, (maxy << 16) | miny);
+ }
#else
BEGIN_NV04(push, NV50_3D(SCISSOR_HORIZ(i)), 2);
PUSH_DATA (push, (s->maxx << 16) | s->minx);
PUSH_DATA (push, (s->maxy << 16) | s->miny);
#endif
- }
nv50->scissors_dirty = 0;
}
First ART regression
semarie@ found that rtadvd(8) is printing the following messages with an
ART-enabled kernel:
"rtadvd[43548]: new interface route's plen 128 is invalid for a prefix"
This is due to the prefix length to mask conversion code. Previously
the RTAX_NETMASK argument of a routing message was NULL for every host
route. With ART it contains a mask of the size of the address.
Diff below fixes that, ok?
Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.296
diff -u -p -r1.296 route.c
--- net/route.c 7 Mar 2016 18:44:00 - 1.296
+++ net/route.c 26 Mar 2016 10:15:01 -
@@ -480,7 +480,8 @@ rt_sendmsg(struct rtentry *rt, int cmd,
memset(&info, 0, sizeof(info));
info.rti_info[RTAX_DST] = rt_key(rt);
info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
- info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, &sa_mask);
+ if (!ISSET(rt->rt_flags, RTF_HOST))
+ info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, &sa_mask);
info.rti_info[RTAX_LABEL] = rtlabel_id2sa(rt->rt_labelid, &sa_rl);
ifp = if_get(rt->rt_ifidx);
if (ifp != NULL) {
Re: Scheduler hack for multi-threaded processes
I can report significant usability improvement on a single core ThinkPad T42 and a dual core ThinkPad X60. It's not just "the videos in Firefox" - everything works *so* much more fluently with the patch there's no way I would go back living without it. I know a hack is a hack and I know there are many unknowns there, but at least from the perspective of a "normal" OpenBSD desktop user, this patch is an absolute must. Let's not start a flame war here, just throwing in my five cents. Kudos to Martin. -j.
Re: mpsafe aesni
On Fri, Mar 25, 2016 at 22:43 +0100, Mark Kettenis wrote: > > From: Mike Belopuhov > > Date: Thu, 24 Mar 2016 21:33:25 +0100 > > > > On 24 March 2016 at 20:53, Mark Kettenis wrote: > > > Diff below makes aesni crypto "mpsafe". It adds a CRYPTOCAP_F_MPSAFE > > > flag that makes the crypto framework dispatch to an mpsafe taskq if it > > > is set. In order to make the aesni_process() function that does the > > > actual crypto work mpsafe, it moves the code over to a per-session > > > working buffer. This obviously increases the cost of setting up a > > > session a bit. Directly invoked crypto operations remain locked. My > > > main laptop seem to do ipsec fine with this, but I'm not sure if there > > > is an actual performance gain. So it would probably be good if > > > somebody could benchmark this. > > > > > > Comments? > > > > It should be fairly simple to use SRP for the session list so that you > > don't have to take the mutex in the aesni_process. Other than that I > > think this should go in once tests are made and people a happy with > > the results. > > Actually, I'm not sure that's possible. I think aesni_newsession() > and aesni_freesession() can be called from interrupt context or at > least are not supposed to sleep. I thought that it's not possible, but it looks like at least tdb_free can be called anywhere and it will trigger freesession, which is a tad unfortunate IMO, yet understandable. > They would call > SRPL_INSERT_HEAD_LOCKED() and SRPL_REMOVE_LOCKED(), which can only be > called from process context. > Not process context though, but under a lock, which wouldn't save us the mtx_enter anyway. > > Another question I have is why are you using an IPL_HIGH mutex? > > The crypto code may be called from any subsystem, so that is the only > safe choice. Well, it's not called from all subsystems, just those that use IPL_BIO and IPL_NET for interrupts and IPL_HIGH just includes AUDIO and CLOCK which don't call any crypto(9) code. So what are you trying to protect it from or is it just a placeholder value? I'm fine if it is, just curious.
[patch] installboot
Hi, Here a little diff to fix small memory leaks inside installboot. Hope it finds its way. Kind regards. Index: i386_installboot.c === RCS file: /cvs/src/usr.sbin/installboot/i386_installboot.c,v retrieving revision 1.26 diff -u -p -r1.26 i386_installboot.c --- i386_installboot.c 28 Dec 2015 23:00:29 - 1.26 +++ i386_installboot.c 24 Mar 2016 17:15:53 - @@ -794,6 +794,8 @@ getbootparams(char *boot, int devfd, str (unsigned int)char *)ap) - buf) + INODEOFF)); } + free(buf); + return 0; } Index: i386_softraid.c === RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v retrieving revision 1.9 diff -u -p -r1.9 i386_softraid.c --- i386_softraid.c 1 Dec 2015 06:39:52 - 1.9 +++ i386_softraid.c 24 Mar 2016 17:15:53 - @@ -194,5 +194,7 @@ sr_install_bootldr(int devfd, char *dev) fprintf(stderr, "%s is %d blocks x %d bytes\n", stage2, nblocks, bsize); + free(p); + close(fd); }
Re: First ART regression
On Sat, Mar 26, 2016 at 02:58:37PM +0100, Martin Pieuchot wrote:
> semarie@ found that rtadvd(8) is printing the following messages with an
> ART-enabled kernel:
>
> "rtadvd[43548]: new interface route's plen 128 is invalid for a prefix"
>
> This is due to the prefix length to mask conversion code. Previously
> the RTAX_NETMASK argument of a routing message was NULL for every host
> route. With ART it contains a mask of the size of the address.
>
> Diff below fixes that, ok?
OK bluhm@
>
> Index: net/route.c
> ===
> RCS file: /cvs/src/sys/net/route.c,v
> retrieving revision 1.296
> diff -u -p -r1.296 route.c
> --- net/route.c 7 Mar 2016 18:44:00 - 1.296
> +++ net/route.c 26 Mar 2016 10:15:01 -
> @@ -480,7 +480,8 @@ rt_sendmsg(struct rtentry *rt, int cmd,
> memset(&info, 0, sizeof(info));
> info.rti_info[RTAX_DST] = rt_key(rt);
> info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
> - info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, &sa_mask);
> + if (!ISSET(rt->rt_flags, RTF_HOST))
> + info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, &sa_mask);
> info.rti_info[RTAX_LABEL] = rtlabel_id2sa(rt->rt_labelid, &sa_rl);
> ifp = if_get(rt->rt_ifidx);
> if (ifp != NULL) {
Re: uvm: remove unused(?) amap_extend
Stefan Kempf wrote:
> amap_extend is called when merging two adjacent areas of virtual address
> space. However, merging is done only for kernel
> virtual address space. It's not done for user space:
>
> uvm/uvm_map.c:1359
> /*
>* Try to merge entry.
>*
>* Userland allocations are kept separated most of the time.
>* Forego the effort of merging what most of the time can't be merged
>* and only try the merge if it concerns a kernel entry.
>*/
> if ((flags & UVM_FLAG_NOMERGE) == 0 &&
> (map->flags & VM_MAP_ISVMSPACE) == 0)
> uvm_mapent_tryjoin(map, entry, &dead);
>
>
> As far as I can tell, kernel vm_map_entries do not use amaps. So
> amap_extend should never be called. Can we remove it?
Any objections against committing this diff?
Merging vm map entries for userspace was turned off a long time
ago in r1.104 of uvm/uvm_map.c.
The kernel doesn't use amaps either. Removing this would make the amap
shrink diffs simpler.
> Index: uvm/uvm_amap.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 uvm_amap.c
> --- uvm/uvm_amap.c16 Mar 2016 16:53:43 - 1.62
> +++ uvm/uvm_amap.c23 Mar 2016 17:03:53 -
> @@ -279,174 +279,6 @@ amap_free(struct vm_amap *amap)
> }
>
> /*
> - * amap_extend: extend the size of an amap (if needed)
> - *
> - * => called from uvm_map when we want to extend an amap to cover
> - *a new mapping (rather than allocate a new one)
> - * => to safely extend an amap it should have a reference count of
> - *one (thus it can't be shared)
> - * => XXXCDC: support padding at this level?
> - */
> -int
> -amap_extend(struct vm_map_entry *entry, vsize_t addsize)
> -{
> - struct vm_amap *amap = entry->aref.ar_amap;
> - int slotoff = entry->aref.ar_pageoff;
> - int slotmapped, slotadd, slotneed, slotalloc;
> -#ifdef UVM_AMAP_PPREF
> - int *newppref, *oldppref;
> -#endif
> - u_int *newsl, *newbck, *oldsl, *oldbck;
> - struct vm_anon **newover, **oldover;
> - int slotadded;
> -
> - /*
> - * first, determine how many slots we need in the amap. don't
> - * forget that ar_pageoff could be non-zero: this means that
> - * there are some unused slots before us in the amap.
> - */
> - AMAP_B2SLOT(slotmapped, entry->end - entry->start); /* slots mapped */
> - AMAP_B2SLOT(slotadd, addsize); /* slots to add */
> - slotneed = slotoff + slotmapped + slotadd;
> -
> - /*
> - * case 1: we already have enough slots in the map and thus
> - * only need to bump the reference counts on the slots we are
> - * adding.
> - */
> - if (amap->am_nslot >= slotneed) {
> -#ifdef UVM_AMAP_PPREF
> - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> - amap_pp_adjref(amap, slotoff + slotmapped, slotadd, 1);
> - }
> -#endif
> - return (0);
> - }
> -
> - /*
> - * case 2: we pre-allocated slots for use and we just need to
> - * bump nslot up to take account for these slots.
> - */
> - if (amap->am_maxslot >= slotneed) {
> -#ifdef UVM_AMAP_PPREF
> - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> - if ((slotoff + slotmapped) < amap->am_nslot)
> - amap_pp_adjref(amap, slotoff + slotmapped,
> - (amap->am_nslot - (slotoff + slotmapped)),
> - 1);
> - pp_setreflen(amap->am_ppref, amap->am_nslot, 1,
> -slotneed - amap->am_nslot);
> - }
> -#endif
> - amap->am_nslot = slotneed;
> - /*
> - * no need to zero am_anon since that was done at
> - * alloc time and we never shrink an allocation.
> - */
> - return (0);
> - }
> -
> - /*
> - * case 3: we need to malloc a new amap and copy all the amap
> - * data over from old amap to the new one.
> - *
> - * XXXCDC: could we take advantage of a kernel realloc()?
> - */
> - if (slotneed >= UVM_AMAP_LARGE)
> - return E2BIG;
> -
> - if (slotneed > UVM_AMAP_CHUNK)
> - slotalloc = malloc_roundup(slotneed * MALLOC_SLOT_UNIT) /
> - MALLOC_SLOT_UNIT;
> - else
> - slotalloc = slotneed;
> -
> -#ifdef UVM_AMAP_PPREF
> - newppref = NULL;
> - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> - newppref = mallocarray(slotalloc, sizeof(int), M_UVMAMAP,
> - M_WAITOK | M_CANFAIL);
> - if (newppref == NULL) {
> - /* give up if malloc fails */
> - free(amap->am_ppref, M_UVMAMAP, 0);
> - amap->am_ppref = PPREF_NONE;
> - }
> - }
> -
Re: multitouch support again
On 2016-03-24 22.34.12 +0100, Ulf Brosziewski wrote: > Are there any reviews, tests, OKs, or NOs pending? I'll add on to the list of: no regressions. I do not have the applicable harware to try the multitouch. (My status is unchanged: the touch screen works fine until suspend/resume, and then X treats it like a mouse instead of a touch screen.) -Mike
Re: use fast lookup in in6_pcbconnect()
On Wed, Mar 23, 2016 at 06:22:36PM +0100, Vincent Gross wrote:
> The current use of in_pcblookup() in in6_pcbconnect() is suboptimal :
> all of the addresses and ports are defined, we are only interested in
> exact matches, and its v4 cousin in_pcbconnect() already uses
> in_pcbhashlookup().
>
> Ok ?
OK bluhm@
>
> Index: sys/netinet6/in6_pcb.c
> ===
> RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 in6_pcb.c
> --- sys/netinet6/in6_pcb.c 23 Mar 2016 15:50:36 - 1.89
> +++ sys/netinet6/in6_pcb.c 23 Mar 2016 17:09:11 -
> @@ -304,9 +304,9 @@ in6_pcbconnect(struct inpcb *inp, struct
>
> inp->inp_ipv6.ip6_hlim = (u_int8_t)in6_selecthlim(inp);
>
> - if (in_pcblookup(inp->inp_table, &sin6->sin6_addr, sin6->sin6_port,
> + if (in6_pcbhashlookup(inp->inp_table, &sin6->sin6_addr, sin6->sin6_port,
> IN6_IS_ADDR_UNSPECIFIED(&inp->inp_laddr6) ? in6a : &inp->inp_laddr6,
> - inp->inp_lport, INPLOOKUP_IPV6, inp->inp_rtableid)) {
> + inp->inp_lport, inp->inp_rtableid)) {
> return (EADDRINUSE);
> }
Re: multitouch support again
On 25/03/16(Fri) 13:23, Ulf Brosziewski wrote: > Again, my mail client insisted on the "flowed" text format, > sorry. Here is a clean version of the diff. Tested with: pms0: Synaptics clickpad, firmware 8.0 In think this should go in, then we can polish it in-tree and wait for regression before converting mice. ok mpi@
[mm...@mykolab.com: Merge memleak fix from BoringSSL]
Does this look good? - Forwarded message from Michael McConville - Date: Sun, 20 Mar 2016 23:15:48 -0400 From: Michael McConville To: libre...@openbsd.org Subject: Merge memleak fix from BoringSSL Looks like it applies to us: https://boringssl.googlesource.com/boringssl/+/6b6e0b20893e2be0e68af605a60ffa2cbb0ffa64 Anecdotally, I need to check whether sk_X509_NAME_pop_free() are also NULL-safe for us, or if BoringSSL made that change. One way or the other, they removed their NULL checks. It's a little hard to confidently discern because they're at least triple-nested macros, but I'll have the time to spelunk eventually. Index: src/ssl/s3_clnt.c === RCS file: /cvs/src/lib/libssl/src/ssl/s3_clnt.c,v retrieving revision 1.137 diff -u -p -r1.137 s3_clnt.c --- src/ssl/s3_clnt.c 11 Mar 2016 07:08:45 - 1.137 +++ src/ssl/s3_clnt.c 21 Mar 2016 03:08:40 - @@ -1641,6 +1641,7 @@ ssl3_get_certificate_request(SSL *s) ERR_R_MALLOC_FAILURE); goto err; } + xn = NULL; /* avoid free in err block */ } /* we should setup a certificate to return */ @@ -1658,6 +1659,7 @@ truncated: SSL_R_BAD_PACKET_LENGTH); } err: + X509_NAME_free(xn); if (ca_sk != NULL) sk_X509_NAME_pop_free(ca_sk, X509_NAME_free); return (ret); - End forwarded message -
Re: uvm: remove unused(?) amap_extend
On 26/03/16(Sat) 19:19, Stefan Kempf wrote:
> Stefan Kempf wrote:
> > amap_extend is called when merging two adjacent areas of virtual address
> > space. However, merging is done only for kernel
> > virtual address space. It's not done for user space:
> >
> > uvm/uvm_map.c:1359
> > /*
> > * Try to merge entry.
> > *
> > * Userland allocations are kept separated most of the time.
> > * Forego the effort of merging what most of the time can't be merged
> > * and only try the merge if it concerns a kernel entry.
> > */
> > if ((flags & UVM_FLAG_NOMERGE) == 0 &&
> > (map->flags & VM_MAP_ISVMSPACE) == 0)
> > uvm_mapent_tryjoin(map, entry, &dead);
> >
> >
> > As far as I can tell, kernel vm_map_entries do not use amaps. So
> > amap_extend should never be called. Can we remove it?
>
> Any objections against committing this diff?
>
> Merging vm map entries for userspace was turned off a long time
> ago in r1.104 of uvm/uvm_map.c.
>
> The kernel doesn't use amaps either. Removing this would make the amap
> shrink diffs simpler.
If it should never happen, what about putting a KASSERT() rather than
returning NULL?
> > Index: uvm/uvm_amap.c
> > ===
> > RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
> > retrieving revision 1.62
> > diff -u -p -r1.62 uvm_amap.c
> > --- uvm/uvm_amap.c 16 Mar 2016 16:53:43 - 1.62
> > +++ uvm/uvm_amap.c 23 Mar 2016 17:03:53 -
> > @@ -279,174 +279,6 @@ amap_free(struct vm_amap *amap)
> > }
> >
> > /*
> > - * amap_extend: extend the size of an amap (if needed)
> > - *
> > - * => called from uvm_map when we want to extend an amap to cover
> > - *a new mapping (rather than allocate a new one)
> > - * => to safely extend an amap it should have a reference count of
> > - *one (thus it can't be shared)
> > - * => XXXCDC: support padding at this level?
> > - */
> > -int
> > -amap_extend(struct vm_map_entry *entry, vsize_t addsize)
> > -{
> > - struct vm_amap *amap = entry->aref.ar_amap;
> > - int slotoff = entry->aref.ar_pageoff;
> > - int slotmapped, slotadd, slotneed, slotalloc;
> > -#ifdef UVM_AMAP_PPREF
> > - int *newppref, *oldppref;
> > -#endif
> > - u_int *newsl, *newbck, *oldsl, *oldbck;
> > - struct vm_anon **newover, **oldover;
> > - int slotadded;
> > -
> > - /*
> > -* first, determine how many slots we need in the amap. don't
> > -* forget that ar_pageoff could be non-zero: this means that
> > -* there are some unused slots before us in the amap.
> > -*/
> > - AMAP_B2SLOT(slotmapped, entry->end - entry->start); /* slots mapped */
> > - AMAP_B2SLOT(slotadd, addsize); /* slots to add */
> > - slotneed = slotoff + slotmapped + slotadd;
> > -
> > - /*
> > -* case 1: we already have enough slots in the map and thus
> > -* only need to bump the reference counts on the slots we are
> > -* adding.
> > -*/
> > - if (amap->am_nslot >= slotneed) {
> > -#ifdef UVM_AMAP_PPREF
> > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > - amap_pp_adjref(amap, slotoff + slotmapped, slotadd, 1);
> > - }
> > -#endif
> > - return (0);
> > - }
> > -
> > - /*
> > -* case 2: we pre-allocated slots for use and we just need to
> > -* bump nslot up to take account for these slots.
> > -*/
> > - if (amap->am_maxslot >= slotneed) {
> > -#ifdef UVM_AMAP_PPREF
> > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > - if ((slotoff + slotmapped) < amap->am_nslot)
> > - amap_pp_adjref(amap, slotoff + slotmapped,
> > - (amap->am_nslot - (slotoff + slotmapped)),
> > - 1);
> > - pp_setreflen(amap->am_ppref, amap->am_nslot, 1,
> > - slotneed - amap->am_nslot);
> > - }
> > -#endif
> > - amap->am_nslot = slotneed;
> > - /*
> > -* no need to zero am_anon since that was done at
> > -* alloc time and we never shrink an allocation.
> > -*/
> > - return (0);
> > - }
> > -
> > - /*
> > -* case 3: we need to malloc a new amap and copy all the amap
> > -* data over from old amap to the new one.
> > -*
> > -* XXXCDC: could we take advantage of a kernel realloc()?
> > -*/
> > - if (slotneed >= UVM_AMAP_LARGE)
> > - return E2BIG;
> > -
> > - if (slotneed > UVM_AMAP_CHUNK)
> > - slotalloc = malloc_roundup(slotneed * MALLOC_SLOT_UNIT) /
> > - MALLOC_SLOT_UNIT;
> > - else
> > - slotalloc = slotneed;
> > -
> > -#ifdef UVM_AMAP_PPREF
> > - newppref = NULL;
> > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > - newppref = mallocarray(slotalloc, sizeof(int), M_UVMAMAP,
> > - M_WAITOK | M_CANFAIL);
> > -
Re: [mm...@mykolab.com: Merge memleak fix from BoringSSL]
On Sat, 26 Mar 2016 17:59:26 -0400, Michael McConville wrote: > Does this look good? OK millert@. X509_NAME_free() (really asn1_item_combine_free) just returns when passed a NULL pointer so this is safe. - todd
typo in fseek.3: "prefer seek()" -> "prefer fseek()"
ok? Index: lib/libc/stdio/fseek.3 === RCS file: /var/cvs/src/lib/libc/stdio/fseek.3,v retrieving revision 1.17 diff -u -p -r1.17 fseek.3 --- lib/libc/stdio/fseek.3 15 Mar 2016 19:45:57 - 1.17 +++ lib/libc/stdio/fseek.3 26 Mar 2016 22:04:54 - @@ -143,7 +143,7 @@ The .Fn rewind function returns no value. Prefer -.Fn seek , +.Fn fseek , which is just as portable, and does not hide errors. Upon successful completion, .Fn fgetpos ,
Re: typo in fseek.3: "prefer seek()" -> "prefer fseek()"
On Sat, Mar 26, 2016 at 11:09:54PM +0100, Theo Buehler wrote: > ok? Yes, makes sense. > Index: lib/libc/stdio/fseek.3 > === > RCS file: /var/cvs/src/lib/libc/stdio/fseek.3,v > retrieving revision 1.17 > diff -u -p -r1.17 fseek.3 > --- lib/libc/stdio/fseek.315 Mar 2016 19:45:57 - 1.17 > +++ lib/libc/stdio/fseek.326 Mar 2016 22:04:54 - > @@ -143,7 +143,7 @@ The > .Fn rewind > function returns no value. > Prefer > -.Fn seek , > +.Fn fseek , > which is just as portable, and does not hide errors. > Upon successful completion, > .Fn fgetpos , >
ART regression, multicast
With an ART kernel, programs using UPNP/DLNA (which use multicast) aren't working correctly. Sorry I don't have a simple test method, but it looks like outgoing packets aren't making it out to the network, and I'm not sure how to debug further. The best methods I can come up with are: 1. run minidlna (needs multicast=YES, set network_interface and add a media_dir entry in /etc/minidlna.conf, then start it) and point some client at it (for testing I'm using bubbleupnp on android, I've also used this with other clients). or 2. point tools from gupnp-tools at some media server (again bubbleupnp in android is useful here, while it's running it acts as a server as well as a client, or use minidlna on another machine). you can see devices easily with the X11 tools gupnp-universal-cp and gupnp-av-cp, again the multicast reject route mustn't be installed. (note, if you try running these while minidlna or some other program is already using the ports, it will fail). Route tables included for completeness, but I don't think there is any material difference between them. In this case I want the class D range routed to vlan5 rather than to my default route's destination so I have used "route add 224/4 -interface 10.15.5.2". netstat -rnfinet, ART kernel Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default82.68.199.142 UGS2 2213 - 8 vlan2 10.0.0/24 10.0.0.141 UC 10 - 4 vlan6 10.0.0.138 30:91:8f:9e:ad:8c UHLc 1 10 - 4 vlan6 10.0.0.141 f8:b1:56:ac:32:76 UHLl 04 - 1 vlan6 10.0.0.255 10.0.0.141 UHb00 - 1 vlan6 10.15.3/24 10.15.3.67 UC 32 - 4 trunk0 10.15.3.3 b0:b2:dc:63:18:4d UHLc 0 61 - 4 trunk0 10.15.3.4 90:f6:52:26:2a:89 UHLc 0 68 - 4 trunk0 10.15.3.5 5c:f4:ab:af:1c:36 UHLc 0 61 - 4 trunk0 10.15.3.67 f8:b1:56:ac:32:76 UHLl 0 1488 - 1 trunk0 10.15.3.25510.15.3.67 UHb00 - 1 trunk0 10.15.5/24 10.15.5.2 UC10 310 - 4 vlan5 10.15.5.1 00:00:5e:00:01:05 UHLc 0 605 - 4 vlan5 10.15.5.2 f8:b1:56:ac:32:76 UHLl 1 1853 - 1 vlan5 10.15.5.6 c4:01:7c:35:4a:50 UHLc 1 264 - 4 vlan5 10.15.5.10 24:a4:3c:7c:c0:87 UHLc 5 81 - 4 vlan5 10.15.5.13 04:4f:aa:0c:3a:e0 UHLc 0 343 - 4 vlan5 10.15.5.15 c0:3f:d5:6c:2d:64 UHLc 0 285 - 4 vlan5 10.15.5.16 00:0b:dc:00:5b:d3 UHLc 0 330 - 4 vlan5 10.15.5.25 48:44:f7:af:a7:d2 UHLc 0 253 - 4 vlan5 10.15.5.27 cc:fa:00:f3:d6:34 UHLc 0 27 - 4 vlan5 10.15.5.32 f8:b1:56:b0:df:e7 UHLc 0 76 - 4 vlan5 10.15.5.25400:25:90:c0:77:b4 UHLc 0 287 - 4 vlan5 10.15.5.25510.15.5.2 UHb2 125 - 1 vlan5 82.68.199.128/28 82.68.199.130 UC 4 241 - 4 vlan2 82.68.199.130 f8:b1:56:ac:32:76 UHLl 4 4615 - 1 vlan2 82.68.199.131 00:00:24:c2:e1:f8 UHLc 0 33 - 4 vlan2 82.68.199.132 00:0d:b9:14:30:ec UHLc 1 98 - 4 vlan2 82.68.199.137 00:04:13:23:26:6c UHLc 0 76 - 4 vlan2 82.68.199.142 00:25:90:c0:77:b4 UHLc 2 852 - 4 vlan2 82.68.199.143 82.68.199.130 UHb3 64 - 1 vlan2 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHl 3117460 32768 1 lo0 224/4 10.15.5.2 US 0 228 - 8 vlan5 .. same without ART. Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default82.68.199.142 UGS8 724 - 8 vlan2 10.0.0/24 10.0.0.141 UC 10 - 4 vlan6 10.0.0.138 30:91:8f:9e:ad:8c UHLc 13 - 4 vlan6 10.0.0.141 f8:b1:56:ac:32:76 UHLl 03 - 1 vlan6 10.0.0.255 10.0.0.141 UHb00 - 1 vlan6 10.15.3/24 10.15.3.67 UC 20 - 4 trunk0 10.15.3.3 b0:b2:dc:63:18:4d UHLc 01 - 4 trunk0 10.15.3.5 5c:f4:ab:af:1c:36 UHLc 01 - 4 trunk0 10.15.3.67 f8:b1:56:ac:32:76 UHLl 03 - 1 trunk0 10.15.3.25510.15.3.67 UHb00 - 1 trunk0 10.15.5/24 10.15.5.2 UC 6 232 - 4 vlan5 10.15.5.2
Re: ART regression, multicast
On 2016/03/26 23:21, Stuart Henderson wrote: > Sorry I don't have a simple test method, oh, there are some example programs in p5-IO-Socket-Multicast (in /usr/local/share/examples/p5-IO-Socket-Multicast), can't reboot again right now to test that they fail with ART, but they work ok without ART and it looks like they might be an easier way..just run server.pl on one box, client.pl on another.
Re: Scheduler hack for multi-threaded processes
Jyri Hovila [Turvamies.fi] writes:
> I can report significant usability improvement on a single core ThinkPad T42
> and a dual core ThinkPad X60.
>
I hate to crap on this wonderful parade, but on my T60 (i386, dmesg at
bottom) running 25 march snap the heat has bumped a full 10DegC from
what was "normal" before. I'm sorry for the lack of science here and
I have no hard numbers w/wo patch yet but in the past my steady state
on this machine w/o firefox was something like 70DegC, w/just some
xterms and emacs (aka life). Starting firefox generally added 10DegC
before I did anything at all and I always had to watch the heat and
kill firefox when we crossed 95DegC or Bad Things Happened; thus I
live with w3m in one hand and treat firefox as some kind of
luxury... tor-browser was, strangely, less hard on things but maybe
that's just because I never have too many tabs there (also, maybe
firefox-esr is a little lighter, not sure).
Now it will be a challenge to see if I can cvs up, back out the patch
and build a kernel without ringing the bell (100DegC). I freely admit
this is an old, P.O.S. laptop and that there might be some HW issue
(fan seems fine but I haven't taken it apart and really looked). It
does seem like the difference in the scheduler has a remarkable effect
on heat in my case.
Does anyone else see this?
> It's not just "the videos in Firefox" - everything works *so* much more
> fluently with the patch there's no way I would go back living without it.
It never occurs to me to try watching videos in firefox. I think I'm
just old.
> I know a hack is a hack and I know there are many unknowns there, but at
> least from the perspective of a "normal" OpenBSD desktop user, this patch is
> an absolute must.
>
> Let's not start a flame war here, just throwing in my five cents.
"Flame war" has added meaning in my case :-).
> Kudos to Martin.
>
> -j.
I appreciate all the great work as always. OpenBSD rules... and yes,
I need a new laptop.
Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
OpenBSD 5.9-current (GENERIC.MP) #1677: Fri Mar 25 14:19:24 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
real mem = 2145730560 (2046MB)
avail mem = 2092142592 (1995MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 03/21/11, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @
0xe0010 (68 entries)
bios0: vendor LENOVO version "79ETE7WW (2.27 )" date 03/21/2011
bios0: LENOVO 2008VRQ
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT
SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4)
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
halt), PSS
acpicpu1 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
halt), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4504" serial 41199 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000!
0xe/0x1!
cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Hos
Re: Scheduler hack for multi-threaded processes
On Sat, Mar 26, 2016 at 7:47 PM, attila wrote:
>
> Jyri Hovila [Turvamies.fi] writes:
>
>> I can report significant usability improvement on a single core ThinkPad T42
>> and a dual core ThinkPad X60.
>>
>
> I hate to crap on this wonderful parade, but on my T60 (i386, dmesg at
> bottom) running 25 march snap the heat has bumped a full 10DegC from
> what was "normal" before. I'm sorry for the lack of science here and
> I have no hard numbers w/wo patch yet but in the past my steady state
> on this machine w/o firefox was something like 70DegC, w/just some
> xterms and emacs (aka life). Starting firefox generally added 10DegC
> before I did anything at all and I always had to watch the heat and
> kill firefox when we crossed 95DegC or Bad Things Happened; thus I
> live with w3m in one hand and treat firefox as some kind of
> luxury... tor-browser was, strangely, less hard on things but maybe
> that's just because I never have too many tabs there (also, maybe
> firefox-esr is a little lighter, not sure).
>
> Now it will be a challenge to see if I can cvs up, back out the patch
> and build a kernel without ringing the bell (100DegC). I freely admit
> this is an old, P.O.S. laptop and that there might be some HW issue
> (fan seems fine but I haven't taken it apart and really looked). It
> does seem like the difference in the scheduler has a remarkable effect
> on heat in my case.
Could you not use # apm -L to set keep the CPU at its lowest frequency setting?
>
> Does anyone else see this?
>
>
>> It's not just "the videos in Firefox" - everything works *so* much more
>> fluently with the patch there's no way I would go back living without it.
>
> It never occurs to me to try watching videos in firefox. I think I'm
> just old.
>
>> I know a hack is a hack and I know there are many unknowns there, but at
>> least from the perspective of a "normal" OpenBSD desktop user, this patch is
>> an absolute must.
>>
>> Let's not start a flame war here, just throwing in my five cents.
>
> "Flame war" has added meaning in my case :-).
>
>> Kudos to Martin.
>>
>> -j.
>
> I appreciate all the great work as always. OpenBSD rules... and yes,
> I need a new laptop.
>
> Pax, -A
> --
> http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
>
>
>
> OpenBSD 5.9-current (GENERIC.MP) #1677: Fri Mar 25 14:19:24 MDT 2016
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class)
> 1.83 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
> real mem = 2145730560 (2046MB)
> avail mem = 2092142592 (1995MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 03/21/11, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @
> 0xe0010 (68 entries)
> bios0: vendor LENOVO version "79ETE7WW (2.27 )" date 03/21/2011
> bios0: LENOVO 2008VRQ
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT
> SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4)
> EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class)
> 1.83 GHz
> cpu1:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xf000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus 4 (EXP2)
> acpiprt5 at acpi0: bus 12 (EXP3)
> acpiprt6 at acpi0: bus 21 (PCI1)
> acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
> halt), PSS
> acpicpu1 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
> halt), PSS
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 99 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 model "42T4504" serial 41199 type LION oem "SANYO"
> acpibat1 at acpi0: BAT1 not present
> acpiac0 at acpi0: AC unit onl
