On Fri, Mar 13, 2009 at 03:02:59PM -0700, Greg KH wrote: > On Fri, Mar 13, 2009 at 02:29:08PM -0700, Luis R. Rodriguez wrote: > > On Thu, Mar 12, 2009 at 3:18 PM, Luis R. Rodriguez > > <lrodriguez@xxxxxxxxxxx> wrote: > > > This v6 removes the hotplug CPU stuff which although it technically > > > would be correct is more cruft and highly unlikely. The down side > > > is you will get serialization applied even if you only have one > > > CPU but who cares, I doubt those nutty SGI guys are toying with > > > ath9k in the lab. > > > > > > Yesterday I started mucking with an alternative approach to > > > serialization which worked. I added just 5 udelay()s in key places > > > where we had a lot of consecutive IO read/writes issued and that > > > resolved the issue at least for STA mode but it didn't do the trick > > > for AP mode. Technically it should be possible to groom all hardware > > > access routines to do the same but I'm tired of this issue and want > > > to a fix merged today not a few weeks from now. Anyway if you are > > > curious you can check out that patch replacement approach for > > > serialization here: > > > > > > http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-03-12/smp-udelay-fix.patch > > > > > > Note that AP won't work though so if you have a lot of time in your > > > hands and have an SMP box with PCI Atheros 11n and are seeing the hangs > > > and want a neat alternative to the current serialization implementation > > > try adding udelays like the ones in the patch in places where we do a lot > > > of io read/writes. Send me the results :) > > > > > > The compromise is to keep serialization conditional -- we do not want to > > > do it for every read/write regardless of the type of card you have, the > > > code overhead is not great and we maintain this anyway. Adding it for all > > > cases would just not be optimal. > > > > > > Luis R. Rodriguez (3): > > > ath9k: implement IO serialization > > > ath9k: AR9280 PCI devices must serialize IO as well > > > ath9k: remove dummy PCI "retry timeout" fix > > > > > > drivers/net/wireless/ath9k/ath9k.h | 34 ++++++++++++++++++++++++++++++++++ > > > drivers/net/wireless/ath9k/hw.c | 28 +++++++++++++++++++++++++++- > > > drivers/net/wireless/ath9k/hw.h | 4 ++-- > > > drivers/net/wireless/ath9k/main.c | 1 + > > > drivers/net/wireless/ath9k/pci.c | 18 ------------------ > > > 5 files changed, 64 insertions(+), 21 deletions(-) > > > > John, Greg, > > > > these patches require a port down to the other stable kernels, I've > > taken the time to port only the necessary patches (the first two) to > > fix the SMP hang on each stable kernel and test them accordingly: > > > > * 2.6.27 > > * 2.6.28 > > * 2.6.29 > > > > Once merged into wireless-testing the following patches can be used to > > push into Linus' tree: > > > > http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-03-12/serialization-v6/for-2.6.29/ > > > > Once merged into stable these can be used to merge into 2.6.27 and 2.6.28: > > > > http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-03-12/serialization-v6/for-2.6.27/ > > http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-03-12/serialization-v6/for-2.6.28/ > > > > Just replace: > > > > This is a port of commit SHA1 <BLEH> > > > > With the respective SHA1. > > > > I can also simply resend the ports for 27 and 28 once merged into > > Linus' tree. Whatever makes it easier for you. > > Please, when the patches go into Linus's tree, send stable@xxxxxxxxxx > the backported patches, with the proper git commit id in them. > > Otherwise it's just too much confusing work for me and I'll easily mess > it up. The number of -stable patches is increasing and I need all the > help I can get in handling this in a sane manner :) Sure will do thanks, 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
