Hi.
> i have just created a madwifi branch prepared for tracing
> (madwifi/branches/madwifi-trace) and checked in my scripts to make tracing
> easier. so getting register traces is really easy now.
Tarballs for this new branch are now automatically created and available
for download.
For downloa
hello!
i have just created a madwifi branch prepared for tracing
(madwifi/branches/madwifi-trace) and checked in my scripts to make tracing
easier. so getting register traces is really easy now.
it's all documented here:
http://madwifi.org/wiki/DevDocs/MadwifiTrace
i uploaded the trace informa
hmm... that would mean i would have to add support for overlapping ranges to
the script (searching for the most specific matching one) or add a special
case for AR5K_PHY which i'm not quite ready to do for an idea i'm not 100%
convinced of anyways. feel free to do it.
bruno
On Wednesday 31 O
On Wednesday 31 October 2007 10:03:27 Nick Kossifidis wrote:
> This is also an easy way to automate ath_info, it would be nice if we
> included that on the script too...
> [...]
> #Get memory address for ath_info...
> mem=`dmesg|grep Atheros|awk '{print $4}'|awk -F"=" '{print $2}'`
thats not a goo
This is also an easy way to automate ath_info, it would be nice if we
included that on the script too...
#!/bin/bash
#See if madwifi is loaded...
lsmod|grep ath_pci > /dev/null
if [ $? != 0 ]
then
modprobe ath_pci
fi
#Get memory address for ath_info...
mem=`dmesg|grep Atheros|awk '{print
I think it's more easy to remember an int (eg AR5K_PHY(231)) than a
hex value + it makes searching more easy (eg. we'll want to see when
and how often a register is written so we might figure out what it
is).
We can limit this, the last known phy register is
AR5K_PHY_GAIN_2GHZ 0xa20c
so we might
ok. i updated the values in the wiki. delete your ath_registers.wiki.txt and
it will be fetched again.
for AR5K_PHY (0x9800-???): do you really think it is a good idea?
i think using symbolic names like AR5K_PHY(231) just hide away the fact that
we don't know anything about it. i'd rather prefer
2007/10/31, bruno randolf <[EMAIL PROTECTED]>:
> On Wednesday 31 October 2007 00:50:28 Luis R. Rodriguez wrote:
> > Nice, how about we start an svn branch on madwifi with this stuff, it
> > might be easier for users. I understand the current instructions are
> > pretty involved.
>
> yep, that's fin
On Wednesday 31 October 2007 00:50:28 Luis R. Rodriguez wrote:
> Nice, how about we start an svn branch on madwifi with this stuff, it
> might be easier for users. I understand the current instructions are
> pretty involved.
yep, that's fine with me.
i'd also like to add my trace and decode scrip
On Wednesday 31 October 2007 00:12:49 Dan Williams wrote:
> > +EXPORT_SYMBOL(ath_hal_func);
>
> Any particular reason this is not EXPORT_SYMBOL_GPL?
nope. i just didn't care. actually i don't think it's important - it's just
debugging/reverse engineering code after all... i don't think anyone is
This line got lost when the descriptor setup and fill functions were
merged. Applies ontop of Nick's patches.
Changes-licensed-under: ISC
Signed-off-by: Ulrich Meis <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/ath5k/hw.c b/drivers/net/wireless/ath5k/hw.c
index 7b9920c..50ceab0 100644
2007/10/30, Ulrich Meis <[EMAIL PROTECTED]>:
> On Tue 30.10.07 12:45, Luis R. Rodriguez wrote:
> > On 10/27/07, Nick Kossifidis <[EMAIL PROTECTED]> wrote:
> > > fill_tx_desc is used for fast frames operation, since
> > > we don't support fast frames (and since fill_tx_desc
> > > had a bug -thanx to
On Tue 30.10.07 12:45, Luis R. Rodriguez wrote:
> On 10/27/07, Nick Kossifidis <[EMAIL PROTECTED]> wrote:
> > fill_tx_desc is used for fast frames operation, since
> > we don't support fast frames (and since fill_tx_desc
> > had a bug -thanx to Ulrich Meis for finding that out-)
> > these functions
On 10/27/07, Nick Kossifidis <[EMAIL PROTECTED]> wrote:
> fill_tx_desc is used for fast frames operation, since
> we don't support fast frames (and since fill_tx_desc
> had a bug -thanx to Ulrich Meis for finding that out-)
> these functions are not needed (+ they are misleading
> because they don'
On 10/30/07, bruno randolf <[EMAIL PROTECTED]> wrote:
> hi luis!
>
> adding the following patch lets us log the calling function names as well!
> which makes it much easier to make sense to the traces :)
>
> and i added ALQ=1 MMIOTRACE=1 and the objdump command to the Makefile as well
> to avoid fo
On 10/30/07, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-30 at 17:49 +0900, bruno randolf wrote:
> > hi luis!
> >
> > adding the following patch lets us log the calling function names as well!
> > which makes it much easier to make sense to the traces :)
> >
> > and i added ALQ=1 MMIO
On Tue, 2007-10-30 at 17:49 +0900, bruno randolf wrote:
> hi luis!
>
> adding the following patch lets us log the calling function names as well!
> which makes it much easier to make sense to the traces :)
>
> and i added ALQ=1 MMIOTRACE=1 and the objdump command to the Makefile as well
> to av
On Mon 08.10.07 13:15, David Boreham wrote:
>
> I discovered that the fast frames option is disabled by default.
I believe it is enabled by default on all cards for which the hal
reports that they do support it. For example on my 5212 it is enabled by
default. Relevant lines in if_ath.c:
#ifdef
> sure, it's as easy as adding the right ranges to the wiki.
> can you tell me the end addresses?
>
> i'm guessing:
>
> 0x9a00-0x9aff ??? AR5K_RF_GAIN
> 0x9b00-0x9c00 ??? AR5K_BB_GAIN ???
RF_GAIN and BB_GAIN tables are 64bytes each
so its from AR5K_RF_GAIN(0) to AR5K_RF_GAIN(63)
(0x9a0
hi luis!
adding the following patch lets us log the calling function names as well!
which makes it much easier to make sense to the traces :)
and i added ALQ=1 MMIOTRACE=1 and the objdump command to the Makefile as well
to avoid forgetting that.
cheers,
bruno
this time the patch is included,
hi luis!
adding the following patch lets us log the calling function names as well!
which makes it much easier to make sense to the traces :)
and i added ALQ=1 MMIOTRACE=1 and the objdump command to the Makefile as well
to avoid forgetting that.
cheers,
bruno
On Saturday 20 October 2007 04:
21 matches
Mail list logo
