Re: ath0 timeout problem - again

JoaoBR wrote:
On Thursday 28 December 2006 21:52, you wrote:
check this message:

http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031216.html

run "/usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power" and
see if one of the hosts on your wlan has powersaving turned on.

"stops forever" was not one of my symptoms though, so your issue may be
different...



thank's for your answer
powersaving is not the issue here because it's off

See my previous reply to you. Lamont is directing you to look for
stations in your network operating with power save enabled.


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.


wether powersaving is on or not on the station/client is a local setting to
this station and must not influence any remote computer in any way, imagine,
you turn on your powersavings and the complete internet goes down on your
request hihihihi :)

but then, like my case, on the AP or better ath in ap mode, even IF
powersaving is ON it might stop working for any related reason but firstable
NOT WHILE TX/RX and secondable if idle it must return soon THIS computer
wants to transmit any kind of traffic again

last but not least powersaving might shut the power down but must return when
necessary - if not - there is a driver problem.

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.

Sam
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"