Hi Nick Kossifidis, I changed the DMASIZE to 64B. Now it is working fine even in higher cpu frequencies. Thanks for ur suggestions.
Regads, S.Satish. 2009/2/15 Nick Kossifidis <[email protected]> 2009/2/14 satish sethuraman <[email protected]>: > > Dear friends, > > This is satish from Indian Institute of Science. I am working on 802.11s > > implementation. > > > > We are using routerboard 433ah platform which has atheros processor. > > The wifi chip we are using is AR5413. We are using ath5k driver > downloaded > > from compat wireless. > > > > Our board reboots at higher clock frequency (> 100 MHZ). The processor > hangs > > approx. five minutes after we bring the wlan0 interface up. > > When we ping from the board with higher size data bytes ( Ex: ping -s 128 > ), > > the board hangs after two pings in higher clock frequency. The same > problem > > occurs when we ping our board from some other system. But the above issue > > does not arise when the clock frequency is 100 MHZ. > > > > when i add intr alone into the debug/ath5k/phy0/debug, the /proc/kmesg/ > is > > flooded with following info: > > __ratelimit: 4026 callbacks suppressed > > <4>__ratelimit: 4026 callbacks suppressed > > > > <7>ath5k phy0: (ath5k_intr:2427): status 0x1/0x800904b5 > > <7>ath5k phy0: (ath5k_intr:2427): status 0x1/0x800904b5 > > <7>ath5k phy0: (ath5k_intr:2427): status 0x1/0x800904b5 > > > > I have attached the content of /proc/kmesg when I enable all in > > debug/ath5k/phy0/debug. > > > > Please give ur suggestions. > > > > I have already filed a bug in bugzilla > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12647 > > > > > > I, therefore, request u all to give me some insight abt this issue. > > > > > > -- > > Regards, > > S.Satish. > > Helo ;-) > > > <7>ath5k phy0: (ath5k_intr:2427): status 0x1/0x800904b5 > > <7>ath5k phy0: (ath5k_intr:2427): status 0x1/0x800904b5 > > <7>ath5k phy0: (ath5k_intr:2427): status 0x1/0x800904b5 > > You get an rx ok interrupt, that's not a problem, it seems that > interrupt is triggered and that can be related to dma size... > > There are known problems with dma size for embedded devices, for a > long time we used 512B for all cards except pci-e, now (after the > recent patch series that updated reset.c) we use the standard 128B > like MadWiFi. Check out your reset.c and see if it's updated to use > this. Get the latest code from wireless-testing tree and check it > out... > > 1296 if (ah->ah_version != AR5K_AR5210) { > 1297 AR5K_REG_WRITE_BITS(ah, AR5K_TXCFG, > 1298 AR5K_TXCFG_SDMAMR, AR5K_DMASIZE_128B); > 1299 AR5K_REG_WRITE_BITS(ah, AR5K_RXCFG, > 1300 AR5K_RXCFG_SDMAMW, AR5K_DMASIZE_128B); > 1301 } > > ...note that some boards need even smaller size to work corectly. > > I'm thinking we should make that depend on EMBEDDED and have 64 for > all embedded boards to be safe, what do you think ? > > -- > GPG ID: 0xD21DB2DB > As you read this post global entropy rises. Have Fun ;-) > Nick > -- Regards, S.Satish. -- Regards, S.Satish.
_______________________________________________ ath5k-devel mailing list [email protected] https://lists.ath5k.org/mailman/listinfo/ath5k-devel
