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
