[PATCH] ksh: Fail gracefully if sethistsize() fails

This can be hard to debug, and could indeed prevent debugging, since it can take out the ability to run /bin/sh, depending on how you've set up your environment. Before: $ HISTSIZE=10 /bin/sh /bin/sh: internal error: unable to allocate memory <--- no ksh With this pa $

Re: ifconfig compiler warnings

Alexander Bluhm(alexander.bl...@gmx.net) on 2019.10.17 16:23:32 +0200: > Hi, > > I would like to fix some warings in ifconfig when compiled with > WARNINGS=yes. > > - Move all prototypes and variables used in multiple .c files into > common ifconfig.h. Basically rename brconfig.h to

Re: ifTypes, if_data->if_type, conflicts and too small

Hi, On 18/10/2019 17:19, Theo de Raadt wrote: >> 3. Track down all the places that this might be used, and make sure they >> are also changed to handle a u_int32_t. > > Gigantic ABI breakage. > > Hope you have fun upgrading bsd, ifconfig, and other tools through that > change. Yeah, I didn't

Re: ifTypes, if_data->if_type, conflicts and too small

> This presents another problem because the if_type member of the if_data > struct is defined as a u_char and so the type I've been assigned isn't > even going to fit. Riight. > 3. Track down all the places that this might be used, and make sure they > are also changed to handle a u_int32_t.

ifTypes, if_data->if_type, conflicts and too small

Hi, For context: I'm currently working on a patch set for OpenBSD that adds support for AX.25 network interfaces. Constants for interface types are defined in based on the IANA registry for ifTypes maintained as: https://www.iana.org/assignments/ianaiftype-mib As the bottom of this file, we

Re: OpenBSD 6.x and wxallowed

Nelson H. F. Beebe wrote: > If only a small number of packages need W^X capability, would it make > sense to create a separate file tree for them, and let every other > part of the filesystem enjoy W^X protection, along with additional > security from addition of pledge() and veil() promises

Re: OpenBSD 6.x and wxallowed

On Fri, Oct 18, 2019 at 07:39:26AM -0600, Nelson H. F. Beebe wrote: > Because I dislike splitting disks into numerous partitions, each of > whose sizes is a future show-stopper when they prove too small, I > generally split disks into just root + swap. Thus, I find on our > currently 7 versions

Re: xhci(4): fix endless loop when transfer is aborted

On 18/10/19(Fri) 14:55, Stefan Sperling wrote: > On Fri, Oct 18, 2019 at 12:54:06PM +0200, Stefan Sperling wrote: > > On Fri, Oct 18, 2019 at 11:37:01AM +0200, Martin Pieuchot wrote: > > > The question here is how an `xfer' with a status of NORMAL_COMPLETION > > > can be found in the pipe's queue?

Re: OpenBSD 6.x and wxallowed

On Fri, Oct 18, 2019 at 07:39:26AM -0600, Nelson H. F. Beebe wrote: > Because I dislike splitting disks into numerous partitions, each of > whose sizes is a future show-stopper when they prove too small, I > generally split disks into just root + swap. > If only a small number of packages need

OpenBSD 6.x and wxallowed

Because I dislike splitting disks into numerous partitions, each of whose sizes is a future show-stopper when they prove too small, I generally split disks into just root + swap. Thus, I find on our currently 7 versions of OpenBSD 6.x in our test farm reports like this: # mount

Re: mbuf limit atomic operation

On Fri, Oct 18, 2019 at 03:55:39PM +1000, David Gwynne wrote: > why? is it significantly faster? page allocation should be in the slow path. At least it was not slower. Performance were slightly higher, but changes are well below meassurement tolerance. Usually it is a good idea to avoid locks

Re: xhci(4): fix endless loop when transfer is aborted

On Fri, Oct 18, 2019 at 12:54:06PM +0200, Stefan Sperling wrote: > On Fri, Oct 18, 2019 at 11:37:01AM +0200, Martin Pieuchot wrote: > > The question here is how an `xfer' with a status of NORMAL_COMPLETION > > can be found in the pipe's queue? > > I don't know yet. I have managed to track it

Re: xhci(4): fix endless loop when transfer is aborted

On Fri, Oct 18, 2019 at 11:37:01AM +0200, Martin Pieuchot wrote: > The question here is how an `xfer' with a status of NORMAL_COMPLETION > can be found in the pipe's queue? I don't know yet. Here is some output with usbdebug = 6. The error handling starts at line "xhci0: txerr? code 4" and

Re: netstart diff for aggr(4) handling

On Thu, Oct 17, 2019 at 11:24:24PM +0200, Alexander Bluhm wrote: > On Thu, Oct 17, 2019 at 04:47:27PM -0400, Brad Smith wrote: > > Shouldn't aggr(4) be handled in the same manner as trunk(4)? > > I guess so, OK bluhm@ +1 OK claudio > > Index: netstart > >

Re: xhci(4): fix endless loop when transfer is aborted

On 17/10/19(Thu) 18:53, Stefan Sperling wrote: > My USB scanner works again in 6.6 \o/ > Thanks to whoever fixed it. I have no idea when and how it happened but > since a few releases back it has always been failed with some I/O error. > But now it just works again as it once did (apart from a

Re: probable error in 66.html regarding rpki-client

I'm not sure it matters. The text is not invalid. It was imported into the tree. It just didn't ship a binary. > On Wed, Oct 16, 2019 at 09:34:26PM -0600, Theo de Raadt wrote: > > Ross L Richardson wrote: > > > > > 66.html claims that rpki-client is included, but: > > > -

Re: probable error in 66.html regarding rpki-client

On Wed, Oct 16, 2019 at 09:34:26PM -0600, Theo de Raadt wrote: > Ross L Richardson wrote: > > > 66.html claims that rpki-client is included, but: > > - gives no result. > > - The test system I just sysupgraded doesn't have it. > > > > It's not actually

[PATCH] www - 66.html - fix a typo - aggregation

Hello, ... and a small typo. Raf Index: 66.html === RCS file: /cvs/www/66.html,v retrieving revision 1.72 diff -u -p -r1.72 66.html --- 66.html 17 Oct 2019 13:49:28 - 1.72 +++ 66.html 18 Oct 2019 06:18:22 - @@

[PATCH] www - 66.html - fix a broken link to relayd(8) man page

Hi, The URL to the relayd(8) manual page is incomplete. Regards, Raf Index: 66.html === RCS file: /cvs/www/66.html,v retrieving revision 1.72 diff -u -p -r1.72 66.html --- 66.html 17 Oct 2019 13:49:28 - 1.72 +++