ath0 timeout problem - again

JoaoBR joao at matik.com.br
Sat Dec 30 14:34:52 PST 2006


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



> > 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

thank's

-- 

João







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br


More information about the freebsd-stable mailing list