Re: Add / Amend history info for some utilities in /bin

It appears the goal here is to be accurate regarding minor amusing documentation details. That's good, the same detailing will reflects in code as well. Well, then don't send a diff alone. Provide all the proof. History is complicated and full of gaps. By providing the full proof, the maximum

Re: bigger mbuf clusters for sosend()

> On 18 Aug 2016, at 08:49, Alexander Bluhm wrote: > > On Wed, Aug 17, 2016 at 09:21:21PM +0200, Claudio Jeker wrote: >> On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote: >>> As I understand, we are hitting the global mbuf cluster limit. I >>> don't see

Re: bigger mbuf clusters for sosend()

On Wed, Aug 17, 2016 at 09:21:21PM +0200, Claudio Jeker wrote: > On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote: > > As I understand, we are hitting the global mbuf cluster limit. I > > don't see how a changed pool wakeup policy could fix this hang. > > > > Choose your poision.

small patch for relayd.conf.5

Hi I think there is a small mistake in relayd.conf.5. Remi Index: relayd.conf.5 === RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v retrieving revision 1.170 diff -u -p -r1.170 relayd.conf.5 --- relayd.conf.5 29 Jul 2016

Re: Add / Amend history info for some utilities in /bin

Hi Sevan, Sevan Janiyan Solaris wrote on Wed, Aug 17, 2016 at 09:32:54PM +0100: > On 16/08/2016 20:03, Ingo Schwarze wrote: >> Not (yet?) committed. Can you explain why you think that it >> appeared in version 1? > Appologies Ingo, I made a mistake here, I was using the snippet of code > set

Re: ld.so initarray support

On Wed, 17 Aug 2016, Mark Kettenis wrote: ... > Functions listed by DT_PREINIT_ARRAY get run immediately after ld.so has > finished loading and relocating all shared objects. This happens only > for the main executable. The _dl_call_init() invocation in dlopen() needs to change too, or

Re: pid for RTM_ADD

> > > Index: net/if.h > > > === > > > RCS file: /cvs/openbsd/src/sys/net/if.h,v > > > retrieving revision 1.177 > > > diff -u -p -u -p -r1.177 if.h > > > --- net/if.h 10 Jun 2016 20:33:29 - 1.177 > > > +++ net/if.h

Re: pid for RTM_ADD

On Wed, Aug 17, 2016 at 10:39:51AM +0100, Stuart Henderson wrote: > On 2016/08/17 10:11, Peter Hessler wrote: > > It sure would be nice if we could see the PID of the process that added > > routes. Heck, route(8) even tries to print them already. > > > > Add the fields to the appropriate struct,

cwm(1): Enable numpad Enter on menus

Hi, This is a tiny patch to enable the use of numpad Enter key on cwm menus. __ Regards, Henrique N. Lengler Index: menu.c === RCS file: /cvs/xenocara/app/cwm/menu.c,v retrieving revision 1.90 diff -u -p -r1.90 menu.c --- menu.c

Re: bigger mbuf clusters for sosend()

On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote: > On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote: > > the reason is that pools now keep track of things that are sleeping > > for memory and will give them an item BEFORE waking them up. > > previously i believe they

ld.so initarray support

The diff below adds support for DT_PREINIT_ARRAY, DT_INIT_ARRAY and DT_FINI_ARRAY to our ld.so. The idea is that these tags each point to a list of function pointers that get executed at initialization and termination time. Functions listed by DT_PREINIT_ARRAY get run immediately after ld.so has

Re: bigger mbuf clusters for sosend()

On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote: > On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote: > > the reason is that pools now keep track of things that are sleeping > > for memory and will give them an item BEFORE waking them up. > > previously i believe they

Re: Enable FIFO Synopsis DesignWare APB UART

> Date: Wed, 17 Aug 2016 15:36:21 +0200 > From: Marcus Glocker > > Enables FIFO for Synopsis DesignWare APB UART. > > ok? Apparently the FIFO is optional. There is a register that tells you whether it is enabled or not. Not sure we'll ever encounter an implementation that

Re: Skip double FIFO probing in com(4)

> Date: Wed, 17 Aug 2016 15:38:39 +0200 > From: Marcus Glocker > > If a FIFO device already got a FIFO depth assigned, don't run a FIFO > probe against it. > > ok? Sorry, but no. As far as I understand, the FIFO probe was added to detect buggy 16550 versions that implement a

Re: [PATCH] fix mbuf leak in uicp_usrreq.c

On Wed, Aug 17, 2016 at 10:01:16AM +0200, Simon Mages wrote: > I think the following diff fixes this problem by handly the error correctly. Commited, thanks. > > Index: kern/uipc_usrreq.c > === > RCS file:

Skip double FIFO probing in com(4)

If a FIFO device already got a FIFO depth assigned, don't run a FIFO probe against it. ok? Index: dev/ic/com.c === RCS file: /cvs/src/sys/dev/ic/com.c,v retrieving revision 1.159 diff -u -p -r1.159 com.c --- dev/ic/com.c16

Enable FIFO Synopsis DesignWare APB UART

Enables FIFO for Synopsis DesignWare APB UART. ok? Index: arch/armv7/dev/com_fdt.c === RCS file: /cvs/src/sys/arch/armv7/dev/com_fdt.c,v retrieving revision 1.5 diff -u -p -r1.5 com_fdt.c --- arch/armv7/dev/com_fdt.c17 Aug 2016

Re: iwm: make use of RTS/CTS conditional

Did anyone test this? On Wed, Jul 20, 2016 at 02:48:02PM +0200, Stefan Sperling wrote: > Currently, if running in 11n mode, iwm always enables RTS/CTS to protect > frames it is sending. > > To recap what the various HT protection modes are: > > /* > * HT protection modes (see 802.11-2012

Re: iwm driver in latest snapshot has terrible performance

On Sun, Jul 31, 2016 at 05:26:21PM +0200, Noth wrote: > Now testing with a July 17th kernel, everything works fine at .11n speeds > but the ping goes from 1ms to 100+ms for one packet on average every 50-60 > packets. Can you pin-point the iwm commit which changed this?

Re: bigger mbuf clusters for sosend()

On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote: > the reason is that pools now keep track of things that are sleeping > for memory and will give them an item BEFORE waking them up. > previously i believe they were woken up to try and get an item, > which could fail as you described

Re: ral(4) support RT5390 and RT5392

On Tue, Aug 16, 2016 at 05:34:20PM -0400, James Hastings wrote: > On 8/16/16, Stefan Sperling wrote: > > > > Your patch can't be applied with patch(1) because directory > > components are missing on the Index: lines even though modified > > files are spread across several

Re: per cpu memory in the kernel

On Wed, Aug 17, 2016 at 09:13:04PM +1000, David Gwynne wrote: > On Wed, Aug 17, 2016 at 08:27:19PM +1000, David Gwynne wrote: > > On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > > > ive been tinkering with per cpu memory in the kernel. > > > > mpi@ wanted to see another example of

Re: bigger mbuf clusters for sosend()

On Wed, Aug 17, 2016 at 01:43:00PM +0200, Alexander Bluhm wrote: > On Sat, Aug 13, 2016 at 10:59:30AM +0200, Claudio Jeker wrote: > > to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in > > the same function. I see no point in not waiting for a cluster and instead > > chain

Re: bigger mbuf clusters for sosend()

On Sat, Aug 13, 2016 at 10:59:30AM +0200, Claudio Jeker wrote: > to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in > the same function. I see no point in not waiting for a cluster and instead > chain lots of mbufs together as a consequence. The M_WAIT reverts this bugfix:

Re: per cpu memory in the kernel

On Wed, Aug 17, 2016 at 08:27:19PM +1000, David Gwynne wrote: > On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > > ive been tinkering with per cpu memory in the kernel. > > mpi@ wanted to see another example of moving something to per cpu counters > and challenged me to do

Re: bigger mbuf clusters for sosend()

> On 17 Aug 2016, at 5:23 PM, Simon Mages wrote: > > Hi, > > this diff works for me. > > I tested TCP and Unix Domain Sockets. I did no performance tests though. > > I like this version better then the one i was working with, it really > is easier to read. cool.

Re: per cpu memory in the kernel

On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > ive been tinkering with per cpu memory in the kernel. mpi@ wanted to see another example of moving something to per cpu counters and challenged me to do tcpstat. the diff below does that, but with a couple of warts. firstly, it

Re: [PATCH] fix mbuf leak in uicp_usrreq.c

On 17 August 2016 at 10:01, Simon Mages wrote: > Hi, > > while i was debugging dlg@'s diff regarding the bigger mbuf clusters i > stumbled > across a bug in the PRU_SEND case in uicp_usrreq.c. > > There is a call to sbappendcontrol which can fail, but there is no >

Re: pid for RTM_ADD

On 2016 Aug 17 (Wed) at 10:39:51 +0100 (+0100), Stuart Henderson wrote: :On 2016/08/17 10:11, Peter Hessler wrote: :> It sure would be nice if we could see the PID of the process that added :> routes. Heck, route(8) even tries to print them already. :> :> Add the fields to the appropriate

Re: finer grained art locking again

On Mon, Aug 15, 2016 at 10:08:16PM +1000, Jonathan Matthew wrote: > This removes ART's reliance on the kernel lock to serialise updates. > I sent out an earlier version of this prior to 6.0, but it didn't make it in. > Since then, we've decided to go with rwlocks in the packet processing path, >

Re: pid for RTM_ADD

On 2016/08/17 10:11, Peter Hessler wrote: > It sure would be nice if we could see the PID of the process that added > routes. Heck, route(8) even tries to print them already. > > Add the fields to the appropriate struct, and while here, document which > fields are in sync. > > (requested by

pid for RTM_ADD

It sure would be nice if we could see the PID of the process that added routes. Heck, route(8) even tries to print them already. Add the fields to the appropriate struct, and while here, document which fields are in sync. (requested by krw@) OK? Index: net/if.h

[PATCH] fix mbuf leak in uicp_usrreq.c

Hi, while i was debugging dlg@'s diff regarding the bigger mbuf clusters i stumbled across a bug in the PRU_SEND case in uicp_usrreq.c. There is a call to sbappendcontrol which can fail, but there is no error handling done. If sbappendcontrol fails m will be set to NULL, which just leaks this

Re: bigger mbuf clusters for sosend()

Hi, this diff works for me. I tested TCP and Unix Domain Sockets. I did no performance tests though. I like this version better then the one i was working with, it really is easier to read. For completeness follows the diff i was using: Index: kern/uipc_socket.c