On Tue, Jan 19, 2010 at 5:04 PM, Peter Stuge <pe...@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 <linvi...@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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
