[ath9k-devel] Dirty Laundry List

[ath9k-devel] Dirty Laundry List

[Luis R. Rodriguez]

Moving this discussion out to the public list. Guys this is our
latest TODO list. We welcome people from the community to take up items
here, but please let us know if you are going to work on something.

I'll be tackling the MacBook pro swiotlb issue, I think this should be
fixed now, but not sure, needs a MacBook Pro 3.1 tester. I also already
started working on the ath9k regulatory scrub. Essentially we'll be
relying on CRDA for 11d instead of the EEPROM so this is a huge major
cleanup. Also there is a lot of potential to share this work with ath5k
code. One option which Jouni suggested was a module we can share between
ath9k/ath5k, maybe some sort of ath_common.ko or the like and first
stash in there reg stuff. Maybe later add more shared stuff as we go.

On Thu, Nov 20, 2008 at 08:22:21AM -0800, Sujith Manoharan wrote:
> Hi,
> 
> So more dirty linen to be washed, and here it is.
> 
> Issues/Bugs:
> 
> * PCI/DMA suckage ( SWIOTLB issue on macbooks )

Taken, need a MacBook pro 3.1 tester.

> * Fix xmit ( there is still a difference between xmit and recv )
>   (I don't see the difference in UDP, only in TCP)
> * TX/RX Hang
>   (I run into TX/RX hang after running Iperf for some time, no idea as to what's happening)
> * Fix convoluted aggregation logic
>   (bf_lastbf, bf_lastfrm, bf_next, bf_rifslast, buf_q, tid_q, axq_acq ...)
> * Fix Channel setting mess
>   (Racy, calculation of HT parameters is buggy)
> * RC scaling
>   (More analysis/optimization needs to be done here)
> * Fix probe/auth timeout issues
> * Fix HT handling mess
>   (reassociation with HT40 is a problem, switching between legacy/HT APs fails occasionally too)
> * Fix locking
>   (Yeah, right, like we have locking to begin with)
> * Throughput with legacy APs suck, analyze this
>   (Compare with Minstrel for legacy mode ?)
> * AR5416 based cards show lower throughput numbers than AR9280 and above. Fix this.
> * Handle PCI suspend/resume callbacks properly
> * Check ANI
>   (Does it work ?)
> * WTF is Slow Antenna Diversity and why have we not done anything to enable it so far ?
> * Lots of code for chainmask handling is present ( timers etc.), what are we doing with all that ?
> * Lockdep warning on ath_tid_drain() when association is lost and we try to clean up
> 
> Cleanup love:
> 
> * http://wireless.kernel.org/en/users/Drivers/ath9k
> 
> Major Items ( I know, we keep listing these again and again ):
> * 11d (Regulatory Scrub)

Taken.

> * 11h
> * SoftAP
> * Power Save (legacy)
> * BT Coex
> 
> Sujith
> 
> 

[ath9k-devel] Dirty Laundry List

[Alistair John Strachan]

On Thursday 20 November 2008 19:32:47 Luis R. Rodriguez wrote:
[snip]
> > * PCI/DMA suckage ( SWIOTLB issue on macbooks )
>
> Taken, need a MacBook pro 3.1 tester.

Why does this have to be a MacBook Pro 3.1? If the ath9k driver's got swiotlb 
issues it should be possible to use any supported hardware in combination with 
the sw-iommu right? The IOMMU can be forced on with machines less than ~4GB, 
so just about anybody could test it.

If any of the above is correct, I've got a machine I could test the fix on.

-- 
Cheers,
Alistair.

[ath9k-devel] Dirty Laundry List

[Luis R. Rodriguez]

On Thu, Nov 20, 2008 at 03:23:19PM -0800, Alistair John Strachan wrote:
> On Thursday 20 November 2008 19:32:47 Luis R. Rodriguez wrote:
> [snip]
> > > * PCI/DMA suckage ( SWIOTLB issue on macbooks )
> >
> > Taken, need a MacBook pro 3.1 tester.
> 
> Why does this have to be a MacBook Pro 3.1? If the ath9k driver's got swiotlb
> issues it should be possible to use any supported hardware in combination with
> the sw-iommu right? The IOMMU can be forced on with machines less than ~4GB,
> so just about anybody could test it.

You would think right!? Have you seen the bug report?

http://bugzilla.kernel.org/show_bug.cgi?id=11811

> If any of the above is correct, I've got a machine I could test the fix on.

I've been testing on iommu=soft swiotlb=force mem=4G while doing all
sorts of other memory intensive DMA things but no luck. So something is
peculiar about the MacBook pro 3.1. So we have patches now, so what we
need is to see if it still occurs with such patches. If anyone has a
MacBook pro 3.1 and is willing to test please let me know.

  Luis

[ath9k-devel] Dirty Laundry List

[Alistair John Strachan]

On Thursday 20 November 2008 23:28:47 Luis R. Rodriguez wrote:
> On Thu, Nov 20, 2008 at 03:23:19PM -0800, Alistair John Strachan wrote:
[snip]
> > Why does this have to be a MacBook Pro 3.1? If the ath9k driver's got
> > swiotlb issues it should be possible to use any supported hardware in
> > combination with the sw-iommu right? The IOMMU can be forced on with
> > machines less than ~4GB, so just about anybody could test it.
>
> You would think right!? Have you seen the bug report?
>
> http://bugzilla.kernel.org/show_bug.cgi?id=11811

No, very interesting! Fortunately I was able to reproduce the problem on my 
2GB RAM Macbook v2, despite the experiences you guys have had.

I built a kernel (2.6.28-rc5) with SWIOTLB set, and then booted with 
"iommu=soft swiotlb=force mem=512M" and then copied a TV show onto the laptop 
from another computer. It broke almost instantly (and took some of my data 
with it :-)).

[snip]
> So we have patches now, so what we
> need is to see if it still occurs with such patches. If anyone has a
> MacBook pro 3.1 and is willing to test please let me know.

I applied the patches, re-ran my test case, and half a gig later the problem 
seems to be gone. So if this is any use to you at all I'd say it's fixed by 
those patches, which do make a lot of sense.

The driver tested was the one in 2.6.28-rc5. I had to apply the patch manually 
because the driver in 2.6.28-rc5 is formatted in a substantially different 
way. No functional differences afaict.

-- 
Cheers,
Alistair.