Hi,
I just started using OpenBSD's ospfd.
1. I would like to have a direct Ethernet link
between OpenBSD box and Cisco/Juniper router.
I would like to specify the link type as point to point.
Which configuration directive I have to use ?.
2. I would like to use SHA1/SHA2 Message digest
Hello -
I believe this is correct.
After mikeb@ committed destroying cloneable interfaces under
splsoftnet, these aren't needed anymore.
Index: if_mpe.c
===
RCS file: /cvs/src/sys/net/if_mpe.c,v
retrieving revision 1.54
diff -u -p
On Tue, Sep 20, 2016 at 02:35:18AM +0200, Stefan Sperling wrote:
> I'd like to know if this diff helps with iwm(4) performance issues
> some people have been reporting.
>
> This is not done yet and some details don't really make sense, especially
> the #if 0 hiding of what should be correct code
Without this diff src.db is installed as the build user when makeing a
noperm release. is required for BINOWN/BINGRP. Ok?
natano
Index: Makefile
===
RCS file: /cvs/src/distrib/sets/Makefile,v
retrieving revision 1.1
diff -u -p
When processing an ADDBA request, iwm(4) runs a task which sends a
command to the firmware and waits for confirmation. This command can
fail and there's currently no way we can recover from such an error.
With the diff below, drivers can return EBUSY from their ic_ampdu_rx_start()
handler which
Ping. Ok?
On Sat, Sep 10, 2016 at 10:16:20PM +0200, Martin Natano wrote:
> Another diff I typoed, also found by rpe@. Ok?
>
> Index: share/misc/pcvtfonts/Makefile
> ===
> RCS file: /cvs/src/share/misc/pcvtfonts/Makefile,v
>
On Tue, Sep 20, 2016 at 11:08 AM, Mark Kettenis wrote:
> So my diff that switched libunwind to use dl_unwind_find_exidx() was
> incomplete. I forgot that I had put its prototype in and
> missed that file when generating the diff. However, isn't
> really the right
So my diff that switched libunwind to use dl_unwind_find_exidx() was
incomplete. I forgot that I had put its prototype in and
missed that file when generating the diff. However, isn't
really the right place to put the prototype. We have
dl_iterate_phdr() in , and dl_unwind_find_exidx() is
On Tue, Sep 20, 2016 at 17:20 +0200, Martin Pieuchot wrote:
> On 20/09/16(Tue) 17:04, Mike Belopuhov wrote:
> > On Tue, Sep 20, 2016 at 10:51 -0400, David Hill wrote:
> > > On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > > > More...
> > > >
> > > > splassert: sorwakeup: want 5
On 20 September 2016 at 17:09, Martin Pieuchot wrote:
> On 20/09/16(Tue) 10:51, David Hill wrote:
>> On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
>> > More...
>> >
>> > splassert: sorwakeup: want 5 have 0
>> > Starting stack trace...
>> > splassert_check() at
On 20/09/16(Tue) 17:04, Mike Belopuhov wrote:
> On Tue, Sep 20, 2016 at 10:51 -0400, David Hill wrote:
> > On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > > More...
> > >
> > > splassert: sorwakeup: want 5 have 0
> > > Starting stack trace...
> > > splassert_check() at
On Tue, Sep 20, 2016 at 05:04:02PM +0200, Mike Belopuhov wrote:
> On Tue, Sep 20, 2016 at 10:51 -0400, David Hill wrote:
> > On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > > More...
> > >
> > > splassert: sorwakeup: want 5 have 0
> > > Starting stack trace...
> > >
On Tue, Sep 20, 2016 at 05:09:41PM +0200, Martin Pieuchot wrote:
> On 20/09/16(Tue) 10:51, David Hill wrote:
> > On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > > More...
> > >
> > > splassert: sorwakeup: want 5 have 0
> > > Starting stack trace...
> > > splassert_check() at
On Tue, Sep 20, 2016 at 05:04:02PM +0200, Mike Belopuhov wrote:
> On Tue, Sep 20, 2016 at 10:51 -0400, David Hill wrote:
> > On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > > More...
> > >
> > > splassert: sorwakeup: want 5 have 0
> > > Starting stack trace...
> > >
On 20/09/16(Tue) 10:51, David Hill wrote:
> On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > More...
> >
> > splassert: sorwakeup: want 5 have 0
> > Starting stack trace...
> > splassert_check() at splassert_check+0x78
> > sorwakeup() at sorwakeup+0x27
> > route_input() at
On Mon, 19 Sep 2016 20:27:56 -0700, Philip Guenther wrote:
> I'm pretty sure I got all of the "no effect" casts to off_t and size_t.
> I picked up the void* and char* casts with a less comprehensize search, so
> there may be some that slipped through.
>
> This diff was checked by comparing
On Tue, Sep 20, 2016 at 10:51 -0400, David Hill wrote:
> On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> > More...
> >
> > splassert: sorwakeup: want 5 have 0
> > Starting stack trace...
> > splassert_check() at splassert_check+0x78
> > sorwakeup() at sorwakeup+0x27
> >
On 20 September 2016 at 16:50, Martin Pieuchot wrote:
> On 20/09/16(Tue) 16:37, Alexander Bluhm wrote:
>> On Tue, Sep 20, 2016 at 04:17:37PM +0200, Mike Belopuhov wrote:
>> > Can we assert that *_usrreq is always called under splsoftnet?
>>
>> I think that is the way to go.
On Tue, Sep 20, 2016 at 09:53:02AM -0400, David Hill wrote:
> More...
>
> splassert: sorwakeup: want 5 have 0
> Starting stack trace...
> splassert_check() at splassert_check+0x78
> sorwakeup() at sorwakeup+0x27
> route_input() at route_input+0x284
> pflog_clone_create() at
On 20/09/16(Tue) 16:37, Alexander Bluhm wrote:
> On Tue, Sep 20, 2016 at 04:17:37PM +0200, Mike Belopuhov wrote:
> > Can we assert that *_usrreq is always called under splsoftnet?
>
> I think that is the way to go. Long time back the spl moved from
> inet to socket. We need it in the socket
On Tue, Sep 20, 2016 at 04:17:37PM +0200, Mike Belopuhov wrote:
> Can we assert that *_usrreq is always called under splsoftnet?
I think that is the way to go. Long time back the spl moved from
inet to socket. We need it in the socket layer to fix various
races.
> I recall fixing some of them
On 20 September 2016 at 15:55, Alexander Bluhm wrote:
> On Tue, Sep 20, 2016 at 08:21:55AM -0400, David Hill wrote:
>> With bluhm's r1.160 uipc_socket.c.
>
> With splsoftnet() in soshutdown() I can fix this one.
>
> splassert: sowwakeup: want 5 have 0
> Starting stack
On Tue, Sep 20, 2016 at 03:39:17PM +0200, Mike Belopuhov wrote:
> On Tue, Sep 20, 2016 at 09:19 -0400, David Hill wrote:
> > Another...
> >
> > splassert: sorwakeup: want 5 have 4
> > Starting stack trace...
> > splassert_check() at splassert_check+0x78
> > sorwakeup() at sorwakeup+0x27
> >
On Tue, Sep 20, 2016 at 08:21:55AM -0400, David Hill wrote:
> With bluhm's r1.160 uipc_socket.c.
With splsoftnet() in soshutdown() I can fix this one.
splassert: sowwakeup: want 5 have 0
Starting stack trace...
splassert_check() at splassert_check+0x78
sowwakeup() at sowwakeup+0x27
uipc_usrreq()
More...
splassert: sorwakeup: want 5 have 0
Starting stack trace...
splassert_check() at splassert_check+0x78
sorwakeup() at sorwakeup+0x27
route_input() at route_input+0x284
pflog_clone_create() at pflog_clone_create+0xa4
if_clone_create() at if_clone_create+0x7f
ifioctl() at ifioctl+0x35a
Another
splassert: sowwakeup: want 5 have 0
Starting stack trace...
splassert_check() at splassert_check+0x78
sowwakeup() at sowwakeup+0x27
uipc_usrreq() at uipc_usrreq+0xfd
sys_shutdown() at sys_shutdown+0x67
syscall() at syscall+0x27b
--- syscall (number 134) ---
end of kernel
end trace frame:
On Tue, Sep 20, 2016 at 09:19 -0400, David Hill wrote:
> Another...
>
> splassert: sorwakeup: want 5 have 4
> Starting stack trace...
> splassert_check() at splassert_check+0x78
> sorwakeup() at sorwakeup+0x27
> pfkey_sendup() at pfkey_sendup+0x99
> pfkeyv2_sendmessage() at
On Tue, Sep 20, 2016 at 09:27:57AM -0400, David Hill wrote:
> On Tue, Sep 20, 2016 at 03:16:50PM +0200, Alexander Bluhm wrote:
> > On Tue, Sep 20, 2016 at 08:21:55AM -0400, David Hill wrote:
> > > With bluhm's r1.160 uipc_socket.c.
> > > Here are the first ones that were detected.
> >
> > Thanks
On Tue, Sep 20, 2016 at 03:16:50PM +0200, Alexander Bluhm wrote:
> On Tue, Sep 20, 2016 at 08:21:55AM -0400, David Hill wrote:
> > With bluhm's r1.160 uipc_socket.c.
> > Here are the first ones that were detected.
>
> Thanks for the fast report.
>
> So fifo works around the socket layer. Better
On 20 September 2016 at 15:16, Alexander Bluhm wrote:
> On Tue, Sep 20, 2016 at 08:21:55AM -0400, David Hill wrote:
>> With bluhm's r1.160 uipc_socket.c.
>> Here are the first ones that were detected.
>
> Thanks for the fast report.
>
> So fifo works around the socket
And another.
splassert: sorwakeup: want 5 have 4
Starting stack trace...
splassert_check() at splassert_check+0x78
sorwakeup() at sorwakeup+0x27
pfkey_sendup() at pfkey_sendup+0x99
pfkeyv2_sendmessage() at pfkeyv2_sendmessage+0x226
pfkeyv2_expire() at pfkeyv2_expire+0x18d
tdb_soft_timeout() at
Another...
splassert: sorwakeup: want 5 have 4
Starting stack trace...
splassert_check() at splassert_check+0x78
sorwakeup() at sorwakeup+0x27
pfkey_sendup() at pfkey_sendup+0x99
pfkeyv2_sendmessage() at pfkeyv2_sendmessage+0x226
pfkeyv2_expire() at pfkeyv2_expire+0x18d
tdb_timeout() at
OK
On 2016 Sep 20 (Tue) at 14:14:49 +0200 (+0200), Stefan Sperling wrote:
:Parse the DTIM count and period advertised in beacons and store them
:in the node structure. This should be useful for iwm(4) in the future.
:The TIM IE is documented in 802.11-2012 section "8.4.2.7 TIM element".
:
:ok?
:
On Tue, Sep 20, 2016 at 08:21:55AM -0400, David Hill wrote:
> With bluhm's r1.160 uipc_socket.c.
> Here are the first ones that were detected.
Thanks for the fast report.
So fifo works around the socket layer. Better call soconnect2()
instead of unp_connect2(). This adds the missing
Hello -
With bluhm's r1.160 uipc_socket.c.
Here are the first ones that were detected.
splassert: sowwakeup: want 5 have 0
Starting stack trace...
splassert_check() at splassert_check+0x78
sowwakeup() at sowwakeup+0x27
unp_connect2() at unp_connect2+0x62
fifo_open() at fifo_open+0x244
Parse the DTIM count and period advertised in beacons and store them
in the node structure. This should be useful for iwm(4) in the future.
The TIM IE is documented in 802.11-2012 section "8.4.2.7 TIM element".
ok?
There used to be code in iwm(4) which read these values from the ic
On 2016 Sep 17 (Sat) at 12:05:54 +0200 (+0200), Peter Hessler wrote:
:This is a 2nd pass at having BFD send route messages.
:
:I fixed the things pointed out in the first thread, with the following
:comments:
:
: route(8) for the ramdisks is not built with SMALL, so adding SMALL
:won't help.
:
:
On 2016 Sep 18 (Sun) at 20:29:57 +0200 (+0200), Peter Hessler wrote:
:On 2016 Sep 17 (Sat) at 13:15:56 +0200 (+0200), Peter Hessler wrote:
::Tested on an amd64 bsd.rd. dhclient, route add, route del, route show,
::all still work, and it's slightly smaller.
::
:
:All options, commands, modifiers,
On Mon, Sep 19, 2016 at 08:27:56PM -0700, Philip Guenther wrote:
> --- stdlib/malloc.c 18 Sep 2016 13:46:28 - 1.196
> +++ stdlib/malloc.c 19 Sep 2016 11:55:20 -
> @@ -1231,6 +1231,7 @@ _malloc_init(int from_rthreads)
> mprotect(_readonly, sizeof(malloc_readonly),
On 15/09/16(Thu) 16:29, Martin Pieuchot wrote:
> After discussing with a few people about a new "timed task" API I came
> to the conclusion that mixing timeouts and tasks will result in:
>
> - always including a 'struct timeout' in a 'struct task', or the other
> the way around
> or
>
>
Am 19.09.2016 um 22:30 schrieb Philip Guenther:
On Mon, Sep 19, 2016 at 11:02 AM, Jasper Lievisse Adriaanse
wrote:
OK?
Index: alpha/alpha/db_trace.c
...
ok guenther@
There is one too many closing brace in the arm code:
Index: sys/arch/arm/arm/db_trace.c
Reads fine to me. OK.
42 matches
Mail list logo