On Tue, Sep 09, 2014 at 10:17:59PM +0200, Fabian Raetz wrote:
Hm interesting ... i can reproduce it here with an 2.4GHz AP.
The entry isn't cleared when scanning and the interface is up.
Scanning when the interface is down works correct for me.
I will take a look at it tommorow :)
On 2014/09/10 04:44, Ingo Schwarze wrote:
Sure. When i see ld(1) dying from signals, i'll bump limits. But
that's not what what i'm talking about. Memory allocation failure
in ld(1) is hopefully not going to cause a hard kernel lockup.
Besides, almost all the kernel lockups i saw today
Fantastic! Will be great for quick jobs without banshee fan wail and roasted
office space in the long summers.
Thank you.
/jl
On 09/10/14 10:15, Stefan Sperling wrote:
On Tue, Sep 09, 2014 at 10:17:59PM +0200, Fabian Raetz wrote:
Hm interesting ... i can reproduce it here with an 2.4GHz AP.
The entry isn't cleared when scanning and the interface is up.
Scanning when the interface is down works correct for me.
I
On Wed, Sep 10, 2014 at 02:06:15PM +0200, Marcin Piotr Pawlowski wrote:
On 09/10/14 10:15, Stefan Sperling wrote:
On Tue, Sep 09, 2014 at 10:17:59PM +0200, Fabian Raetz wrote:
Hm interesting ... i can reproduce it here with an 2.4GHz AP.
The entry isn't cleared when scanning and the
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
Best regards,
mpp
On 09/10/14 14:34, Stefan Sperling wrote:
On Wed, Sep 10, 2014 at 02:06:15PM +0200, Marcin Piotr Pawlowski wrote:
On 09/10/14 10:15, Stefan Sperling wrote:
On
On 2014/09/10 14:42, Marcin Piotr Pawlowski wrote:
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
Only tested lightly so far, but this seems to be working nicely for me,
thanks Marcin.
On Wed, Sep 10, 2014 at 3:02 PM, Stuart Henderson st...@openbsd.org wrote:
On 2014/09/10 14:42, Marcin Piotr Pawlowski wrote:
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
Only tested lightly so far, but this seems to be
On Wed, Sep 10, 2014 at 02:42:43PM +0200, Marcin Piotr Pawlowski wrote:
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
ok kspillner@, but would prefer a better name than ieee80211_clean_cached. :)
Perhaps
audioctl output is full of useless, misleading and/or unreliable
fields. Let's keep the usable ones only. The plan is to remove them
from the kernel as well.
OK?
Index: audioctl.c
===
RCS file: /cvs/src/usr.bin/audioctl/audioctl.c,v
On Wed, Sep 10, 2014 at 12:27:05PM -0500, Kent R. Spillner wrote:
On Wed, Sep 10, 2014 at 02:42:43PM +0200, Marcin Piotr Pawlowski wrote:
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
ok kspillner@, but would prefer a
On Wed, Sep 10, 2014 at 02:42:43PM +0200, Marcin Piotr Pawlowski wrote:
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
Hi,
this patch works for me too.
But is the problem not specific to the
iwn(4) driver or at least only
Hi,
On 09/10/14 20:19, Fabian Raetz wrote:
On Wed, Sep 10, 2014 at 02:42:43PM +0200, Marcin Piotr Pawlowski wrote:
Yes, I think that it could be is possible to double clean the node cache.
Updated diff with suggestion from Stefan.
Hi,
this patch works for me too.
But is the problem
On Wed, Sep 10, 2014 at 07:39:00PM +0200, Stefan Sperling wrote:
I think ieee80211_clean_cached() is fine.
The function only removes notes in CACHE state. These are nodes
that are visible but haven't otherwise interacted with us.
There are additional states, all of which refer to nodes which
Date: Sat, 6 Sep 2014 14:15:32 -0400
From: Daniel Dickman didick...@gmail.com
according to the numpy developers asinhl on sparc64 might be buggy. I
haven't worked out a test case yet but just reporting in case anyone else
wants to take a look as well.
bug report:
Date: Wed, 10 Sep 2014 21:52:30 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Sat, 6 Sep 2014 14:15:32 -0400
From: Daniel Dickman didick...@gmail.com
according to the numpy developers asinhl on sparc64 might be buggy. I
haven't worked out a test case yet but just
On Fri, Aug 15, 2014 at 13:06, Ted Unangst wrote:
Instead, ressl should copy all parameters as necessary and
free them. This does introduce an error case into formerly void
functions, but I think that's ok. The alternative would be to use
fixed arrays inside ressl_config, but that seems much
17 matches
Mail list logo
