> > I don't know if we recycle them somehow, but just in case...
> >
> > --- sys/sys/file.h
> > +++ sys/sys/file.h
> >
> ...
>
> > -#defineDTYPE_CRYPTO5 /* crypto */
> > +/* was define DTYPE_CRYPTO5 */
> >
>
> When it goes, this is the way to document it, yep.
>
> ...but y
On Mon, Aug 18, 2014 at 8:02 AM, Mike Belopuhov wrote:
> I don't know if we recycle them somehow, but just in case...
>
> --- sys/sys/file.h
> +++ sys/sys/file.h
>
...
> -#defineDTYPE_CRYPTO5 /* crypto */
> +/* was define DTYPE_CRYPTO5 */
>
When it goes, this is the way t
On Tue, Aug 19, 2014 at 8:00 AM, Visa Hankala wrote
>
> This patch corrects the process iterator in procfs_readdir(), allowing
> procfs root listing to work again. The iterator was stuck to the first
> instance of allprocess list because all the relevant LIST_NEXT()
> statements were mistakenly re
On 20 Aug 2014, at 11:53 am, David Gwynne wrote:
> can you fix this?
>
> Begin forwarded message:
>
>> From: David Gwynne
>> Subject: ftp, proxies, and https
>> Date: 20 August 2014 7:47:27 AEST
>> To: guent...@openbsd.org, js...@openbsd.org
>>
>> ola. do you guys have any idea how i could fi
jumbos seem find. nfs seems fine.
im going to put this and the other jalloc driver changes in to see what happens.
dlg
On 20 Aug 2014, at 7:41, Brad Smith wrote:
> On 19/08/14 2:19 PM, Brad Smith wrote:
>> On 18/08/14 6:24 PM, David Gwynne wrote:
>>> On Sun, Jul 13, 2014 at 02:01:15PM +1000, D
Hi Robert,
Robert Peichaer wrote on Wed, Aug 20, 2014 at 12:39:51AM +0200:
> In the "Base system daemon configuration variables" section, in the
> last paragraph this is incorrect.
>
> ... including a string containing only a single blank character, ...
>
> Looking at the _rc_parse_conf() code
this lets you have networks on the "native" vlan on an interface
at 1500, while setting a child vlan interfaces mtu to jumbos.
ok?
Index: if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.108
diff -u -p -r1.1
On Tue, Aug 19, 2014 at 10:44:54PM +0200, Ingo Schwarze wrote:
> Hi,
>
> while working on rcctl(8), i noticed that the rc.conf(8) manual
> is of... err, how can i express it politely... somewhat doubtful
> quality. Here is a stab at it.
>
> As a first step, i moved all the examples from the DE
On 2014/08/19 18:32, Tim Epkes wrote:
> Agree with once elected a DR he stays that way (eliminates a lot of
> bouncing). My issue was that both sides became FULL/OTHER.
I get this sometimes, usually after a link has gone away for a bit but
hasn't lost link, normally restarting ospfd on one router
Cool thanks.
On Tue, Aug 19, 2014 at 4:12 PM, Rafael Zalamena
wrote:
> On Tue, Aug 19, 2014 at 03:48:51PM -0400, Tim Epkes wrote:
> > All,
> >
> > I noticed in a few write-ups by Claudio that PWE3 and VPLS were next on
> the
> > roadmap. This seemed to be a few years ago. Any progress in that
Agree with once elected a DR he stays that way (eliminates a lot of
bouncing). My issue was that both sides became FULL/OTHER. I stopped all
and removed all router priorities and let them go default. When I brought
it all back up, most went FULL/OTHER on both sides so I got nothing. I am
using a
On 19/08/14 2:19 PM, Brad Smith wrote:
On 18/08/14 6:24 PM, David Gwynne wrote:
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just
annoying cos im pretty sure its sr optics with sc connectors.
thanks for testing.
how
On 20 Aug 2014, at 7:12 am, Stuart Henderson wrote:
> On 2014/08/20 07:06, David Gwynne wrote:
>> I think sthen is referring to the original diff Kettenis had in the tree a
>> few years ago.
>
> Yes - I just wanted to give ideas of things that might be worth testing
> that have been known to ca
On Tue, Aug 19, 2014 at 01:59:42AM +0200, Alexander Bluhm wrote:
> I will split this diff into smaller parts to make review and
> discussion easier.
Rename priv_gethostserv() to priv_getaddrinfo() as this is what the
function does. Change the return code semantics to match getaddrinfo(3).
ok?
b
On 2014/08/20 07:06, David Gwynne wrote:
> I think sthen is referring to the original diff Kettenis had in the tree a
> few years ago.
Yes - I just wanted to give ideas of things that might be worth testing
that have been known to cause problems on those NICs in the past
> On 20/08/2014 4:44 am,
I think sthen is referring to the original diff Kettenis had in the tree a
few years ago.
On 20/08/2014 4:44 am, "Brad Smith" wrote:
> On 19/08/14 2:43 PM, Stuart Henderson wrote:
>
>> From what I remember from last attempt to convert sk(4) to MCLGETI,
>> there were problems which only showed up
On 08/19/14 21:45, Tim Epkes wrote:
> All,
>
> I had implemented a network using openospf and initially left
> router-priorities off. Problem is I kept coming up FULL/OTHER and would
> not get routes. I changed the router priority values (not to match as when
> I matched got the same). I change
Hi,
while working on rcctl(8), i noticed that the rc.conf(8) manual
is of... err, how can i express it politely... somewhat doubtful
quality. Here is a stab at it.
As a first step, i moved all the examples from the DESCRIPTION to
the EXAMPLES esction. After that, the DESCRIPTION section was
b
On Tue, Aug 19, 2014 at 01:59:42AM +0200, Alexander Bluhm wrote:
> I will split this diff into smaller parts to make review and
> discussion easier.
Replace gethostbyaddr(3) with getnameinfo(3).
Note that I remove the sigprocmask() that was added in rev 1.23
before privsep. It was necessary beca
On Tue, Aug 19, 2014 at 03:48:51PM -0400, Tim Epkes wrote:
> All,
>
> I noticed in a few write-ups by Claudio that PWE3 and VPLS were next on the
> roadmap. This seemed to be a few years ago. Any progress in that regard?
> Is their a page that tracks that status? Very interested, Thanks
>
> T
All,
I noticed in a few write-ups by Claudio that PWE3 and VPLS were next on the
roadmap. This seemed to be a few years ago. Any progress in that regard?
Is their a page that tracks that status? Very interested, Thanks
Tim
All,
I had implemented a network using openospf and initially left
router-priorities off. Problem is I kept coming up FULL/OTHER and would
not get routes. I changed the router priority values (not to match as when
I matched got the same). I changed one side of a line to 10, while the
other was
On 19/08/14 2:43 PM, Stuart Henderson wrote:
From what I remember from last attempt to convert sk(4) to MCLGETI,
there were problems which only showed up under load (possibly also involved
NFS, I don't remember for sure) - I probably used netrate with something like
"netblast 11.22.33.44 12345 1
>From what I remember from last attempt to convert sk(4) to MCLGETI,
there were problems which only showed up under load (possibly also involved
NFS, I don't remember for sure) - I probably used netrate with something like
"netblast 11.22.33.44 12345 1 30" to generate a bunch of packets over it
qui
On 18/08/14 6:24 PM, David Gwynne wrote:
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just annoying cos
im pretty sure its sr optics with sc connectors.
thanks for testing.
how's this one?
Only running regular MTU
2014-08-18 9:23 GMT+04:00 Kent R. Spillner :
> Haven't tested, just eyeballing the diff; I have two questions inline
> below.
> 1). Did you want to use proglen here?
Yep, good catch, thanks!
> 2). proglen is declared as an int; is there any danger malicious
> values could cause an overflow, or ar
Hello,
This patch corrects the process iterator in procfs_readdir(), allowing
procfs root listing to work again. The iterator was stuck to the first
instance of allprocess list because all the relevant LIST_NEXT()
statements were mistakenly removed in revision 1.58 of procfs_vnops.c.
Regards,
Vis
When the procfs root directory is listed using more than one getdents()
call, the process iterator can mistakenly skip a few processes. The
patch corrects this by making the index of the first process entry match
with the static procfs entries. This prevents over-winding of the
process list during
2014-08-19 14:19 GMT+04:00 Reyk Floeter :
> On Fri, Aug 15, 2014 at 09:35:03PM +0400, Vadim Zhukov wrote:
>> The SIOCG80211ALLNODES operate on struct ieee80211_nodereq_all, not
>> on struct ieee80211_nodereq, right? If I understand things correctly,
>> we were on a safe side because struct ieee8021
On Fri, Aug 15, 2014 at 09:35:03PM +0400, Vadim Zhukov wrote:
> The SIOCG80211ALLNODES operate on struct ieee80211_nodereq_all, not
> on struct ieee80211_nodereq, right? If I understand things correctly,
> we were on a safe side because struct ieee80211_nodereq is larger
> than struct ieee80211_nod
30 matches
Mail list logo
