All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org
Cc: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Subject: [PATCH v6 0/3] ath9k: SMP fixes
Date: Thu, 12 Mar 2009 18:18:48 -0400	[thread overview]
Message-ID: <1236896331-5026-1-git-send-email-lrodriguez@atheros.com> (raw)

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(-)


WARNING: multiple messages have this Message-ID (diff)
From: Luis R. Rodriguez <lrodriguez@atheros.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH v6 0/3] ath9k: SMP fixes
Date: Thu, 12 Mar 2009 18:18:48 -0400	[thread overview]
Message-ID: <1236896331-5026-1-git-send-email-lrodriguez@atheros.com> (raw)

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(-)

             reply	other threads:[~2009-03-12 22:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 22:18 Luis R. Rodriguez [this message]
2009-03-12 22:18 ` [ath9k-devel] [PATCH v6 0/3] ath9k: SMP fixes Luis R. Rodriguez
2009-03-12 22:18 ` [PATCH v6 1/3] ath9k: implement IO serialization Luis R. Rodriguez
2009-03-12 22:18   ` [ath9k-devel] " Luis R. Rodriguez
2009-03-12 22:18 ` [PATCH v6 2/3] ath9k: AR9280 PCI devices must serialize IO as well Luis R. Rodriguez
2009-03-12 22:18   ` [ath9k-devel] " Luis R. Rodriguez
2009-03-12 22:18 ` [PATCH v6 3/3] ath9k: remove dummy PCI "retry timeout" fix Luis R. Rodriguez
2009-03-12 22:18   ` [ath9k-devel] " Luis R. Rodriguez
2009-03-13 21:29 ` [ath9k-devel] [PATCH v6 0/3] ath9k: SMP fixes Luis R. Rodriguez
2009-03-13 21:29   ` Luis R. Rodriguez
2009-03-13 22:02   ` [stable] " Greg KH
2009-03-13 22:02     ` [ath9k-devel] [stable] " Greg KH
2009-03-13 21:24     ` [stable] [ath9k-devel] " Luis R. Rodriguez
2009-03-13 21:24       ` [ath9k-devel] [stable] " Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1236896331-5026-1-git-send-email-lrodriguez@atheros.com \
    --to=lrodriguez@atheros.com \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.