Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Fri, Jan 07, 2011 at 12:01:01PM -0800, Luis Rodriguez wrote:
> 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'll also note:

http://wireless.kernel.org/en/users/Documentation/Reporting_bugs

If this needs update feel free to edit. The hope is to make it easier for
users to identify issues and report them properly.

  Luis