I agree, was just pointing out what seemed to be the problem with the
code.
On Thu, 2008-09-25 at 22:39 -0400, Bob Copeland wrote:
> On Fri, Sep 26, 2008 at 09:26:10AM +1000, Geoffrey McRae wrote:
> > I can see the reason why this seg faults...
> >
> > ani_state = kzalloc(sizeof(struct ath5k_ani_
On Fri, Sep 26, 2008 at 09:26:10AM +1000, Geoffrey McRae wrote:
> I can see the reason why this seg faults...
>
> ani_state = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
>
> shoud be
>
> *ani_state = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
That's still a strange way to wri
I can see the reason why this seg faults...
ani_state = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
shoud be
*ani_state = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
On Wed, 2008-09-24 at 08:49 -0400, Bob Copeland wrote:
> > b) During attach i do a bad memory allocation
> >
2008/9/24 Bob Copeland <[EMAIL PROTECTED]>:
>> 2008/9/24 Bob Copeland <[EMAIL PROTECTED]>:
>> > Shouldn't this be something like:
>> >
>> >ah->ah_ai_state = kzalloc()...
>> >
>> > Otherwise ath5k_hw_ani_set_min_immunity segfaults immediately.
>>
>> Already tested that and it doesn't segfaul
> 2008/9/24 Bob Copeland <[EMAIL PROTECTED]>:
> > Shouldn't this be something like:
> >
> >ah->ah_ai_state = kzalloc()...
> >
> > Otherwise ath5k_hw_ani_set_min_immunity segfaults immediately.
>
> Already tested that and it doesn't segfault, we set ah_ani_state before
> that...
> struct at
2008/9/24 Bob Copeland <[EMAIL PROTECTED]>:
>> b) During attach i do a bad memory allocation
>> ani_stats = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
>> just change it to
>> ani_stats = kzalloc(sizeof(struct ath5k_ani_stats), GFP_KERNEL);
>
> Looks like more is wrong with that:
>
>> int
> b) During attach i do a bad memory allocation
> ani_stats = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
> just change it to
> ani_stats = kzalloc(sizeof(struct ath5k_ani_stats), GFP_KERNEL);
Looks like more is wrong with that:
> int ath5k_hw_ani_attach(struct ath5k_hw *ah){
> str
2007/12/18 bruno randolf <[EMAIL PROTECTED]>:
> On Tuesday 18 December 2007 01:24:07 Nick Kossifidis wrote:
>> 2007/12/17, bruno randolf <[EMAIL PROTECTED]>:
>> > hi nick!
>> >
>> > thanks for the explanations, that makes it a bit more transparent how you
>> > figure that stuff out...
>> >
>> > On
On Thursday 20 December 2007 02:36:46 Nick Kossifidis wrote:
> 2007/12/17, Nick Kossifidis <[EMAIL PROTECTED]>:
> > 2007/12/13, Pavel Roskin <[EMAIL PROTECTED]>:
> > > Hello!
> > >
> > > On Thu, 2007-12-13 at 19:36 +0200, Nick Kossifidis wrote:
> > > > So what we really have to rev.engineer is ani_
2007/12/17, Nick Kossifidis <[EMAIL PROTECTED]>:
> 2007/12/13, Pavel Roskin <[EMAIL PROTECTED]>:
> > Hello!
> >
> > On Thu, 2007-12-13 at 19:36 +0200, Nick Kossifidis wrote:
> >
> > > So what we really have to rev.engineer is ani_control function.
> >
> > Can we somehow counteract whatever the new
On Tuesday 18 December 2007 01:24:07 Nick Kossifidis wrote:
> 2007/12/17, bruno randolf <[EMAIL PROTECTED]>:
> > hi nick!
> >
> > thanks for the explanations, that makes it a bit more transparent how you
> > figure that stuff out...
> >
> > On Monday 17 December 2007 15:02:05 Nick Kossifidis wrote:
2007/12/13, Pavel Roskin <[EMAIL PROTECTED]>:
> Hello!
>
> On Thu, 2007-12-13 at 19:36 +0200, Nick Kossifidis wrote:
>
> > So what we really have to rev.engineer is ani_control function.
>
> Can we somehow counteract whatever the new HAL is doing with ANI without
> reverse engineering, just by writ
2007/12/17, Nick Kossifidis <[EMAIL PROTECTED]>:
> 2007/12/17, bruno randolf <[EMAIL PROTECTED]>:
> > hi nick!
> >
> > thanks for the explanations, that makes it a bit more transparent how you
> > figure that stuff out...
> >
> > On Monday 17 December 2007 15:02:05 Nick Kossifidis wrote:
> > > Brun
2007/12/17, bruno randolf <[EMAIL PROTECTED]>:
> hi nick!
>
> thanks for the explanations, that makes it a bit more transparent how you
> figure that stuff out...
>
> On Monday 17 December 2007 15:02:05 Nick Kossifidis wrote:
> > Bruno can you redo this dump with 802.11b link (CCK) ? It might be
>
hi nick!
thanks for the explanations, that makes it a bit more transparent how you
figure that stuff out...
On Monday 17 December 2007 15:02:05 Nick Kossifidis wrote:
> Bruno can you redo this dump with 802.11b link (CCK) ? It might be
> easier to spot what these registers do (and verify if i'm
This is what i've found so far (for more infos check out patent doc
and code that was inside if_ath.c ->
http://madwifi.org/browser/cvs-import/trunk/driver/if_ath.c?rev=135#L2291
)...
This part seems to reset counters in mac...
> 1020: R: 0x8090 = 0x - AR5K_ACK_FAIL_5211
> 1021: R: 0x808c
Hello!
On Thu, 2007-12-13 at 19:36 +0200, Nick Kossifidis wrote:
> So what we really have to rev.engineer is ani_control function.
Can we somehow counteract whatever the new HAL is doing with ANI without
reverse engineering, just by writing to the registers what the old HAL
would do at the strat
2007/12/13, bruno randolf <[EMAIL PROTECTED]>:
> hi!
>
> since turning interference mitigation (ANI) on and off seems to have an
> important impact on performance, i traced it down, with both the "old" HAL
> v0.9.18.0 and the "new" HAL v0.9.30.13. superficially both do the same thing,
> but the new
hi!
since turning interference mitigation (ANI) on and off seems to have an
important impact on performance, i traced it down, with both the "old" HAL
v0.9.18.0 and the "new" HAL v0.9.30.13. superficially both do the same thing,
but the new HAL ignores setting "intmit" to 0. well, for ath5k it
19 matches
Mail list logo
