[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Peter Stuge]

Today when I came home and resumed my system I got these messages
from the driver:

[302214.156400] phy1: device no longer idle - scanning
[302214.341494] ath: ath_isr status=00000009 imask=f4001071 wecare=00000001
[302214.341983] ath: ath_isr status=01000009 imask=f4001071 wecare=00000001
[302214.345578] ath: ath_isr status=20000008 imask=f4001071 wecare=20000000
[302214.359875] ath: Failed to stop TX DMA in 100 msec after killing last frame
[302214.359900] ath: Unable to stop TxDMA. Reset HAL!
[302214.364010] phy1: device now idle

I didn't save messages from the suspend. (And, those ath_isr messages
were added by me to aid debugging the disconnect issue.)

I unloaded and reloaded the driver and could connect again.

(A few hours later I was disconnected as per my previous thread. Oh,
and a friend with a 92xx generation ath9k also experiences similar
disconnect issues under a little load. But that's another thread.)


//Peter

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Luis R. Rodriguez]

On Mon, Jan 18, 2010 at 06:31:19PM -0800, Peter Stuge wrote:
> Today when I came home and resumed my system I got these messages
> from the driver:
> 
> [302214.156400] phy1: device no longer idle - scanning
> [302214.341494] ath: ath_isr status=00000009 imask=f4001071 wecare=00000001
> [302214.341983] ath: ath_isr status=01000009 imask=f4001071 wecare=00000001
> [302214.345578] ath: ath_isr status=20000008 imask=f4001071 wecare=20000000
> [302214.359875] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [302214.359900] ath: Unable to stop TxDMA. Reset HAL!
> [302214.364010] phy1: device now idle
> 
> I didn't save messages from the suspend. (And, those ath_isr messages
> were added by me to aid debugging the disconnect issue.)
> 
> I unloaded and reloaded the driver and could connect again.
> 
> (A few hours later I was disconnected as per my previous thread. Oh,
> and a friend with a 92xx generation ath9k also experiences similar
> disconnect issues under a little load. But that's another thread.)

What kernel? You should try to use the latest stable. At this point that is
the 2.6.32 kernel release, if you want to stick to an older kernel you can use
compat-wireless:

http://wireless.kernel.org/en/users/Download/stable/

  Luis

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Benoit PAPILLAULT]

Luis R. Rodriguez a ?crit :
> On Mon, Jan 18, 2010 at 06:31:19PM -0800, Peter Stuge wrote:
>   
>> Today when I came home and resumed my system I got these messages
>> from the driver:
>>
>> [302214.156400] phy1: device no longer idle - scanning
>> [302214.341494] ath: ath_isr status=00000009 imask=f4001071 wecare=00000001
>> [302214.341983] ath: ath_isr status=01000009 imask=f4001071 wecare=00000001
>> [302214.345578] ath: ath_isr status=20000008 imask=f4001071 wecare=20000000
>> [302214.359875] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> [302214.359900] ath: Unable to stop TxDMA. Reset HAL!
>> [302214.364010] phy1: device now idle
>>
>> I didn't save messages from the suspend. (And, those ath_isr messages
>> were added by me to aid debugging the disconnect issue.)
>>
>> I unloaded and reloaded the driver and could connect again.
>>
>> (A few hours later I was disconnected as per my previous thread. Oh,
>> and a friend with a 92xx generation ath9k also experiences similar
>> disconnect issues under a little load. But that's another thread.)
>>     
>
> What kernel? You should try to use the latest stable. At this point that is
> the 2.6.32 kernel release, if you want to stick to an older kernel you can use
> compat-wireless:
>
> http://wireless.kernel.org/en/users/Download/stable/
>
>   Luis
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>   
I am seeing this as well on 2.6.33-rc4-wl, but only at unload time 
(modprobe -r ath9k).

Regards,
Benoit

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Peter Stuge]

Luis R. Rodriguez wrote:
> > [302214.359875] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > [302214.359900] ath: Unable to stop TxDMA. Reset HAL!
> 
> What kernel?

The one that I reported using in the disconnect thread. I'll repeat
in this thread. Sorry that I forgot to mention it.

Merge commit 'wireless-testing/master' as of 2010-01-14

My last is:

commit a30ce7f35fbb5643b1e67051b55fb874ed19936a
Merge: e384cc6 7284ce6
Author: John W. Linville <linville@tuxdriver.com>
Date:   Wed Jan 13 11:23:51 2010 -0500

    Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

$ uname -r
2.6.33-rc4-wl


> You should try to use the latest stable.

Your constant suggestion that people should not use the very latest
code absolutely baffles me. Or do you mean to say "this is a known
regression" ?


> if you want to stick to an older kernel

No, for f's sake, I want the very same commit that all the developers
are working on, so that I have all recent fixes and so that the code
that runs here is the same as the code they have loaded in their
heads. I don't understand why it would be better to run older code!


When posting on this mailing list my attitude is that this is a
developer discussion group for the ath9k driver and that unreported
issues will be met with enthousiasm, so that developers can get
detailed input on unforeseen ways that the driver might fail in the
field, so that the driver can be improved. Repeat until perfect.

I find that it is always more effective when people who cooperate
have a common ground - like using the same code. That is an ideal I
strive for when I work. It seems to be common in most open source
projects too, where a bug only in older code is not really worth
spending much effort on, unless it also exists in the latest code.

I am amazed that you continue to instruct people to use old kernels.

Maybe it is important to point out that I am not the least bit
interested in avoiding the symptoms that I am seeing. My only
interest is that the problems which actually _cause_ the symptoms are
understood and solved.

During this process I am willing to accept some degree of performance
loss as long as I have something that works well enough, and more
importantly as long as I know that the problem is actually being
considered by those who can suggest solutions.

If noone cares enough about the problems then please communicate this,
and I will gladly try to find other products.

I'm also a competent engineer, so if there is technical information
that I can use to debug the problems on my own then that is also very
welcome.

I don't think "run older code" is the answer.


//Peter

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Luis R. Rodriguez]

On Tue, Jan 19, 2010 at 5:04 PM, Peter Stuge <peter@stuge.se> wrote:
> Luis R. Rodriguez wrote:
>> > [302214.359875] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> > [302214.359900] ath: Unable to stop TxDMA. Reset HAL!
>>
>> What kernel?
>
> The one that I reported using in the disconnect thread. I'll repeat
> in this thread. Sorry that I forgot to mention it.
>
> Merge commit 'wireless-testing/master' as of 2010-01-14
>
> My last is:
>
> commit a30ce7f35fbb5643b1e67051b55fb874ed19936a
> Merge: e384cc6 7284ce6
> Author: John W. Linville <linville@tuxdriver.com>
> Date: ? Wed Jan 13 11:23:51 2010 -0500
>
> ? ?Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> $ uname -r
> 2.6.33-rc4-wl
>
>
>> You should try to use the latest stable.
>
> Your constant suggestion that people should not use the very latest
> code absolutely baffles me. Or do you mean to say "this is a known
> regression" ?

There is a difference between latest and greatest and latest stable.
Bleeding edge is unstable by nature, but users of it are welcomed. If
a user wants stability they would surely be better off with a stable
release.

>> if you want to stick to an older kernel
>
> No, for f's sake, I want the very same commit that all the developers
> are working on, so that I have all recent fixes and so that the code
> that runs here is the same as the code they have loaded in their
> heads. I don't understand why it would be better to run older code!
>
>
> When posting on this mailing list my attitude is that this is a
> developer discussion group for the ath9k driver and that unreported
> issues will be met with enthousiasm, so that developers can get
> detailed input on unforeseen ways that the driver might fail in the
> field, so that the driver can be improved. Repeat until perfect.
>
> I find that it is always more effective when people who cooperate
> have a common ground - like using the same code. That is an ideal I
> strive for when I work. It seems to be common in most open source
> projects too, where a bug only in older code is not really worth
> spending much effort on, unless it also exists in the latest code.
>
> I am amazed that you continue to instruct people to use old kernels.

But I'm not. I assume the worst sometimes, that users are on ancient
crippled old kernels.

> Maybe it is important to point out that I am not the least bit
> interested in avoiding the symptoms that I am seeing. My only
> interest is that the problems which actually _cause_ the symptoms are
> understood and solved.
>
> During this process I am willing to accept some degree of performance
> loss as long as I have something that works well enough, and more
> importantly as long as I know that the problem is actually being
> considered by those who can suggest solutions.
>
> If noone cares enough about the problems then please communicate this,
> and I will gladly try to find other products.
>
> I'm also a competent engineer, so if there is technical information
> that I can use to debug the problems on my own then that is also very
> welcome.
>
> I don't think "run older code" is the answer.

Indeed, but bleeding edge is unstable by nature, so if a user wants
stability I recommend the stable kernels, if a user is up to deal with
a few hiccups here and there and report them to linux-wireless then
bleeding edge is better suited.

The fact that you are on bleeding edge actually does help for the
exact reasons you mentioned.

  Luis

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Sujith]

Benoit PAPILLAULT wrote:
> I am seeing this as well on 2.6.33-rc4-wl, but only at unload time
> (modprobe -r ath9k).

Yep, this happens because I changed the debug mask for that message to FATAL.
It is harmless, but can be fixed by cleaning up the virtual wiphy / idle stuff.

Sujith

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Peter Stuge]

Sujith wrote:
> Benoit PAPILLAULT wrote:
> > I am seeing this as well on 2.6.33-rc4-wl, but only at unload
> > time (modprobe -r ath9k).
> 
> Yep, this happens because I changed the debug mask for that message
> to FATAL. It is harmless, but can be fixed by cleaning up the
> virtual wiphy / idle stuff.

Maybe not completely harmless since it required me to reload driver
after a resume.


//Peter

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[yingqiang Ma]

On my machine when I encounter this issue, the wireless doesn't work any
more. My machine is running latest 2.6.32.7 as an AP on a ARM box.

2010/1/20 Sujith <Sujith.Manoharan@atheros.com>

> Benoit PAPILLAULT wrote:
> > I am seeing this as well on 2.6.33-rc4-wl, but only at unload time
> > (modprobe -r ath9k).
>
> Yep, this happens because I changed the debug mask for that message to
> FATAL.
> It is harmless, but can be fixed by cleaning up the virtual wiphy / idle
> stuff.
>
> Sujith
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20100204/96452c8b/attachment.htm 

[ath9k-devel] ath: Unable to stop TxDMA. Reset HAL!

[Peter Stuge]

yingqiang Ma wrote:
> 2010/1/20 Sujith <Sujith.Manoharan@atheros.com>
> > Yep, this happens because I changed the debug mask for that
> > message to FATAL.
> > It is harmless,

WTF?! Please make up your mind! Either it's FATAL, or it's harmless -
which is it?


> > but can be fixed by cleaning up the virtual wiphy / idle stuff.

Any proper fix would be nice of course.


> On my machine when I encounter this issue, the wireless doesn't
> work any more. My machine is running latest 2.6.32.7 as an AP on a
> ARM box.

Like on my system, as reported in my message that started this
thread, what - a month ago by now?


I have to say that I'm really disappointed by the absolute lack of
input from Atheros on this mailing list. WTF is going on - I thought
you wanted to do the Linux thing properly?


//Peter