Ok just forget my message, these values are set on phy.c, I should read the
code more carefully :-)
2008/8/5 Frédéric Weisbecker <[EMAIL PROTECTED]>
> Hi,
>
> After looking at 2425 dumps I saw some RF_GAIN values that seem to always
> and immediately follow the 2425 specific
Hi,
After looking at 2425 dumps I saw some RF_GAIN values that seem to always
and immediately follow the 2425 specific initial values. I think these are
parts of
Rf Gain initial values.
Here is a patch which appends them on rf2425_ini_mode_end. It is based on
wireless-testing git.
Regards.
diff
2008/7/20 Nick Kossifidis <[EMAIL PROTECTED]>:
> 2008/7/20 Alan Jenkins <[EMAIL PROTECTED]>:
> > Frédéric Weisbecker wrote:
> >> Yes I have the same problem.
> >> I think I found the origin.
> >> That's because wme_qdiscop_destr
Yes I have the same problem.
I think I found the origin.
That's because wme_qdiscop_destroy in net/mac80211/wme.c passes a bad
pointer in tcf_destroy_chain.
It requires a struct tcf_proto **fl and not a struct tcf_proto *fl
Here is a patch, I can't test it because my gcc segfaults but I think it
w
ernel > 2.6.22, i have 2.6.25 on
> my laptop.
>
> 2008/7/17 Frédéric Weisbecker <[EMAIL PROTECTED]>:
> > Good news! :-)
> >
> > I have some troubles to build it. Can you tell me which kernel you used
> to
> > make it?
> >
> > PS: Sorry I alw
ossifidis <[EMAIL PROTECTED]>:
> >> It's ready ppl, just associated, everything seems to work ok. We still
> >> have performance issues but it's normal (still no ANI/power table
> >> calibration/minor rfregs additions) !!
> >>
> >>
And debugging will be more pleasant with something that is starting to work
:-)
2008/7/11 Pavel Roskin <[EMAIL PROTECTED]>:
> On Fri, 2008-07-11 at 14:23 +0300, Nick Kossifidis wrote:
> > Just to inform you that i just got RX working ;-)
>
> You are the man, Nick! Sometimes monitor mode is all I
Great! How did you get it work? What was there missing?
2008/7/11 Nick Kossifidis <[EMAIL PROTECTED]>:
> Just to inform you that i just got RX working ;-)
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
__
Ok thanks for the tip. So I will wait until the wireless-testing 2.6.27-rc1
:-)
2008/7/9 Pavel Roskin <[EMAIL PROTECTED]>:
> On Tue, 2008-07-08 at 16:13 +0200, Frédéric Weisbecker wrote:
> > Ok thank you for your answer.
> > In the purpose to compare ath5k traces wit
]>:
> On Fri, 2008-07-04 at 15:54 +0200, Frédéric Weisbecker wrote:
> > Hello,
> >
> > Sorry I wanted to try this version but I was involved in my exams and
> > had not enough time to
> > make some tests.
> > Now I have much free time. I have tried this ve
Hello,
Sorry I wanted to try this version but I was involved in my exams and had
not enough time to
make some tests.
Now I have much free time. I have tried this version with the last wireless
git and I get too much compilation errors. It seems that some structures
have changed since this 2425 tes
2008/5/10 Nick Kossifidis <[EMAIL PROTECTED]>:
> I've been doing some disassembly on the binary HAL and it seems i got
> the function that sets the channel on RF2425, it seems different from
> the one we are using so that might be the problem.
>
> I also found that for each phy chip there is a set
2008/5/8 Nick Kossifidis <[EMAIL PROTECTED]>:
>
> Seems it's the radio initialization.
>
Yes you said in your first post that radio_revision returns 0.
I checked it on a madwifi dump and I see the same result: it returns 0:
0.006182 write32 #1 0xfa009800 <- 0x0007 (ATH_PHY(0))
0.006185
2008/5/8 Nick Kossifidis <[EMAIL PROTECTED]>:
>
> I stored init_val but forgot to write it at the end of the for loop !
> Static values found on ndiswrapper dumps don't show up in madwifi
> traces, that's why i put the comment there, i also see them in RF2425
> ndiswrapper dumps so there is no ne
Hello,
Nothing serious but I found a small difference with the 2425 in
ath5k_hw_post()
_The value of two registers are replaced inside a counter but their initial
value is not restored at the end. I checked on a madwifi dump and it is
restored.
Example in a trace:
0.001450read32 #1 0xfa00800
> 2008/5/1 Pavel Roskin <[EMAIL PROTECTED]>:
>
> >
> >
> > I don't know where you got the last two lines, but we absolutely should
> > not be using Atheros HAL code!
> >
>
Of course it's not the real Atheros code (I don't have any access to it). I
just guessed it with multiple traces and tests.
It's a really good idea, I will try that with my AR5007EG...
> 2008/5/1 Bob Copeland <[EMAIL PROTECTED]>:
>
> >
> >
> > One thing I did here, which is silly but works, is to just printk
> > inside of ath5k_reg_read/write(). I would think mmiotrace should work
> > just as well for these though.
Hello,
I have tested it on my AR5007EG. And as you said there is nothing sent
or received.
I loaded it with debug=0x300 (Dump the Tx / Rx)
And after the set of the IP, I see this packet dumped many times:
phy0 TX 40 00 00 00 ff ff ff ff ff ff 00 16 44 75 ed e4
@...Du.
2008/1/31, Hans-Jürgen Koch <[EMAIL PROTECTED]>:
>
> Am Thu, 31 Jan 2008 12:52:11 +0200
> schrieb "Nick Kossifidis" <[EMAIL PROTECTED]>:
>
> > > I don't think ath5k has support for AR5007 chipsets so far.
> > >
> >
> > Indeed it hasn't, i've only fixed hw attach so far, even with some
> > dumps at
19 matches
Mail list logo
