hi nick!

thank you for the instructions!

i used them to trace sta mode connections to a and g aps.

the 5414 includes turbo a mode. unfortunately i couldn't setup turbo g mode 
with f****ng madwifi anymore (i know i used to).

http://br1.einfach.org/ath/5213-connect.tgz
http://br1.einfach.org/ath/5213A-connect.tgz
http://br1.einfach.org/ath/5414-connect.tgz

i think we should make 1) "call ath_hal_reset WITHOUT channel change flag" 
default in the madwifi-trace branch then.

bruno

On Friday 09 November 2007 00:39:39 Nick Kossifidis wrote:
> 2007/11/8, bruno randolf <[EMAIL PROTECTED]>:
> > hi!
> >
> > i put up 2 new traces of cardbus cards, both with a 5112A PHY. the
> > curious thing is, the one with the 5213 MAC works with ath5k, but the one
> > with 5213A doesn't. there shouldn't be *that* much difference...
> >
> > http://br1.einfach.org/ath/5213-5112A-mad-trace.tgz
> > http://br1.einfach.org/ath/5213A-5112A-mad-trace.tgz
> >
> > i'll try to figure out the differences tomorrow, but i'm still a bit
> > overwhelmed with the amount of data. i want to add a --filter option to
> > the ath-reg-decode script to get rid of the uninteresting registers...
> >
> > right now i think we can filter (this is a regex):
> >
> > KEY|AR5K_PCICFG|AR5K_SLEEP|AR5K_INTPEND|AR5K_STA_ID1|AR5K_STA_ID0|AR5K_TS
> >F_| AR5K_PISR|AR5K_RAC_PISR|AR5K_RXDP|AR5K_SIMR|AR5K_PIMR|AR5K_IER
> >
> > maybe
> >
> > BSS_ID|TIMER|AR5K_QUEUE_DFS_SEQNUM|AR5K_QUEUE_TXDP|BEACON
> >
> > and
> >
> > AR5K_RX_FILTER_5211|AR5K_PHY_ERR_FIL|AR5K_PHY_ERR_FIL|AR5K_RXCFG|MCAST_FI
> >LTER|
> > AR5K_ACK_FAIL_5211|AR5K_RTS_FAIL_5211|AR5K_FCS_FAIL_5211|AR5K_RTS_OK_5211
> >
> > too?
> >
> > nick? luis? anyone? can you comment?
> >
> > thanks,
> > bruno
>
> Just do the following for faster results (i'm doing the same for 5414
> stuff)...
>
> 1) In if_ath.c always call ath_hal_reset WITHOUT channel change flag
> so we always get a full reset (documentation is faulty on this, when
> setting channel_change flag some steps on reset are skiped and we want
> them on the trace).
>
> 2) After that only get the last reset circle (the one before
> connection -you shouldn't see another reset after that) from
> ath_hal_reset to the last call to ath_hal_beacontimers (then only
> rx_monitor/gettsf etc are called). Getting the card to connect
> somewhere is very usefull for traces, here is what i do...
>
> a) enable loging/debug
> b) modprobe ath_pci
> c) save log as <rev>-attach.log
> d) disable loging/empty log/reenable loging
> e) iwpriv ath0 mode <mode> <- this should result a call to resettxqueue
> f) save log as <rev>-iwpriv-mode-<mode>.log
> g) disable loging/empty log/reenable loging
> h) iwconfig ath0 essid <essid> channel <channel> <- this doesn't
> result any data on the log
> i) ifconfig ath0 up
> j) wait to connect
> k) disable loging/save log as <rev>-ifup-connected-chan<channel>.log
>
> now attach and iwpriv logs are always the same and it's easy to diff
> them etc, on ifup logs doing 2 helps a lot because last step is what
> it's interesting to us (untill then card is switching channels etc and
> this is some extra noise we don't need).
>
> On 5212/5213 this should give you about 1300 - 1308 lines (the full
> reset cycle) that should be easy to diff and see what happens. I'll
> also look into it ;-)


_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to