Re: Can not allocate memory for KERN_MSGBUF

On Fri, Jun 24, 2016 at 01:19:32PM +0200, Alexander Bluhm wrote: > On Fri, Jun 24, 2016 at 10:30:04AM +0200, Andreas Kusalananda K?h?ri wrote: > > I'm following -current on amd64, running in VirtualBox. I recompiled > > the kernel today with fresh sources, like I do a few times a week on > > slow

Re: Can not allocate memory for KERN_MSGBUF

On Fri, Jun 24, 2016 at 10:30:04AM +0200, Andreas Kusalananda K?h?ri wrote: > I'm following -current on amd64, running in VirtualBox. I recompiled > the kernel today with fresh sources, like I do a few times a week on > slow days. Have you also installed /usr/include/sys/msgbuf.h from

Medion Mobile S4222 works with umb(4)

Hi, just a short report that the "Medion Mobile S4222" UMTS stick (attached via USB) works fine with the new umb(4): umsm0 at uhub0 port 2 configuration 1 interface 0 "MediaTek Inc Product" rev 2.00/3.00 addr 10 umsm0 detached umb1 at uhub0 port 2 configuration 1 interface 0 "MediaTek Inc

Re: less progname in r

> From: "Ted Unangst" > Date: Thu, 23 Jun 2016 21:57:00 -0400 > > These programs don't do anything interesting based on progname, > except to echo is back to the user. If the user creates a link, is > it somehow more correct to print that name? I'd argue the original > name

opencvs - check len in rcsnum_setsize()

Hi, Since RCSNUM's rn_id array is limited to RCSNUM_MAXLEN it is very sensible to make sure rcsnum_setsize() protects against this. Index: rcsnum.c === RCS file: /cvs/src/usr.bin/cvs/rcsnum.c,v retrieving revision 1.57 diff -u -p

Can not allocate memory for KERN_MSGBUF

On Thu, Jun 23, 2016 at 07:15:21AM -0600, Alexander Bluhm wrote: > CVSROOT: /cvs > Module name: src > Changes by: bl...@cvs.openbsd.org 2016/06/23 07:15:21 > > Modified files: > sys/kern : subr_log.c > sys/sys: msgbuf.h > > Log message: > It is annoying that

Re: new feature in pkg_add(1)

On Thu, Jun 23, 2016 at 06:44:19AM +0200, Patrik Lundin wrote: > On Wed, Jun 22, 2016 at 02:19:26PM +0200, Marc Espie wrote: > > On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote: > > > The reason for doing this is that it is much faster than just blindly > > > trying to install a

[PATCH] small improvements to ftp(1)

Hi, The patch below implements the following changes to ftp(1), beginning with the least disruptive and ending with the most disruptive. 1) Change ftp->newer's behavior to match ftp->reget's behavior when stat(2) on the local file fails: do the file transfer from offset 0 instead of from

Re: Can not allocate memory for KERN_MSGBUF

This happens if kernel and the dmesg(8) userland program are out of sync. And yes, that can even happen for snapshots. Next snapshot should be ok again.

[patch] opencvs rcsnum_free()

Hi, If people are interested in opencvs diffs again, sharing a rcsnum_free()->free() clean-up item. Note that rcs(1) also has a version of rcsnum_free() which does more than simply call free(). - Michael Index: add.c === RCS

Re: less progname in r

Theo de Raadt wrote: > > I actually dislike how these programs behave when linked to. It is > rare. But it feels misleading somehow. Yes, I mentioned this in passing. It's somewhat contrived, but here's an example. $ cp /bin/ls ~/bin/ld $ ld -X ld: unknown option -- X usage: ld

Re: less progname in r

Mark Kettenis wrote: > > From: "Ted Unangst" > > Date: Thu, 23 Jun 2016 21:57:00 -0400 > > > > These programs don't do anything interesting based on progname, > > except to echo is back to the user. If the user creates a link, is > > it somehow more correct to print that

Re: less progname in r

> > Yes, although I think it's kind of mindless copying. This code doesn't > > benefit from progname. (Code that inspects argv[0] does benefit.) > > > > I doubt porting these programs is a high priority for anyone, but > > nevertheles I prefer standard code over nonstandard code. > > > > That

Re: less progname in r

On Fri, 24 Jun 2016 16:52:24 -0400, "Ted Unangst" wrote: > Yes, although I think it's kind of mindless copying. This code doesn't > benefit from progname. (Code that inspects argv[0] does benefit.) > > I doubt porting these programs is a high priority for anyone, but > nevertheles I prefer

path mtu discovery dynamic route

Hi, Path MTU discovery in IPv6 is slightly broken. I takes two ICMP6_PACKET_TOO_BIG packets to create and change the dynamic route. When the first ICMP6 packet arrives, a dynamic route gets created in icmp6_mtudisc_clone() and icmp6_mtudisc_update() sets its MTU value. During notify