ath0 timeout problem - again

[Sam Leffler]

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