Re: manpage text width

2018-03-29 Thread Ingo Schwarze
Hi Paul, Theo de Raadt wrote on Thu, Mar 29, 2018 at 04:17:14PM -0600: > piroft@ wrote: >> Is there any reason why manpage text does not resize nicely >> with <80 columns xterms? I want to avoid excessive magic. By the way, actually, the default width is 78, not 80. By tradition. >> Is it

Re: kqueue EV_DISPATCH and EV_EOF interaction

2018-03-29 Thread Mike Belopuhov
On Fri, Mar 30, 2018 at 01:21 +0200, Mike Belopuhov wrote: > > Hi, > > This appears to be an issue with reactivating disabled event sources > in kqueue_register. Something along the lines of FreeBSD commits: > > https://svnweb.freebsd.org/base?view=revision=274560 and >

Re: kqueue EV_DISPATCH and EV_EOF interaction

2018-03-29 Thread Mike Belopuhov
On Thu, Mar 29, 2018 at 15:09 +0200, Lukas Larsson wrote: > Hello, > > I've been re-writing the polling mechanisms in the Erlang VM and stumbled > across > something that might be a bug in the OpenBSD implementation of kqueue. > > When using EV_DISPATCH, the event is never triggered again after

Re: manpage text width

2018-03-29 Thread Theo de Raadt
> Is there any reason why manpage text does not resize nicely with <80 > columns xterms? Is it because of less(1)? Can I do anything to fix this? It is pre-formatted.

manpage text width

2018-03-29 Thread Paul Irofti
Hi, Is there any reason why manpage text does not resize nicely with <80 columns xterms? Is it because of less(1)? Can I do anything to fix this? Thanks, Paul

return packets may not be desired to be scrubbed

2018-03-29 Thread Peter J. Philipp
Hi, While writing my own patches to the OpenBSD kernel and the pf subsystem, I noticed that random-id packets scrub twice. I noticed this by copying random-id's code and modifying it a little. From that grew a little patch for scrub and random-id and I'd like OpenBSD to consider it. I sent a

Re: NFS vs NET_LOCK()

2018-03-29 Thread Visa Hankala
On Thu, Mar 29, 2018 at 11:57:42AM +0200, Martin Pieuchot wrote: > On 28/03/18(Wed) 16:09, Visa Hankala wrote: > > On Wed, Mar 28, 2018 at 11:59:46AM +0200, Martin Pieuchot wrote: > > > Index: uvm/uvm_vnode.c > > > === > > > RCS file:

Re: NFS vs NET_LOCK()

2018-03-29 Thread Martin Pieuchot
On 28/03/18(Wed) 16:09, Visa Hankala wrote: > On Wed, Mar 28, 2018 at 11:59:46AM +0200, Martin Pieuchot wrote: > > Index: uvm/uvm_vnode.c > > === > > RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v > > retrieving revision 1.99 > > diff -u -p

Re: sparc64 softraid boot: workaround for memory leak

2018-03-29 Thread Mike Larkin
On Thu, Mar 29, 2018 at 09:21:16AM +0200, Mark Kettenis wrote: > > Date: Wed, 28 Mar 2018 23:46:49 -0700 > > From: Mike Larkin > > > > On Thu, Mar 29, 2018 at 08:40:27AM +0200, Stefan Sperling wrote: > > > On Mon, Mar 12, 2018 at 11:38:14AM +0100, Stefan Sperling wrote: > >

Re: sparc64 softraid boot: workaround for memory leak

2018-03-29 Thread Mark Kettenis
> Date: Wed, 28 Mar 2018 23:46:49 -0700 > From: Mike Larkin > > On Thu, Mar 29, 2018 at 08:40:27AM +0200, Stefan Sperling wrote: > > On Mon, Mar 12, 2018 at 11:38:14AM +0100, Stefan Sperling wrote: > > > I haven't had any feedback on the previous diff. However, I felt it >

Re: sparc64 softraid boot: workaround for memory leak

2018-03-29 Thread Mark Kettenis
> From: Stefan Sperling > > On Mon, Mar 12, 2018 at 11:38:14AM +0100, Stefan Sperling wrote: > > I haven't had any feedback on the previous diff. However, I felt it > > was a bit of a hack, so I tried to come up with a cleaner solution. > > Anyone? Can this go in now? I hope to

Re: sparc64 softraid boot: workaround for memory leak

2018-03-29 Thread Mike Larkin
On Thu, Mar 29, 2018 at 08:40:27AM +0200, Stefan Sperling wrote: > On Mon, Mar 12, 2018 at 11:38:14AM +0100, Stefan Sperling wrote: > > I haven't had any feedback on the previous diff. However, I felt it > > was a bit of a hack, so I tried to come up with a cleaner solution. > > Anyone? Can this

Re: sparc64 softraid boot: workaround for memory leak

2018-03-29 Thread Stefan Sperling
On Mon, Mar 12, 2018 at 11:38:14AM +0100, Stefan Sperling wrote: > I haven't had any feedback on the previous diff. However, I felt it > was a bit of a hack, so I tried to come up with a cleaner solution. Anyone? Can this go in now? I hope to get this tested across many sparc64 machines during

Re: xhci@fdt; legacy binding support

2018-03-29 Thread Jonathan Gray
On Wed, Mar 28, 2018 at 12:05:54PM +0200, Mark Kettenis wrote: > The Marvell Aramada device trees use a legacy binding for the XHCI USB > PHY. This diff adds support for this misfeature as fixing the device > trees may take a while. It also adds support for the "usb-nop-xceiv" > PHY type, which