On Wed, 16 Dec 2015, Alexandr Nedvedicky wrote:
> On Wed, Dec 16, 2015 at 02:48:49PM +1300, Richard Procter wrote:
> > Quoting pf.conf(5) "once - Creates a one shot rule that will remove itself
> > from an active ruleset after the first match."
> >
> > A 'first' match presupposes a total orde
I updated a box running bgpd/ospfd/ospf6d earlier and ran into this when
bgpd started at boot time:
$ syslogc bgpd | cut -d' ' -f 3,5-
21:03:23 bgpd[2742]: startup
21:03:23 bgpd[2742]: rereading config
21:03:23 bgpd[8249]: route decision engine ready
21:03:23 bgpd[2742]: new ktable rdomain_0 for r
On Thu, Dec 17, 2015 at 08:13:03PM +0100, Stefan Sperling wrote:
> This should fix the infinite scanning loops people have been
> reporting with 11n-enabled iwn(4), as well as the issue where
> clients associating to 11g APs end up in 11b mode and can't
> use OFDM data rates.
>
> ok?
Updated diff
On Thu, Dec 17, 2015 at 9:01 PM, Ted Unangst wrote:
> Maxim Pugachev wrote:
>> On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst wrote:
>> > Maxim Pugachev wrote:
>> >> Currently two checks in free() function confirm the correctness of
>> >> freedsize argument. I think that it's better to check that
On Thu, Dec 17, 2015 at 8:21 PM, Ted Unangst wrote:
> Maxim Pugachev wrote:
>> Hey all,
>>
>> I'm wondering, why an allocation type in kern/exec_elf.c is equal to
>> M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate
>> memory as M_EXEC, and it looks more reasonable to me.
>>
>
This should fix the infinite scanning loops people have been
reporting with 11n-enabled iwn(4), as well as the issue where
clients associating to 11g APs end up in 11b mode and can't
use OFDM data rates.
ok?
Index: ieee80211.c
===
RC
On 12/16/15 15:35, Stefan Sperling wrote:
This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.
It also tweaks replay detection for CCMP encrypted frames, which needed
tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
this driver was discarding some re
Maxim Pugachev wrote:
> On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst wrote:
> > Maxim Pugachev wrote:
> >> Currently two checks in free() function confirm the correctness of
> >> freedsize argument. I think that it's better to check that provided
> >> freedsize fall into the same bucket that was
Maxim Pugachev wrote:
> Ping?
>
> On Sun, Dec 13, 2015 at 12:28 AM, Maxim Pugachev
> wrote:
> > Hi,
> >
> > In a case when the shell name is not specified (i.e. just "#!" without
> > a path), don't run the heavy logic that checks shell, simply return
> > ENOENT.
> >
> > Also, as a tiny improveme
Maxim Pugachev wrote:
> Hey all,
>
> I'm wondering, why an allocation type in kern/exec_elf.c is equal to
> M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate
> memory as M_EXEC, and it looks more reasonable to me.
>
> What's the reason for this?
I think the reason is M_TEMP
Theo Buehler wrote:
> I've now committed most of your diff, thanks once again.
>
> o I asked for further review on the kernel parts
> o I'm going to skip hack for now
>
> Here's a patch for libc, based on the previous discussion.
> I think this is easier to read and understand. No binary
hello,
The following patch passes the correct size to free(9) for a filedesc's
klist.
Index: kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.125
diff -u -p -r1.125 kern_descrip.c
--- kern_descrip
On Thu, Dec 17, 2015 at 12:40:48PM +0100, Marcus MERIGHI wrote:
> iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b
> iwn0: association failed (status 18)
On 2015/12/17 13:22, Stefan Sperling wrote:
> On Thu, Dec 17, 2015 at 12:40:48PM +0100, Marcus MERIGHI wrote:
> > iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> > iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> > iwn0: received auth from 80:1f:02:c1:fd:86 rssi
> From: Christian Weisgerber
> Date: Thu, 17 Dec 2015 11:50:53 + (UTC)
>
> On 2015-12-16, Mark Kettenis wrote:
>
> > The downside of this diff is that number of levels is limited to 16
> > whereas we currently have much finer granularity. But I think that is
> > acceptable. The levels are
Thanks Stefan!
Works on my Thinkpad X220.
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO
1T2R, BGS, address 74:e5:0b:c6:3c:c8
dmesg:
OpenBSD 5.8-current (GENERIC.MP) #1752: Thu Dec 17 01:17:05 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN
On 2015-12-16, Mark Kettenis wrote:
> The downside of this diff is that number of levels is limited to 16
> whereas we currently have much finer granularity. But I think that is
> acceptable. The levels are probably better calibrated and we now have
> proper coordination between the OS and the
s...@stsp.name (Stefan Sperling), 2015.12.16 (Wed) 15:35 (CET):
> This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.
>
> It also tweaks replay detection for CCMP encrypted frames, which needed
> tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
> this
Here is a diff to pass around the size to free(9) in amd64's _bus_dmamap
allocations.
i386 is symmetric but I don't have the hardware currently to test it.
Index: bus_dma.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
retr
On Thu, Nov 26, 2015 at 09:02:17PM +0500, Alexandr Shadchin wrote:
> From http://en.cppreference.com/w/c/numeric/complex/csqrt :
>
> csqrt(conj(z)) == conj(csqrt(z))
>
> Before patch
> csqrt(-4.0 + -0.0i) = 0.0 + 2.0j
> but should be
> csqrt(-4.0 + -0.0i) = 0.0 - 2.0j
This, too, looks right to
On Fri, Nov 27, 2015 at 03:14:52PM +0500, Alexandr Shadchin wrote:
> Fix wrong answer if the imaginary part is zero.
> NetBSD also turn off this piece of code.
>
> See
> http://en.cppreference.com/w/c/numeric/complex/casin
> http://www.wolframalpha.com/input/?i=asin%28-2.0%29
Makes complete sense
I've now committed most of your diff, thanks once again.
o I asked for further review on the kernel parts
o I'm going to skip hack for now
Here's a patch for libc, based on the previous discussion.
I think this is easier to read and understand. No binary change on
amd64.
ok?
Index: lib
On 16/12/15(Wed) 23:57, Alexander Bluhm wrote:
> On Wed, Dec 16, 2015 at 09:46:26PM +0100, Alexander Bluhm wrote:
> > 10.188.70.17 fe:e1:ba:d0:d5:6d UHLS 03 - 8 vio0
>
> This is this route that crashed the machine when the arp entry expired.
>
> When I move the rtref(
I don’t have MPLS.
No regression.
> On 4 dec. 2015, at 14:51, Martin Pieuchot wrote:
>
> To reduce contention in the fast path we can use a mutex(9) to serialize
> read/write operations on the radix tree instead of the KERNEL_LOCK.
>
> Note that the KERNEL_LOCK is still needed to serialize walk
No regression here.
> On 4 dec. 2015, at 11:54, Martin Pieuchot wrote:
>
> Now that in_arpinput() only uses the routing table, if_get()/if_put()
> and carp_iamatch being already mpsafe we can kill the ARP input queue.
>
> This moves the ARP input path processing from the softnet interrupt
> con
25 matches
Mail list logo
