On Fri, Jan 07, 2011 at 07:36:07AM -0800, Peter Stuge wrote: > Ben Greear wrote: > > > but at least other clueless users would not go over stable limit > > > you have found. > > > > I think it's very likely that the problems I find are general > > issues that are just much easier to hit with lots of stations. > > I strongly support this. I recognize several of your problems from my > attempts at using ath9k with only a single STA which was all but stable. Sure, see my other e-mail. > > There is probably no 'safe' number of stations...just takes longer > > to see bugs with fewer stations. > > > > For instance, you still see the failure-to-stop-DMA errors with a > > single station, right? And the tx locking stuff was just easier to > > exercise with lots of stations, but it would have been possible to > > hit it with 2 stations. > > > > The current tx-hang stuff I'm chasing seems like logic bugs in the > > queueing, probably nothing in particular about the chipset. > > This is also my impression. Since it is important for Atheros to have > bugzilla reports rather than discussion on list I'm trying to tell you how you can more efficiently work with developers on reporting issues, I'm not singling you out but I am telling you that the energy you spend on complaining on things not being addressed can be better put on reporting issues more efficiently. Reporting issues on the list helps but what helps is a describin the issue for a specific release but the most difficult thing to do sometimes is to come up with a recipe for a way to reproduce a specific issue. Without this it is harder to debug issues. If you can come up with ways to reproduce issues then it becomes easier for engineers to start digging. Additionally if an issue is seen that was not observed before the reporter may also do a git bisect to try to identify the culprit commit. Be aware though that bisecting on wireless-testing can only be done against the master-* tags, and not on the entire tree due to the way John updates his tree. If you see the issue on a stable kernel though you can just use Linus' tree or the linux-2.6-allstable git tree which will have the stable extra versioned kernels as well. Reporting issues for stable kernels should go through the kernel bugzilla, but can start off on the mailing list. ath9k-devel though is not ideal for reporting major issues and I recommend linux-wireless to be used instead for that. If an issue is reporting for wireless-testing with a good series of reproducible steps chances are very high it will be addressed. Motivated highly technical users willing to help further get bonus points if they go the extra mile and bisect. Furthermore, issues can be kept track on here: http://wireless.kernel.org/en/users/Drivers/ath9k/bugs This keeps track of major issues reported, and what people are working on. > I will try to find > time for creating more and/or new bug reports about my problems. Good, the bug reports will not be necessary if the issue is not on a stable kernel as it will just be a regression against the last stable kernel. If the issue is seen on a > (But the ones I have created so far did not really receive very good > response.) Try to increase the quality of your reports and I assure you that your issues will be addressed. > Note that my AR9280 is not even detected correctly on PCI now so I > may switch back to AR5008 for that. > > I really should try out FreeBSD too. Good luck with that ;) Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
