Date: Sat, 30 Dec 2006 19:34:48 -0200 From: JoaoBR <joao@matik.com.br> To: Sam Leffler <sam@errno.com> Cc: freebsd-stable@freebsd.org, Lamont Granquist <lamont@scriptkiddie.org> Subject: Re: ath0 timeout problem - again Message-ID: <200612301934.48381.joao@matik.com.br> In-Reply-To: <4596CC31.6010604@errno.com> References: <200612282002.11562.joao@matik.com.br> <200612282241.24542.joao@matik.com.br> <4596CC31.6010604@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20 not agree that power management enabled on some of them could bring the=20 network down > > 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 sta= te > > ... 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=20 disable powersaving) we do not have this problem and like I said before in= =20 the former msg that I believe the problem is related to a certain kind of=20 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, te= mp=20 and traffic and to complete the powersaving issue, it is unlikely that the= =20 freeBSD goes to sleep when I get considerable traffic through this box and= =20 especially the ath card thank's =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612301934.48381.joao>