Re: erroneous message from locked-up machine

Can someone please elaborate on the acronym KVA ?

$ sysctl -d kern.ipc.maxpipekva
kern.ipc.maxpipekva: Pipe KVA limit

This doesn't tell me enough.

 - aW



	On Tue, Nov 11, 2003 at 04:46:47AM +1100, Bruce Evans wrote:

	> > I came in to work today to find one of my -current machines unable to
	> > open a pipe.  (This probably had a lot to do with the spamd that went
	> > stark raving nutters overnight, but that's a separate problem.)  A
	> > power cycle fixed the problem, but /var/log/messages was filled with:
	> >
	> > Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7).
	> >
	> > Interesting.
	> >
	> > bewilderbeast~;sysctl kern.maxpipekva
	> > sysctl: unknown oid 'kern.maxpipekva'
	> > bewilderbeast~;
	> 
	> The following patch fixes this and some nearby style bugs:
	> - source style bug: line too line
	> - output style bugs: comma splice, verboseness (helps make the source line
	>   too long), and kernel message terminated with a ".".
	> 
	> %%%
	> Index: sys_pipe.c
	> ===================================================================
	> RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
	> retrieving revision 1.158
	> diff -u -2 -r1.158 sys_pipe.c
	> --- sys_pipe.c	9 Nov 2003 09:17:24 -0000	1.158
	> +++ sys_pipe.c	10 Nov 2003 17:21:47 -0000
	> _at__at_ -331,5 +331,5 _at__at_
	>  	if (error != KERN_SUCCESS) {
	>  		if (ppsratecheck(&lastfail, &curfail, 1))
	> -			printf("kern.maxpipekva exceeded, please see tuning(7).\n");
	> +			printf("kern.ipc.maxpipekva exceeded; see tuning(7)\n");
	>  		return (ENOMEM);
	>  	}
	> %%%
	> 
	> > And tuning(7) doesn't mention this, either.
	> >
	> > Is this just work-in-progress, or did someone forget to commit something?
	> 
	> Seems like tuning pipe kva is completely absent in tuning(7) (so the above
	> message can be shortened further).  You can tune kva generally as documented
	> there, but the pipe limit is separate.
	> 
	> > PS: Lesson of the day: no pipe KVA, no su.  Great fun on remote
	> > machines!  :-)
	> 
	> It's interesting that su was the point of failure.  It uses a pipe hack
	> for IPC.  Otherwise it doesn't use pipes, at least direectly.  It
	> shouldn't need to use the pipe hack.  My version uses signals instead.