ath9k fellows,
as it seems no one could find the cause for this problem so far. I'd therefore
like to create a workaround by checking one/some registers for 0xdeadbeef and
reset the chip if this is found.
Can anyone recommend a register which should never go 0xdeadbeef in a normal
case?
From
It'll only go into that mode if that core is off for some reason.
So sure, do that and try to turn the radio off/on :-)
adrian
On 13 September 2012 09:51, Simon Wunderlich
simon.wunderl...@s2003.tu-chemnitz.de wrote:
ath9k fellows,
as it seems no one could find the cause for this problem
Hi Simon/Sven,
I'm living at a small village, and one or two neighbors may have access
points too,
but that's it - this should be far from beeing busy. We mostly use these APs
for
surfing with smart phones, this is also far from congesting them. ;)
TBH I don't really understand what you
I don't think it's a stuck beacon WAR issue here; 0xdeadbeef really
does read like the MAC has gone to sleep.
Where's the complete register dump hiding?
Adrian
On 4 September 2012 22:12, Mohammed Shafi shafi.wirel...@gmail.com wrote:
Hi Simon/Sven,
I'm living at a small village, and one
On Wednesday 05 September 2012 07:08:47 Adrian Chadd wrote:
I don't think it's a stuck beacon WAR issue here; 0xdeadbeef really
does read like the MAC has gone to sleep.
Where's the complete register dump hiding?
It was not sent to the public mailing lists due to the size. You will receive
On Monday 03 September 2012 19:23:26 Mohammed Shafi wrote:
# dmesg
[...]
[900132.16] ath: phy0: NF calibrated [ext] [chain 0] is -104
[900162.16] ath: phy0: NF calibrated [ctl] [chain 0] is -104
[900162.16] ath: phy0: NF calibrated [ext] [chain 0] is -104
[900192.16]
Hey guys,
now, finally after approx. 9 days the problem hit us again, this time with
debug enabled.
The symptoms are the same as described before. I'm pasting part of the syslog
of routers
200 and 201 where the calibrating output changes - this is the only thing I
could find
which was really
