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 mu
> Date: Wed, 10 Sep 2014 21:52:30 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Sat, 6 Sep 2014 14:15:32 -0400
> > From: Daniel Dickman
> >
> > 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
>
> Date: Sat, 6 Sep 2014 14:15:32 -0400
> From: Daniel Dickman
>
> 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:
> https://github.com/numpy/numpy/iss
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
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
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 on
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
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 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 ieee80211_purge_c
On Wed, Sep 10, 2014 at 3:02 PM, Stuart Henderson 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 working ni
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.
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 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
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
Fantastic! Will be great for quick jobs without banshee fan wail and roasted
office space in the long summers.
Thank you.
/jl
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 toda
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 :)
>
> 2
17 matches
Mail list logo
