* [PATCH] ath9k: claim irq for ath9k, not ath for pci
From: Luis R. Rodriguez @ 2009-09-03 0:06 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
ath9k ahb requests an IRQ and indicates 'ath9k' claimed it,
ath9k pci requests an IRQ and indicates 'ath' claims it;
since 'ath' is another module sync both ahb and pci to claim
the irq using 'ath9k'.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index bc4bc2c..8bb286d 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -187,7 +187,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
/* setup interrupt service routine */
- ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath", sc);
+ ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
if (ret) {
dev_err(&pdev->dev, "request_irq failed\n");
goto bad4;
--
1.6.3.3
^ permalink raw reply related
* [ANN] rfkill: v0.3
From: wireless @ 2009-09-03 3:10 UTC (permalink / raw)
To: linux-wireless
A new release of rfkill (v0.3) is available at:
http://wireless.kernel.org/download/rfkill/rfkill-0.3.tar.bz2
SHA1 sum: db559ef788af5cd996fa70c0b12507559f5ce257
Here is the short log of the changes included in this
release:
Johannes Berg (4):
add copyright notices
remove copyright notice from file
resync rfkill.h with kernel
version 0.3
^ permalink raw reply
* 802.11a multicast rate setting
From: Jinsung Lee @ 2009-09-03 3:38 UTC (permalink / raw)
To: linux-wireless
Hi, everyone.
If using ath5k or ath9k when the WLAN card supports 802.11a mode, is it
possible to change multicast (or broadcast) rate into under 6Mbps, like the
case of 802.11b mode?
e.g. 1Mbps or 2Mbps.
Thank you and best regards,
----
Jinsung Lee
^ permalink raw reply
* [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak reports
From: Luis R. Rodriguez @ 2009-09-03 6:11 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
This was giving false positives. We use eventually free this
through kref_put(), things are not so obvious through
cfg80211_bss_update().
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/wireless/scan.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 19c5a9a..79f7a5d 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -495,6 +495,9 @@ cfg80211_inform_bss(struct wiphy *wiphy,
kref_init(&res->ref);
+ /* cfg80211_bss_update() eats up res - we ensure we free it there */
+ kmemleak_ignore(res);
+
res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
if (!res)
return NULL;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] ath9k: Fix RX Filter handling for BAR
From: Sujith @ 2009-09-03 6:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
BAR frames have to be sent to mac80211 only if the
current channel is HT. Also, move the macro to
enum ath9k_rx_filter.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 3 ++-
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +++
drivers/net/wireless/ath/ath9k/reg.h | 1 -
5 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 71f27f3..011b14f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3967,7 +3967,8 @@ void ath9k_hw_setrxfilter(struct ath_hw *ah, u32 bits)
{
u32 phybits;
- REG_WRITE(ah, AR_RX_FILTER, (bits & 0xffff) | AR_RX_COMPR_BAR);
+ REG_WRITE(ah, AR_RX_FILTER, bits);
+
phybits = 0;
if (bits & ATH9K_RX_FILTER_PHYRADAR)
phybits |= AR_PHY_ERR_RADAR;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 7b39822..f56e77d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -568,6 +568,7 @@ enum ath9k_rx_filter {
ATH9K_RX_FILTER_PROBEREQ = 0x00000080,
ATH9K_RX_FILTER_PHYERR = 0x00000100,
ATH9K_RX_FILTER_MYBEACON = 0x00000200,
+ ATH9K_RX_FILTER_COMP_BAR = 0x00000400,
ATH9K_RX_FILTER_PSPOLL = 0x00004000,
ATH9K_RX_FILTER_PHYRADAR = 0x00002000,
ATH9K_RX_FILTER_MCAST_BCAST_ALL = 0x00008000,
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index c2efdf2..b1d189c 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2433,7 +2433,7 @@ static void ath9k_configure_filter(struct ieee80211_hw *hw,
ath9k_hw_setrxfilter(sc->sc_ah, rfilt);
ath9k_ps_restore(sc);
- DPRINTF(sc, ATH_DBG_CONFIG, "Set HW RX filter: 0x%x\n", sc->rx.rxfilter);
+ DPRINTF(sc, ATH_DBG_CONFIG, "Set HW RX filter: 0x%x\n", rfilt);
}
static void ath9k_sta_notify(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 52e62da..ec0abf8 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -423,6 +423,9 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
if (sc->rx.rxfilter & FIF_PSPOLL)
rfilt |= ATH9K_RX_FILTER_PSPOLL;
+ if (conf_is_ht(&sc->hw->conf))
+ rfilt |= ATH9K_RX_FILTER_COMP_BAR;
+
if (sc->sec_wiphy || (sc->rx.rxfilter & FIF_OTHER_BSS)) {
/* TODO: only needed if more than one BSSID is in use in
* station/adhoc mode */
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 3ddb243..e5c29eb 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1325,7 +1325,6 @@ enum {
#define AR_CFP_VAL 0x0000FFFF
#define AR_RX_FILTER 0x803C
-#define AR_RX_COMPR_BAR 0x00000400
#define AR_MCAST_FIL0 0x8040
#define AR_MCAST_FIL1 0x8044
--
1.6.4.2
^ permalink raw reply related
* [PATCH 2/2] ath9k: Fix channelFlags for 2GHZ
From: Sujith @ 2009-09-03 6:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
CHANNEL_G has to be set for 2GHZ channels since
IS_CHAN_G() checks for this in channelFlags and not in
chanmode. To make things messier, ath9k_hw_process_ini()
checks for CHANNEL_G in chanmode and not in channelFlags.
The supreme, brain-searing fix is to set the
flag in both cases.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index b1d189c..a69fda8 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1879,7 +1879,7 @@ void ath9k_update_ichannel(struct ath_softc *sc, struct ieee80211_hw *hw,
if (chan->band == IEEE80211_BAND_2GHZ) {
ichan->chanmode = CHANNEL_G;
- ichan->channelFlags = CHANNEL_2GHZ | CHANNEL_OFDM;
+ ichan->channelFlags = CHANNEL_2GHZ | CHANNEL_OFDM | CHANNEL_G;
} else {
ichan->chanmode = CHANNEL_A;
ichan->channelFlags = CHANNEL_5GHZ | CHANNEL_OFDM;
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak reports
From: Johannes Berg @ 2009-09-03 7:26 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1251958266-10692-1-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Thu, 2009-09-03 at 02:11 -0400, Luis R. Rodriguez wrote:
> This was giving false positives. We use eventually free this
> through kref_put(), things are not so obvious through
> cfg80211_bss_update().
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> net/wireless/scan.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> index 19c5a9a..79f7a5d 100644
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -495,6 +495,9 @@ cfg80211_inform_bss(struct wiphy *wiphy,
>
> kref_init(&res->ref);
>
> + /* cfg80211_bss_update() eats up res - we ensure we free it there */
> + kmemleak_ignore(res);
> +
> res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
> if (!res)
> return NULL;
That's not making sense. cfg80211_bss_update() doesn't actually take a
reference, it adds a new one for itself and then we return one to the
caller. Why can it not track this?
Actually it looks like we do leak one in net/mac80211/ibss.c.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ar6k driver
From: Werner Almesberger @ 2009-09-03 7:07 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Luis Rodriguez, Len.Widra, linux-wireless
In-Reply-To: <43e72e890909021518s411c3e0ap2ec94f9ff6c01b68@mail.gmail.com>
Luis R. Rodriguez wrote:
> Hm, seems origin/andy-tracking branch is gone:
Oh, sorry. That's what I get for copying and pasting the first
thing grep finds :-(
The correct git is this one:
git://git.openmoko.org/git/kernel.git
openmoko.git is indeed something entirely different, sorry.
- Werner
^ permalink raw reply
* [PATCH] Staging: stlc45xx: fix usage of mac80211 workqueue
From: Alexander Beregalov @ 2009-09-03 9:50 UTC (permalink / raw)
To: lrodriguez, linville, linux-wireless; +Cc: linux-kernel, Alexander Beregalov
See commit 42935ecaf(mac80211: redefine usage of the mac80211
workqueue).
Fix build error.
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
---
drivers/staging/stlc45xx/stlc45xx.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/stlc45xx/stlc45xx.c b/drivers/staging/stlc45xx/stlc45xx.c
index 12d414d..9ec8bd1 100644
--- a/drivers/staging/stlc45xx/stlc45xx.c
+++ b/drivers/staging/stlc45xx/stlc45xx.c
@@ -1058,7 +1058,7 @@ static void stlc45xx_reset(struct stlc45xx *stlc)
stlc45xx_warning("resetting firmware");
stlc->fw_state = FW_STATE_RESET;
ieee80211_stop_queues(stlc->hw);
- queue_work(stlc->hw->workqueue, &stlc->work_reset);
+ ieee80211_queue_work(stlc->hw, &stlc->work_reset);
}
static void stlc45xx_work_tx_timeout(struct work_struct *work)
@@ -1489,7 +1489,7 @@ static irqreturn_t stlc45xx_interrupt(int irq, void *config)
stlc45xx_debug(DEBUG_IRQ, "IRQ");
- queue_work(stlc->hw->workqueue, &stlc->work);
+ ieee80211_queue_work(stlc->hw, &stlc->work);
return IRQ_HANDLED;
}
@@ -1568,7 +1568,7 @@ static int stlc45xx_wq_tx(struct stlc45xx *stlc)
}
list_add(&entry->tx_list, &stlc->tx_sent);
- queue_delayed_work(stlc->hw->workqueue,
+ ieee80211_queue_delayed_work(stlc->hw,
&stlc->work_tx_timeout,
msecs_to_jiffies(TX_TIMEOUT));
}
@@ -2132,7 +2132,7 @@ static int stlc45xx_op_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
ieee80211_stop_queues(stlc->hw);
}
- queue_work(stlc->hw->workqueue, &stlc->work);
+ ieee80211_queue_work(stlc->hw, &stlc->work);
spin_unlock_bh(&stlc->tx_lock);
--
1.6.4.1
^ permalink raw reply related
* [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Amit Kucheria @ 2009-09-03 11:42 UTC (permalink / raw)
To: List Linux Kernel; +Cc: linux-wireless, Amit Kucheria, Ivo van Doorn
USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
defined. Remove it from rt2500usb.
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2500usb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index ce75426..2e9fac7 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -2020,7 +2020,6 @@ static struct usb_device_id rt2500usb_device_table[] = {
/* Ralink */
{ USB_DEVICE(0x148f, 0x1706), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x148f, 0x2570), USB_DEVICE_DATA(&rt2500usb_ops) },
- { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x148f, 0x9020), USB_DEVICE_DATA(&rt2500usb_ops) },
/* Sagem */
{ USB_DEVICE(0x079b, 0x004b), USB_DEVICE_DATA(&rt2500usb_ops) },
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Ivo Van Doorn @ 2009-09-03 11:54 UTC (permalink / raw)
To: Amit Kucheria; +Cc: List Linux Kernel, linux-wireless
In-Reply-To: <1251978140-4992-1-git-send-email-amit.kucheria@canonical.com>
> USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
> defined. Remove it from rt2500usb.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
NACK
Users have reported that this is a valid rt2500usb ID. You can thank the
manufacturer of the dongle to produce dongles with the same USB ID but
with different chipsets.
Ivo
> ---
> drivers/net/wireless/rt2x00/rt2500usb.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
> index ce75426..2e9fac7 100644
> --- a/drivers/net/wireless/rt2x00/rt2500usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2500usb.c
> @@ -2020,7 +2020,6 @@ static struct usb_device_id rt2500usb_device_table[] = {
> /* Ralink */
> { USB_DEVICE(0x148f, 0x1706), USB_DEVICE_DATA(&rt2500usb_ops) },
> { USB_DEVICE(0x148f, 0x2570), USB_DEVICE_DATA(&rt2500usb_ops) },
> - { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt2500usb_ops) },
> { USB_DEVICE(0x148f, 0x9020), USB_DEVICE_DATA(&rt2500usb_ops) },
> /* Sagem */
> { USB_DEVICE(0x079b, 0x004b), USB_DEVICE_DATA(&rt2500usb_ops) },
> --
> 1.6.3.3
>
>
^ permalink raw reply
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Amit Kucheria @ 2009-09-03 12:27 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: List Linux Kernel, linux-wireless
In-Reply-To: <a32f33a40909030454y51905525g15a65cc8364b8eb5@mail.gmail.com>
On 09 Sep 03, Ivo Van Doorn wrote:
> > USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
> > defined. Remove it from rt2500usb.
> >
> > Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
> > Cc: Ivo van Doorn <IvDoorn@gmail.com>
>
> NACK
>
> Users have reported that this is a valid rt2500usb ID. You can thank the
> manufacturer of the dongle to produce dongles with the same USB ID but
> with different chipsets.
>
> Ivo
Interesting. On my laptop, without this patch both the drivers are loaded
(lsmod), rt2500usb aborts without allocating a device successfully but I am
unable to associate to the AP.
With the patch, I am atleast able to associate to the AP. Perhaps there is
some other side-effect.
Regards,
Amit
> > ---
> > drivers/net/wireless/rt2x00/rt2500usb.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
> > index ce75426..2e9fac7 100644
> > --- a/drivers/net/wireless/rt2x00/rt2500usb.c
> > +++ b/drivers/net/wireless/rt2x00/rt2500usb.c
> > @@ -2020,7 +2020,6 @@ static struct usb_device_id rt2500usb_device_table[] = {
> > /* Ralink */
> > { USB_DEVICE(0x148f, 0x1706), USB_DEVICE_DATA(&rt2500usb_ops) },
> > { USB_DEVICE(0x148f, 0x2570), USB_DEVICE_DATA(&rt2500usb_ops) },
> > - { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt2500usb_ops) },
> > { USB_DEVICE(0x148f, 0x9020), USB_DEVICE_DATA(&rt2500usb_ops) },
> > /* Sagem */
> > { USB_DEVICE(0x079b, 0x004b), USB_DEVICE_DATA(&rt2500usb_ops) },
> > --
> > 1.6.3.3
> >
> >
--
-------------------------------------------------------------------------
Amit Kucheria, Kernel Developer, Verdurent
-------------------------------------------------------------------------
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Mel Gorman @ 2009-09-03 12:49 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bartlomiej Zolnierkiewicz, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <43e72e890909021102g7f844c79xefccf305f5f5c5b6@mail.gmail.com>
On Wed, Sep 02, 2009 at 11:02:14AM -0700, Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> Zolnierkiewicz<bzolnier@gmail.com> wrote:
> > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> >>
> >> s/2.6.30/2.6.31-rc6/
> >>
> >> The issue has always been there but it was some recent change that
> >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> >
> > ipw2200 fix works fine but yesterday I got the following error while mounting
> > ext4 filesystem (mb_history is optional so the mount succeeded):
>
> OK so the mount succeeded.
>
> > EXT4-fs (dm-2): barriers enabled
> > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > EXT4-fs (dm-2): internal journal on dm-2:8
> > EXT4-fs (dm-2): delayed allocation enabled
> > EXT4-fs: file extents enabled
> > mount: page allocation failure. order:5, mode:0xc0d0
> > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > Call Trace:
> > [<c0394de3>] ? printk+0xf/0x14
> > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > [<c016a71b>] __get_free_pages+0xf/0x32
> > [<c01865cf>] __kmalloc+0x28/0xfa
> > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > [<c01f529d>] ext4_mb_init+0x392/0x460
> > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > [<c0239bc8>] ? snprintf+0x15/0x17
> > [<c01c0b26>] ? disk_name+0x24/0x69
> > [<c018ba63>] get_sb_bdev+0xda/0x117
> > [<c01e6711>] ext4_get_sb+0x13/0x15
> > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > [<c018adad>] do_kern_mount+0x33/0xbd
> > [<c019d0af>] do_mount+0x660/0x6b8
> > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > [<c019d168>] sys_mount+0x61/0x99
> > [<c0102908>] sysenter_do_call+0x12/0x36
> > Mem-Info:
> > DMA per-cpu:
> > CPU 0: hi: 0, btch: 1 usd: 0
> > Normal per-cpu:
> > CPU 0: hi: 186, btch: 31 usd: 0
> > Active_anon:25471 active_file:22802 inactive_anon:25812
> > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 489 489
> > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0
> > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > 57947 total pagecache pages
> > 878 pages in swap cache
> > Swap cache stats: add 920, delete 42, find 11/11
> > Free swap = 1016436kB
> > Total swap = 1020116kB
> > 131056 pages RAM
> > 4233 pages reserved
> > 90573 pages shared
> > 77286 pages non-shared
> > EXT4-fs: mballoc enabled
> > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> >
> > Thus it seems like the original bug is still there and any ideas how to
> > debug the problem further are appreciated..
> >
> > The complete dmesg and kernel config are here:
> >
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
>
> This looks very similar to the kmemleak ext4 reports upon a mount. If
> it is the same issue, which from the trace it seems it is, then this
> is due to an extra kmalloc() allocation and this apparently will not
> get fixed on 2.6.31 due to the closeness of the merge window and the
> non-criticalness this issue has been deemed.
>
I suspect the more pressing concern is why is this kmalloc() resulting in
an order-5 allocation request? What size is the buffer being requested?
Was that expected? What is the contents of /proc/slabinfo in case a buffer
that should have required order-1 or order-2 is using a higher order for
some reason.
> A patch fix is part of the ext4-patchqueue
> http://repo.or.cz/w/ext4-patch-queue.git
>
p.s. I'm will be offline until Tuesday so will not be initially very
responsive.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: John W. Linville @ 2009-09-03 11:55 UTC (permalink / raw)
To: Amit Kucheria; +Cc: List Linux Kernel, linux-wireless, Ivo van Doorn
In-Reply-To: <1251978140-4992-1-git-send-email-amit.kucheria@canonical.com>
On Thu, Sep 03, 2009 at 02:42:20PM +0300, Amit Kucheria wrote:
> USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
> defined. Remove it from rt2500usb.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
IIRC there are IDs that are used by different devices where rt73usb
covers one device and the rt2500usb covers another. Are you sure
this is not one of those?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Johannes Berg @ 2009-09-03 13:27 UTC (permalink / raw)
To: Amit Kucheria; +Cc: Ivo Van Doorn, List Linux Kernel, linux-wireless
In-Reply-To: <20090903122727.GA4465@matterhorn.verdurent.com>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Thu, 2009-09-03 at 15:27 +0300, Amit Kucheria wrote:
> On 09 Sep 03, Ivo Van Doorn wrote:
> > > USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
> > > defined. Remove it from rt2500usb.
> > >
> > > Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
> > > Cc: Ivo van Doorn <IvDoorn@gmail.com>
> >
> > NACK
> >
> > Users have reported that this is a valid rt2500usb ID. You can thank the
> > manufacturer of the dongle to produce dongles with the same USB ID but
> > with different chipsets.
> >
> > Ivo
>
> Interesting. On my laptop, without this patch both the drivers are loaded
> (lsmod), rt2500usb aborts without allocating a device successfully but I am
> unable to associate to the AP.
Sounds like the detection logic is somehow messing with the device, or
rt2500usb isn't actually freeing the device for rt73usb to bind?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Ivo Van Doorn @ 2009-09-03 14:18 UTC (permalink / raw)
To: John W. Linville; +Cc: Amit Kucheria, List Linux Kernel, linux-wireless
In-Reply-To: <20090903115521.GB12597@tuxdriver.com>
On Thu, Sep 3, 2009 at 1:55 PM, John W. Linville<linville@tuxdriver.com> wrote:
> On Thu, Sep 03, 2009 at 02:42:20PM +0300, Amit Kucheria wrote:
>> USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
>> defined. Remove it from rt2500usb.
>>
>> Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
>> Cc: Ivo van Doorn <IvDoorn@gmail.com>
>
> IIRC there are IDs that are used by different devices where rt73usb
> covers one device and the rt2500usb covers another. Are you sure
> this is not one of those?
Yes, I believe this particular ID was already discussed some time ago
on this list. This is one of the infamous duplicate IDs. (Fortunately not
one of those infamous Linksys devices with 5 different chipsets for the
same ID).
Ivo
^ permalink raw reply
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Ivo Van Doorn @ 2009-09-03 14:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: Amit Kucheria, List Linux Kernel, linux-wireless
In-Reply-To: <1251984455.3336.24.camel@johannes.local>
On Thu, Sep 3, 2009 at 3:27 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-09-03 at 15:27 +0300, Amit Kucheria wrote:
>> On 09 Sep 03, Ivo Van Doorn wrote:
>> > > USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
>> > > defined. Remove it from rt2500usb.
>> > >
>> > > Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
>> > > Cc: Ivo van Doorn <IvDoorn@gmail.com>
>> >
>> > NACK
>> >
>> > Users have reported that this is a valid rt2500usb ID. You can thank the
>> > manufacturer of the dongle to produce dongles with the same USB ID but
>> > with different chipsets.
>> >
>> > Ivo
>>
>> Interesting. On my laptop, without this patch both the drivers are loaded
>> (lsmod), rt2500usb aborts without allocating a device successfully but I am
>> unable to associate to the AP.
>
> Sounds like the detection logic is somehow messing with the device, or
> rt2500usb isn't actually freeing the device for rt73usb to bind?
That would be odd, I believe it is working with other devices with
duplicate ID's
where first rt2500usb is loaded and then rt73usb. As far as connecting to the
device, the first thing rt2x00 does is reading the EEPROM and checking the
chipset. So no registers are being written which could upset a rt73usb device.
Ivo
^ permalink raw reply
* [compat-2.6] readd netdev_ops backport to ipw2200.c
From: Hauke Mehrtens @ 2009-09-03 14:31 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
This fixes building of ipw2200.c for kernel < 2.6.29.
It was introduced in 203a12ff5a432e2ee4a83b38e698bff0dd4efead
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/patches/01-netdev.patch | 64 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/compat/patches/01-netdev.patch b/compat/patches/01-netdev.patch
index 767bcc9..6d37bb7 100644
--- a/compat/patches/01-netdev.patch
+++ b/compat/patches/01-netdev.patch
@@ -333,6 +333,70 @@ without creating a headache on maintenance of the pathes.
dev->ethtool_ops = &ipw2100_ethtool_ops;
dev->wireless_handlers = &ipw2100_wx_handler_def;
priv->wireless_data.libipw = priv->ieee;
+--- a/drivers/net/wireless/ipw2x00/ipw2200.c 2009-08-20 13:47:07.311291621 -0700
++++ b/drivers/net/wireless/ipw2x00/ipw2200.c 2009-08-20 13:47:07.783268230 -0700
+@@ -11623,6 +11623,7 @@
+ return NETDEV_TX_OK;
+ }
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29))
+ static const struct net_device_ops ipw_prom_netdev_ops = {
+ .ndo_open = ipw_prom_open,
+ .ndo_stop = ipw_prom_stop,
+@@ -11631,6 +11632,7 @@
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
+ };
++#endif
+
+ static int ipw_prom_alloc(struct ipw_priv *priv)
+ {
+@@ -11651,7 +11653,13 @@
+ memcpy(priv->prom_net_dev->dev_addr, priv->mac_addr, ETH_ALEN);
+
+ priv->prom_net_dev->type = ARPHRD_IEEE80211_RADIOTAP;
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29))
+ priv->prom_net_dev->netdev_ops = &ipw_prom_netdev_ops;
++#else
++ priv->prom_net_dev->open = ipw_prom_open;
++ priv->prom_net_dev->stop = ipw_prom_stop;
++ priv->prom_net_dev->hard_start_xmit = ipw_prom_hard_start_xmit;
++#endif
+
+ priv->prom_priv->ieee->iw_mode = IW_MODE_MONITOR;
+ SET_NETDEV_DEV(priv->prom_net_dev, &priv->pci_dev->dev);
+@@ -11679,6 +11687,7 @@
+
+ #endif
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29))
+ static const struct net_device_ops ipw_netdev_ops = {
+ .ndo_init = ipw_net_init,
+ .ndo_open = ipw_net_open,
+@@ -11689,6 +11698,7 @@
+ .ndo_change_mtu = libipw_change_mtu,
+ .ndo_validate_addr = eth_validate_addr,
+ };
++#endif
+
+ static int __devinit ipw_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+@@ -11790,7 +11800,15 @@
+ priv->ieee->perfect_rssi = -20;
+ priv->ieee->worst_rssi = -85;
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29))
+ net_dev->netdev_ops = &ipw_netdev_ops;
++#else
++ net_dev->open = ipw_net_open;
++ net_dev->stop = ipw_net_stop;
++ net_dev->init = ipw_net_init;
++ net_dev->set_multicast_list = ipw_net_set_multicast_list;
++ net_dev->set_mac_address = ipw_net_set_mac_address;
++#endif
+ priv->wireless_data.spy_data = &priv->ieee->spy_data;
+ net_dev->wireless_data = &priv->wireless_data;
+ net_dev->wireless_handlers = &ipw_wx_handler_def;
--- a/drivers/net/wireless/libertas/main.c 2009-08-18 16:17:34.669375612 -0700
+++ b/drivers/net/wireless/libertas/main.c 2009-08-18 16:17:35.277375431 -0700
@@ -1148,6 +1148,7 @@
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] rt2x00: Get rid of duplicate usb id from rt2500usb
From: Pavel Roskin @ 2009-09-03 15:11 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: John W. Linville, Amit Kucheria, List Linux Kernel,
linux-wireless
In-Reply-To: <a32f33a40909030718v494f8fech6ba3c854b5c84ef8@mail.gmail.com>
On Thu, 2009-09-03 at 16:18 +0200, Ivo Van Doorn wrote:
> On Thu, Sep 3, 2009 at 1:55 PM, John W. Linville<linville@tuxdriver.com> wrote:
> > On Thu, Sep 03, 2009 at 02:42:20PM +0300, Amit Kucheria wrote:
> >> USB_DEVICE(0x148f, 0x2573) is served by the rt73usb driver where it is already
> >> defined. Remove it from rt2500usb.
> >>
> >> Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
> >> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> >
> > IIRC there are IDs that are used by different devices where rt73usb
> > covers one device and the rt2500usb covers another. Are you sure
> > this is not one of those?
>
> Yes, I believe this particular ID was already discussed some time ago
> on this list. This is one of the infamous duplicate IDs. (Fortunately not
> one of those infamous Linksys devices with 5 different chipsets for the
> same ID).
The famous Linksys devices can be distinguished by the textual PCMCIA
ID. In this case, there is no reliable way to distinguish the devices
without trying the drivers. I tried and could not find any difference
between "lsusb -v" output for the devices said to be supported by
rt2500usb and rt73usb.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Fix channelFlags for 2GHZ
From: Pavel Roskin @ 2009-09-03 15:19 UTC (permalink / raw)
To: Sujith; +Cc: linville, linux-wireless
In-Reply-To: <19103.25725.707217.596352@gargle.gargle.HOWL>
On Thu, 2009-09-03 at 12:08 +0530, Sujith wrote:
> CHANNEL_G has to be set for 2GHZ channels since
> IS_CHAN_G() checks for this in channelFlags and not in
> chanmode. To make things messier, ath9k_hw_process_ini()
> checks for CHANNEL_G in chanmode and not in channelFlags.
> The supreme, brain-searing fix is to set the
> flag in both cases.
My impression is that's a workaround for a bug that lies elsewhere. I
don't think we should apply such patches.
chanmode and channelFlags seem to duplicate each other. I would use an
enum for distinctive allowed modes and macros to query if the particular
mode has a specific feature (band, modulation, bandwidth etc).
The enum could use ORed constants for optimization, but such constants
should be used only through the macros.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Cross compiling currently broken?
From: Philip Prindeville @ 2009-09-03 16:14 UTC (permalink / raw)
To: Ed W; +Cc: linux-wireless
In-Reply-To: <4A94319B.9030903@wildgooses.com>
Ed W wrote:
> It would appear that there is something broken with the current Makefile
> when crosscompiling - I need a bit of help figuring out a proper solution.
>
> In this case it's barely cross compiling, I just want to use a kernel I
> compiled somewhere, but isn't installed (I'm also in a chroot).
> According to the docs (http://linuxwireless.org/en/users/Download) I
> should do something like:
>
> make KLIB=/home/mcgrof/kernels/linux-2.6.27.22 \
> KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.27.22
>
> However, the makefile then installs the files in completely the wrong
> location, eg the following puts the files in
> /usr/src/linux/lib/modules/2.6.30.5-grsec-wrap/ !!
>
> make KLIB=/usr/src/linux \
> KLIB_BUILD=/usr/src/linux install-modules
>
> So KLIB should apparently be something like /lib/modules/xyz. However,
> this is still wrong because the line below puts the files in:
> /lib/modules/2.6.30.5-grsec-wrap/lib/modules/2.6.30.5-grsec-wrap/
>
> make KLIB=/lib/modules/2.6.30.5-grsec-wrap/ \
> KLIB_BUILD=/usr/src/linux install-modules
>
>
> Adding unsetting KMODPATH_ARG seems to do the trick (but seems unintended?):
>
> make KLIB=/lib/modules/2.6.30.5-grsec-wrap/ \
> KLIB_BUILD=/usr/src/linux KMODPATH_ARG= install-modules
>
>
> But I still get repeated errors while building (where this is the
> currently running kernel, but the modules dir is unavailable in this
> chroot):
>
> FATAL: Could not load
> /lib/modules/2.6.29.6-grsec2.1.14-vs2.3.0.36.14/modules.dep: No such
> file or directory
> FATAL: Could not load
> /lib/modules/2.6.29.6-grsec2.1.14-vs2.3.0.36.14/modules.dep: No such
> file or directory
>
>
> This appears to be caused by these lines at the top of the makefile:
> MADWIFI=$(shell $(MODPROBE) -l ath_pci)
> OLD_IWL=$(shell $(MODPROBE) -l iwl4965)
>
> Clearly these need some parametrisation to include the running kernel
> name. Something like this might pluck out the correct
> uname:
> KERNELRELEASE = $(cat $(KLIB_BUILD)/include/config/kernel.release 2>
> /dev/null)
>
>
> I'm not quite clear what all the KLIB/KLIB_BUILD vars are supposed to be
> achieving, but at present they aren't working correctly when overridden
> to build a non installed kernel. I'm surprised more people aren't
> hitting this?
>
> Grateful if someone with a bit more experience could suggest a proper fix?
>
> Thanks
>
> Ed W
>
Try the patch I posted a few weeks ago. It solved this issue for us.
-Philip
^ permalink raw reply
* Re: [PATCH] ar9170: added phy register initialisation from eeprom values
From: Christian Lamparter @ 2009-09-03 16:16 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless
In-Reply-To: <4A9EF532.8070500@gmx.de>
[-- Attachment #1: Type: Text/Plain, Size: 1188 bytes --]
(CC linux-wireless)
On Thursday 03 September 2009 00:44:02 Joerg Albert wrote:
> On 08/31/2009 11:37 PM, Christian Lamparter wrote:
>
> > well you need a patch which lets you use the MCS rates and
> > kicks off BlockAck sessions. I posted a version some time
> > ago, (AFAIK initial RFC?). However due to fact that the code belongs
> > into the rc-algorithm and the lack of "out-house testing" feedback,
> > I had to drop it. I can send you an _updated_ (well, it should apply without
> > fuzz... but you still have to select the MCS by hand) version if you want,
> > however not until Friday. Of course, If you have free time on your hand,
> > you could do the fix-ups by yourself and start the madNess right on! ;-)
>
> As I'm not that familiar with 802.11n (and always short of free time)
> I'd like to use your patch.
> Guess the old version is
> "[WIP][RFT][RFC] ar9170: aggregation xmit (aka the _other_ part)" from 2009/06/06?
exactly... it's old & buggy
this version even has a bogus rc.
(Of course, you can select your own MCS rate by changing)
+ rate->idx = sta_info->current_rate;
to a static value between 0 and 15.
(which is _translated_ into: MCS 0 - 15)
Regards,
Chr
[-- Attachment #2: ar9170-rate-v4.2.diff --]
[-- Type: text/x-patch, Size: 10373 bytes --]
diff --git a/drivers/net/wireless/ath/ar9170/ar9170.h b/drivers/net/wireless/ath/ar9170/ar9170.h
index 914e471..d3ba91c 100644
--- a/drivers/net/wireless/ath/ar9170/ar9170.h
+++ b/drivers/net/wireless/ath/ar9170/ar9170.h
@@ -131,6 +131,7 @@ struct ar9170_rxstream_mpdu_merge {
enum ar9170_tid_state {
AR9170_TID_STATE_INVALID,
AR9170_TID_STATE_SHUTDOWN,
+ AR9170_TID_STATE_STARTING,
AR9170_TID_STATE_PROGRESS,
AR9170_TID_STATE_COMPLETE,
};
@@ -233,6 +234,10 @@ struct ar9170 {
struct list_head tx_ampdu_list;
unsigned int tx_ampdu_pending;
+ spinlock_t addba_list_lock;
+ struct list_head addba_list;
+ struct work_struct start_tx_ba_work;
+
/* rxstream mpdu merge */
struct ar9170_rxstream_mpdu_merge rx_mpdu;
struct sk_buff *rx_failover;
@@ -246,6 +251,12 @@ struct ar9170 {
struct ar9170_sta_info {
struct ar9170_sta_tid agg[AR9170_NUM_TID];
unsigned int ampdu_max_len;
+
+#ifndef AR9170_MAC80211_RC_MCS
+ unsigned int max_mcs;
+ int score;
+ unsigned int current_rate;
+#endif /* AR9170_MAC80211_RC_MCS */
};
#define AR9170_TX_FLAG_WAIT_FOR_ACK BIT(0)
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index b007357..89aa831 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -49,7 +49,7 @@ static int modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
-static int modparam_ht;
+static int modparam_ht = 1;
module_param_named(ht, modparam_ht, bool, S_IRUGO);
MODULE_PARM_DESC(ht, "enable MPDU aggregation.");
@@ -285,6 +285,124 @@ static void ar9170_dump_tx_status_ampdu(struct ar9170 *ar)
#endif /* AR9170_TXAGG_DEBUG */
+static void ar9170_setup_aggregation(struct ar9170 *ar, struct sk_buff *skb)
+{
+ unsigned long flags;
+ struct ieee80211_sta *sta;
+ struct ieee80211_hdr *hdr = (void *) skb->data;
+ struct ar9170_sta_tid *tid_info;
+ u16 tid = ar9170_get_tid(skb);
+
+ if (!conf_is_ht(&ar->hw->conf))
+ return ;
+
+ /* don't start aggregation for non-qos / WPA handshake */
+ if ((skb->protocol == cpu_to_le16(ETH_P_PAE)) ||
+ !ieee80211_is_data_qos(hdr->frame_control))
+ return ;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(ar->hw, ieee80211_get_DA(hdr));
+ if (!sta)
+ goto out_unlock;
+
+ if (!sta->ht_cap.ht_supported)
+ goto out_unlock;
+
+ tid_info = &((struct ar9170_sta_info *) sta->drv_priv)->agg[tid];
+
+ if (tid_info->retry++ > AR9170_NUM_MAX_BA_RETRY) {
+#ifdef AR9170_TXAGG_DEBUG
+ printk(KERN_DEBUG "%s: too many addba retries for "
+ "ESS:[%pM], tid:%d.\n", wiphy_name(ar->hw->wiphy),
+ sta->addr, tid);
+#endif /* AR9170_TXAGG_DEBUG */
+ goto out_unlock;
+ }
+
+ if (tid_info->state == AR9170_TID_STATE_SHUTDOWN) {
+ if (!list_empty(&tid_info->list)) {
+#ifdef AR9170_TXAGG_DEBUG
+ printk(KERN_DEBUG "%s: addba already queued.\n",
+ wiphy_name(ar->hw->wiphy));
+#endif /* AR9170_TXAGG_DEBUG */
+ goto out_unlock;
+ }
+
+ /* FIXME: no idea if this is right... */
+ tid_info->ssn = GET_NEXT_SEQ_FROM_SKB(skb);
+
+ spin_lock_irqsave(&ar->addba_list_lock, flags);
+ memcpy(tid_info->addr, sta->addr, ETH_ALEN);
+ tid_info->state = AR9170_TID_STATE_STARTING;
+ list_add_tail(&tid_info->list, &ar->addba_list);
+ spin_unlock_irqrestore(&ar->addba_list_lock, flags);
+ ieee80211_queue_work(ar->hw, &ar->start_tx_ba_work);
+ }
+
+out_unlock:
+ rcu_read_unlock();
+}
+
+#ifndef AR9170_MAC80211_RC_MCS
+static void ar9170_feedback_11nrate(struct ar9170 *ar, struct sk_buff *skb)
+{
+ struct ieee80211_tx_info *txinfo = IEEE80211_SKB_CB(skb);
+ struct ieee80211_tx_rate *txrate = txinfo->status.rates;
+ struct ieee80211_sta *sta;
+ struct ar9170_sta_info *sta_info;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(ar->hw, ieee80211_get_DA((void *)skb->data));
+ if (sta == NULL)
+ goto out_unlock;
+
+ sta_info = (void *) sta->drv_priv;
+ sta_info->score = (sta_info->score * 99998) / 99999;
+
+ if (txinfo->flags & IEEE80211_TX_STAT_ACK)
+ sta_info->score += 16 - txrate->idx;
+ else
+ sta_info->score -= 16 - txrate->idx;
+
+ if (sta_info->score < 0) {
+ if (sta_info->current_rate)
+ sta_info->current_rate--;
+ } else if (sta_info->score > (1 << txrate->idx) &&
+ sta_info->current_rate < sta_info->max_mcs)
+ sta_info->current_rate++;
+
+out_unlock:
+ rcu_read_unlock();
+}
+
+static void ar9170_select_11nrate(struct ar9170 *ar,
+ struct ieee80211_tx_rate *rate,
+ struct ieee80211_tx_info *info)
+{
+ struct ieee80211_sta *sta = info->control.sta;
+ struct ar9170_sta_info *sta_info = (void *) sta->drv_priv;
+
+ info->flags &= ~IEEE80211_TX_INTFL_RCALGO;
+ rate->flags = IEEE80211_TX_RC_MCS;
+ rate->idx = sta_info->current_rate;
+
+ if ((rate->idx > 4) &&
+ conf_is_ht40(&ar->hw->conf) &&
+ (sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
+ rate->flags |= IEEE80211_TX_RC_40_MHZ_WIDTH;
+
+ if ((rate->idx == (sta_info->max_mcs + 1)) &&
+ (rate->flags & IEEE80211_TX_RC_40_MHZ_WIDTH) &&
+ (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40))
+ rate->flags |= IEEE80211_TX_RC_SHORT_GI;
+#ifdef AR9170_RC_MCS_DEBUG
+ if (net_ratelimit())
+ printk(KERN_DEBUG "rate:%x flags:%x\n", rate->idx, rate->flags);
+#endif
+}
+#endif /* AR9170_MAC80211_RC_MCS */
+
/* caller must guarantee exclusive access for _bin_ queue. */
static void ar9170_recycle_expired(struct ar9170 *ar,
struct sk_buff_head *queue,
@@ -353,6 +471,9 @@ static void ar9170_tx_status(struct ar9170 *ar, struct sk_buff *skb,
txinfo->status.rates[0].count = retries + 1;
skb_pull(skb, sizeof(struct ar9170_tx_control));
+ if (tx_status != AR9170_TX_STATUS_FAILED)
+ ar9170_setup_aggregation(ar, skb);
+
ieee80211_tx_status_irqsafe(ar->hw, skb);
}
@@ -388,6 +509,9 @@ static void ar9170_tx_fake_ampdu_status(struct ar9170 *ar)
txinfo->status.rates[0].count = 1;
skb_pull(skb, sizeof(struct ar9170_tx_control));
+#ifndef AR9170_MAC80211_RC_MCS
+ ar9170_feedback_11nrate(ar, skb);
+#endif /* AR9170_MAC80211_RC_MCS */
ieee80211_tx_status_irqsafe(ar->hw, skb);
}
@@ -542,6 +666,9 @@ static void ar9170_handle_block_ack(struct ar9170 *ar, u16 count, u16 r)
txinfo->status.rates[0].count = 1;
skb_pull(skb, sizeof(struct ar9170_tx_control));
+#ifndef AR9170_MAC80211_RC_MCS
+ ar9170_feedback_11nrate(ar, skb);
+#endif /* AR9170_MAC80211_RC_MCS */
ieee80211_tx_status_irqsafe(ar->hw, skb);
count--;
}
@@ -1295,6 +1422,7 @@ static void ar9170_op_stop(struct ieee80211_hw *hw)
cancel_delayed_work_sync(&ar->led_work);
#endif
cancel_work_sync(&ar->beacon_work);
+ cancel_work_sync(&ar->start_tx_ba_work);
mutex_lock(&ar->mutex);
@@ -1414,6 +1542,10 @@ static int ar9170_tx_prepare(struct ar9170 *ar, struct sk_buff *skb)
txc->mac_control |= cpu_to_le16(AR9170_TX_MAC_AGGR);
arinfo->flags = AR9170_TX_FLAG_BLOCK_ACK;
+#ifndef AR9170_MAC80211_RC_MCS
+ ar9170_select_11nrate(ar, txrate, info);
+#endif /* AR9170_MAC80211_RC_MCS */
+
goto out;
}
@@ -1475,6 +1607,13 @@ static void ar9170_tx_prepare_phy(struct ar9170 *ar, struct sk_buff *skb)
u32 r = txrate->idx;
u8 *txpower;
+#ifndef AR9170_MAC80211_RC_MCS
+ if (ar->eeprom.tx_mask == 1)
+ txrate->idx = r = min_t(s8, txrate->idx, 7);
+ else
+ txrate->idx = r = min_t(s8, txrate->idx, 15);
+#endif /* AR9170_MAC80211_RC_MCS */
+
/* heavy clip control */
txc->phy_control |= cpu_to_le32((r & 0x7) << 7);
@@ -1540,6 +1679,7 @@ static void ar9170_tx_prepare_phy(struct ar9170 *ar, struct sk_buff *skb)
/* >= 36M legacy OFDM - use only one chain */
if (rate && rate->bitrate >= 360)
chains = AR9170_TX_PHY_TXCHAIN_1;
+
}
txc->phy_control |= cpu_to_le32(chains << AR9170_TX_PHY_TXCHAIN_SHIFT);
}
@@ -2363,6 +2503,18 @@ static void ar9170_sta_notify(struct ieee80211_hw *hw,
}
sta_info->ampdu_max_len = 1 << (3 + sta->ht_cap.ampdu_factor);
+
+#ifndef AR9170_MAC80211_RC_MCS
+ {
+ unsigned int tx_mcs;
+ unsigned int rx_mcs;
+
+ tx_mcs = ar->eeprom.tx_mask == 1 ? 7 : 15;
+ rx_mcs = find_last_bit((unsigned long *)sta->ht_cap.mcs.rx_mask, 16);
+
+ sta_info->max_mcs = min(tx_mcs, rx_mcs);
+ }
+#endif /* AR9170_MAC80211_RC_MCS */
break;
case STA_NOTIFY_REMOVE:
@@ -2445,7 +2597,7 @@ static int ar9170_ampdu_action(struct ieee80211_hw *hw,
switch (action) {
case IEEE80211_AMPDU_TX_START:
spin_lock_irqsave(&ar->tx_ampdu_list_lock, flags);
- if (tid_info->state != AR9170_TID_STATE_SHUTDOWN ||
+ if (tid_info->state != AR9170_TID_STATE_STARTING ||
!list_empty(&tid_info->list)) {
spin_unlock_irqrestore(&ar->tx_ampdu_list_lock, flags);
#ifdef AR9170_TXAGG_DEBUG
@@ -2514,6 +2666,35 @@ static const struct ieee80211_ops ar9170_ops = {
.ampdu_action = ar9170_ampdu_action,
};
+static void ar9170_start_tx_ba(struct work_struct *work)
+{
+ struct ar9170 *ar = container_of(work, struct ar9170,
+ start_tx_ba_work);
+ unsigned long flags;
+
+ while (!list_empty(&ar->addba_list)) {
+ struct ar9170_sta_tid *tid_info;
+
+ spin_lock_irqsave(&ar->addba_list_lock, flags);
+ tid_info = list_first_entry(&ar->addba_list,
+ struct ar9170_sta_tid, list);
+ if (tid_info) {
+ tid_info->retry = 0;
+ list_del_init(&tid_info->list);
+
+ if (tid_info->state != AR9170_TID_STATE_STARTING) {
+ WARN_ON(1);
+ tid_info = NULL;
+ }
+ }
+ spin_unlock_irqrestore(&ar->addba_list_lock, flags);
+
+ if (tid_info)
+ ieee80211_start_tx_ba_session(ar->hw, tid_info->addr,
+ tid_info->tid);
+ }
+}
+
void *ar9170_alloc(size_t priv_size)
{
struct ieee80211_hw *hw;
@@ -2542,6 +2723,7 @@ void *ar9170_alloc(size_t priv_size)
mutex_init(&ar->mutex);
spin_lock_init(&ar->cmdlock);
spin_lock_init(&ar->tx_stats_lock);
+ spin_lock_init(&ar->addba_list_lock);
spin_lock_init(&ar->tx_ampdu_list_lock);
skb_queue_head_init(&ar->tx_status_ampdu);
for (i = 0; i < __AR9170_NUM_TXQ; i++) {
@@ -2550,8 +2732,10 @@ void *ar9170_alloc(size_t priv_size)
}
ar9170_rx_reset_rx_mpdu(ar);
INIT_WORK(&ar->beacon_work, ar9170_new_beacon);
+ INIT_WORK(&ar->start_tx_ba_work, ar9170_start_tx_ba);
INIT_DELAYED_WORK(&ar->tx_janitor, ar9170_tx_janitor);
INIT_LIST_HEAD(&ar->tx_ampdu_list);
+ INIT_LIST_HEAD(&ar->addba_list);
/* all hw supports 2.4 GHz, so set channel to 1 by default */
ar->channel = &ar9170_2ghz_chantable[0];
^ permalink raw reply related
* Re: 802.11a multicast rate setting
From: Pavel Roskin @ 2009-09-03 17:46 UTC (permalink / raw)
To: Jinsung Lee; +Cc: linux-wireless
In-Reply-To: <031201ca2c47$f334bba0$d99e32e0$@kaist.ac.kr>
On Thu, 2009-09-03 at 12:38 +0900, Jinsung Lee wrote:
> Hi, everyone.
>
> If using ath5k or ath9k when the WLAN card supports 802.11a mode, is it
> possible to change multicast (or broadcast) rate into under 6Mbps, like the
> case of 802.11b mode?
> e.g. 1Mbps or 2Mbps.
No, such rates are not available for 802.11a.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak reports
From: Luis R. Rodriguez @ 2009-09-03 18:13 UTC (permalink / raw)
To: Johannes Berg, Catalin Marinas, linux-kernel; +Cc: linville, linux-wireless
In-Reply-To: <1251962791.3336.3.camel@johannes.local>
On Thu, Sep 3, 2009 at 12:26 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-09-03 at 02:11 -0400, Luis R. Rodriguez wrote:
>> This was giving false positives. We use eventually free this
>> through kref_put(), things are not so obvious through
>> cfg80211_bss_update().
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> net/wireless/scan.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
>> index 19c5a9a..79f7a5d 100644
>> --- a/net/wireless/scan.c
>> +++ b/net/wireless/scan.c
>> @@ -495,6 +495,9 @@ cfg80211_inform_bss(struct wiphy *wiphy,
>>
>> kref_init(&res->ref);
>>
>> + /* cfg80211_bss_update() eats up res - we ensure we free it there */
>> + kmemleak_ignore(res);
>> +
>> res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
>> if (!res)
>> return NULL;
>
> That's not making sense. cfg80211_bss_update() doesn't actually take a
> reference, it adds a new one for itself and then we return one to the
> caller.
What I meant is it gobbles it up and spits another thing out. When it
gobbles it up the routine then uses kref_put().
> Why can it not track this?
It probably can, just not sure if it follows kref_put(), I was under
the impression here it doesn't and because of it we were getting false
positives. Catalin, can you confirm?
> Actually it looks like we do leak one in net/mac80211/ibss.c.
Luis
^ permalink raw reply
* Re: [compat-2.6] readd netdev_ops backport to ipw2200.c
From: Luis R. Rodriguez @ 2009-09-03 18:15 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <1251988316-30031-1-git-send-email-hauke@hauke-m.de>
On Thu, Sep 3, 2009 at 7:31 AM, Hauke Mehrtens<hauke@hauke-m.de> wrote:
> This fixes building of ipw2200.c for kernel < 2.6.29.
> It was introduced in 203a12ff5a432e2ee4a83b38e698bff0dd4efead
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied, thanks.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox