Date: Sat, 30 Dec 2006 19:33:15 -0800 From: Sam Leffler <sam@errno.com> To: JoaoBR <joao@matik.com.br> Cc: freebsd-stable@freebsd.org, Lamont Granquist <lamont@scriptkiddie.org> Subject: Re: ath0 timeout problem - again Message-ID: <45972F7B.4060401@errno.com> In-Reply-To: <200612301934.48381.joao@matik.com.br> References: <200612282002.11562.joao@matik.com.br> <200612282241.24542.joao@matik.com.br> <4596CC31.6010604@errno.com> <200612301934.48381.joao@matik.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
JoaoBR wrote: > On Saturday 30 December 2006 18:29, Sam Leffler wrote: >> See my previous reply to you. Lamont is directing you to look for >> stations in your network operating with power save enabled. >> > > even if there are stations with powersaving on we can do anything against it > > this is an ISP environment where people connect with compatible hardware, I do > not agree that power management enabled on some of them could bring the > network down Sorry I don't understand your comment. Noone has ever said having power save enabled in client sta's should be permitted to cause an ap to stop proper operation. > > > >>> But I saw histories about this and even if powersaving issue "was the >>> issue in that case(really?)" I think this is wierd in any way because if >>> ONE station with powersaving on could set the AP in DoS ... man ... if >>> really true this is kind of lame excuse or kind of driver weakness which >>> both would be inacceptable, and, if it does NOT wake up if in sleep state >>> ... no further comment, but a driver weakness right? >> Power save operation is a required part of 802.11. If there's a problem >> in supporting it then it should be fixed but I'm aware of several ap >> products shipping with freebsd that do not exhibit this problem so it >> may be related to your configuration. ath parts offload much processing >> to the host and creating a production quality ap based on them involves >> certain tuning and configuration that must be done according to the >> complete system. > > I know and as far as our knowledge goes (in fact there are no secrets to > disable powersaving) we do not have this problem and like I said before in > the former msg that I believe the problem is related to a certain kind of > traffic > > >> If you are saying you should not have to reboot a system because the >> device locks up then sure. But I've no idea if that was what was >> required. I'm aware of only one ath-related issue that can lockup a >> system--that's when a part is set into deep sleep and the host then >> accesses a register outside the pci clock domain w/o first waking up the >> part. This has only been reported with cardbus cards which means you >> can just eject the card to unfreeze the bus. But this sounds unrelated >> to the problem you are seeing. >> > > ok, but again our Ap is not in any power save mode, we monitor CPU, fan, temp > and traffic and to complete the powersaving issue, it is unlikely that the > freeBSD goes to sleep when I get considerable traffic through this box and > especially the ath card I guess you still don't understand what 802.11 power save operation means. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45972F7B.4060401>