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

[Peter Stuge <peter@stuge.se>]

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