* Re: compat-wireless and minstrel
From: Christian Lamparter @ 2009-11-04 22:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Luis R. Rodriguez, Adam Wozniak, linux-wireless
In-Reply-To: <20091104222007.GB2599@bombadil.infradead.org>
On Wednesday 04 November 2009 23:20:07 Luis R. Rodriguez wrote:
> On Wed, Nov 04, 2009 at 11:18:13PM +0100, Christian Lamparter wrote:
> > On Wednesday 04 November 2009 22:50:46 Luis R. Rodriguez wrote:
> > > On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
> > > >
> > > > $ ls -la /lib/firmware/ar9170*
> > > > -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
> > > > -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
> > > > -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
> > > >
> > > > It is unclear to me which are actually used.
> > >
> > > By default the ar9170.fw is tried first, if that fails then the others
> > > are tried. The 2-stage firmware will not be tried if your device
> > > cannot handle it but right now only the AVM Fritz devices can't handle
> > > the 2-stage firmware.
> > >
> > > Christian should we just remove 2-stage fw support?
> >
> > I've moved the two-stage fw into the legacy section some time ago :)
> > Maybe a add printk?
>
> Oh sorry didn't notice, I meant complete removal of its support on the
> driver though :)
Oh, I've no problem removing two-stage fw support.
But then, I don't know much about usability :-D and I've enough of
people banging their heads against each other.
Regards,
Chr
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Nick Kossifidis @ 2009-11-04 22:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, Matthew Wilcox, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <20091104221426.GA2599@bombadil.infradead.org>
2009/11/5 Luis R. Rodriguez <mcgrof@bombadil.infradead.org>:
> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>> >> > Even better: I just confirmation from our systems team that our legacy
>> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>> >> > cruft crap.
>> >>
>> >> I meant MWI of course.
>> >
>> > Yes, but they don't necessarily just use cacheline size for MWI ... some
>> > devices use cacheline size for setting up data structures. Might be
>> > worth just checking explicitly that they don't use the cacheline size
>> > register for anything.
>>
>> Oh right -- so the typical Atheros hack for this is to check the cache
>> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>> was doing now is removing all this cruft and replacing it with a
>> generic allocator for atheros drivers that aligns simply to the
>> L1_CACHE_BYTES. Sound kosher?
>
> Something like this:
>
According to comments inside MadWiFi AR5210 needs cache line align
else we get corruptions. I don't know if this is correct for all
platforms or later cards but since we (plan to) support AR5210 i guess
we should leave it there. We need to test this a lot on various
archs/cards before applying it.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 22:28 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Wilcox, Nick Kossifidis, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <20091104221426.GA2599@bombadil.infradead.org>
On Wed, Nov 4, 2009 at 2:14 PM, Luis R. Rodriguez
<mcgrof@bombadil.infradead.org> wrote:
> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>> >> > Even better: I just confirmation from our systems team that our legacy
>> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>> >> > cruft crap.
>> >>
>> >> I meant MWI of course.
>> >
>> > Yes, but they don't necessarily just use cacheline size for MWI ... some
>> > devices use cacheline size for setting up data structures. Might be
>> > worth just checking explicitly that they don't use the cacheline size
>> > register for anything.
>>
>> Oh right -- so the typical Atheros hack for this is to check the cache
>> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>> was doing now is removing all this cruft and replacing it with a
>> generic allocator for atheros drivers that aligns simply to the
>> L1_CACHE_BYTES. Sound kosher?
>
> Something like this:
I also checked with our systems team and it seems we do not rely on
the PCI_CACHE_LINE_SIZE pci config to internally align data in the
hardware itself. It that what you meant?
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Matthew Wilcox @ 2009-11-04 22:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, Nick Kossifidis, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <20091104221426.GA2599@bombadil.infradead.org>
On Wed, Nov 04, 2009 at 05:14:26PM -0500, Luis R. Rodriguez wrote:
> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
> > On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
> > > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
> > >> > Even better: I just confirmation from our systems team that our legacy
> > >> > devices and 11n PCI devices don't support MWR so I'll remove all that
> > >> > cruft crap.
> > >>
> > >> I meant MWI of course.
> > >
> > > Yes, but they don't necessarily just use cacheline size for MWI ... some
> > > devices use cacheline size for setting up data structures. ?Might be
> > > worth just checking explicitly that they don't use the cacheline size
> > > register for anything.
> >
> > Oh right -- so the typical Atheros hack for this is to check the cache
> > line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
> > from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
> > was doing now is removing all this cruft and replacing it with a
> > generic allocator for atheros drivers that aligns simply to the
> > L1_CACHE_BYTES. Sound kosher?
>
> Something like this:
Doesn't look kosher to me. You're not programming the CLS register
now at all, which means you're relying on something else having set
it up for you. If you could EXPORT_SYMBOL(pci_set_cacheline_size)
and include a call to it somewhere, that would be good. You can rely
on pci_cache_line_size not changing after the system has booted.
> /*
> - * Cache line size is used to size and align various
> - * structures used to communicate with the hardware.
> - */
> - pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &csz);
> - if (csz == 0) {
> - /*
> - * Linux 2.4.18 (at least) writes the cache line size
> - * register as a 16-bit wide register which is wrong.
> - * We must have this setup properly for rx buffer
> - * DMA to work so force a reasonable value here if it
> - * comes up zero.
> - */
> - csz = L1_CACHE_BYTES >> 2;
> - pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, csz);
> - }
These comments are what give me pause.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Luis R. Rodriguez @ 2009-11-04 22:20 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Luis R. Rodriguez, Adam Wozniak, linux-wireless
In-Reply-To: <200911042318.13528.chunkeey@googlemail.com>
On Wed, Nov 04, 2009 at 11:18:13PM +0100, Christian Lamparter wrote:
> On Wednesday 04 November 2009 22:50:46 Luis R. Rodriguez wrote:
> > On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
> > >
> > > $ ls -la /lib/firmware/ar9170*
> > > -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
> > > -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
> > > -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
> > >
> > > It is unclear to me which are actually used.
> >
> > By default the ar9170.fw is tried first, if that fails then the others
> > are tried. The 2-stage firmware will not be tried if your device
> > cannot handle it but right now only the AVM Fritz devices can't handle
> > the 2-stage firmware.
> >
> > Christian should we just remove 2-stage fw support?
>
> I've moved the two-stage fw into the legacy section some time ago :)
> Maybe a add printk?
Oh sorry didn't notice, I meant complete removal of its support on the
driver though :)
Luis
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Christian Lamparter @ 2009-11-04 22:18 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Adam Wozniak, linux-wireless
In-Reply-To: <43e72e890911041350i75108dc3g454ab8577d8abacd@mail.gmail.com>
On Wednesday 04 November 2009 22:50:46 Luis R. Rodriguez wrote:
> On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
> >
> > $ ls -la /lib/firmware/ar9170*
> > -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
> > -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
> > -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
> >
> > It is unclear to me which are actually used.
>
> By default the ar9170.fw is tried first, if that fails then the others
> are tried. The 2-stage firmware will not be tried if your device
> cannot handle it but right now only the AVM Fritz devices can't handle
> the 2-stage firmware.
>
> Christian should we just remove 2-stage fw support?
I've moved the two-stage fw into the legacy section some time ago :)
Maybe a add printk?
Regards,
Chr
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: John W. Linville @ 2009-11-04 22:12 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Ingo Molnar, Bartlomiej Zolnierkiewicz, linux-wireless,
linux-kernel, netdev, Randy Dunlap, Luis Correia, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911042251.23506.IvDoorn@gmail.com>
On Wed, Nov 04, 2009 at 10:51:22PM +0100, Ivo van Doorn wrote:
> Get your facts straight, the bullshit level in your mail is staggering.
Please, enough!
--
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: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-04 22:09 UTC (permalink / raw)
To: Pavel Machek
Cc: Ivo van Doorn, Jiri Kosina, Luis Correia, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091104220024.GC27325@elf.ucw.cz>
On Wed, Nov 04, 2009 at 11:00:25PM +0100, Pavel Machek wrote:
> > > But yes, he got flamed for this for some odd reason. I got the impression
> > > that the community around rt2x00 doesn't like (or understand) the way how
> > > opensource development happens.
> >
> > Well you mean the open source development where non-contributors
> > complain that the contributors work too slowly?
>
> This was the case when non-contributor complained that patch adds
> 2KLoC of unneccessary code.
>
> > Perhaps
> > that is the policy in some companies which try to import it into the
> > Open Source world...
>
> Do you really have to attack everyone around?
Really, this is enough.
It seems clear that neither side of this debate sees or appreciates
the injuries that the other side claims. In any case, there seems
little good can come from continuing this bickering.
Now that Bart is posting patches and the rt2x00 team is actively
reviewing (and mostly Acking) them, I hope everyone can just BACK
THE HELL OFF and let the process work itself out.
Please let this discussion end.
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: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 22:14 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Wilcox, Nick Kossifidis, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <43e72e890911041404q5f491bbbw123d8761037f9c63@mail.gmail.com>
On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
> >> > Even better: I just confirmation from our systems team that our legacy
> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
> >> > cruft crap.
> >>
> >> I meant MWI of course.
> >
> > Yes, but they don't necessarily just use cacheline size for MWI ... some
> > devices use cacheline size for setting up data structures. Might be
> > worth just checking explicitly that they don't use the cacheline size
> > register for anything.
>
> Oh right -- so the typical Atheros hack for this is to check the cache
> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
> was doing now is removing all this cruft and replacing it with a
> generic allocator for atheros drivers that aligns simply to the
> L1_CACHE_BYTES. Sound kosher?
Something like this:
drivers/net/wireless/ath/ath.h | 6 +-----
drivers/net/wireless/ath/ath5k/base.c | 27 +++------------------------
drivers/net/wireless/ath/ath9k/ahb.c | 8 --------
drivers/net/wireless/ath/ath9k/ath9k.h | 5 -----
drivers/net/wireless/ath/ath9k/main.c | 9 ---------
drivers/net/wireless/ath/ath9k/pci.c | 20 --------------------
drivers/net/wireless/ath/ath9k/recv.c | 11 +++++------
drivers/net/wireless/ath/main.c | 27 +++++----------------------
8 files changed, 14 insertions(+), 99 deletions(-)
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 4af1362..438f46f 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -63,7 +63,6 @@ struct ath_ops {
struct ath_common;
struct ath_bus_ops {
- void (*read_cachesize)(struct ath_common *common, int *csz);
void (*cleanup)(struct ath_common *common);
bool (*eeprom_read)(struct ath_common *common, u32 off, u16 *data);
void (*bt_coex_prep)(struct ath_common *common);
@@ -78,7 +77,6 @@ struct ath_common {
struct ath_ani ani;
- u16 cachelsz;
u16 curaid;
u8 macaddr[ETH_ALEN];
u8 curbssid[ETH_ALEN];
@@ -94,9 +92,7 @@ struct ath_common {
const struct ath_bus_ops *bus_ops;
};
-struct sk_buff *ath_rxbuf_alloc(struct ath_common *common,
- u32 len,
- gfp_t gfp_mask);
+struct sk_buff *ath_rxbuf_alloc(u32 len, gfp_t gfp_mask);
void ath_hw_setbssidmask(struct ath_common *common);
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index c7fc13c..6943660 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -466,7 +466,6 @@ ath5k_pci_probe(struct pci_dev *pdev,
struct ath_common *common;
struct ieee80211_hw *hw;
int ret;
- u8 csz;
ret = pci_enable_device(pdev);
if (ret) {
@@ -482,22 +481,6 @@ ath5k_pci_probe(struct pci_dev *pdev,
}
/*
- * Cache line size is used to size and align various
- * structures used to communicate with the hardware.
- */
- pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &csz);
- if (csz == 0) {
- /*
- * Linux 2.4.18 (at least) writes the cache line size
- * register as a 16-bit wide register which is wrong.
- * We must have this setup properly for rx buffer
- * DMA to work so force a reasonable value here if it
- * comes up zero.
- */
- csz = L1_CACHE_BYTES >> 2;
- pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, csz);
- }
- /*
* The default setting of latency timer yields poor results,
* set it to the value used by other systems. It may be worth
* tweaking this setting more.
@@ -598,7 +581,6 @@ ath5k_pci_probe(struct pci_dev *pdev,
common->ops = &ath5k_common_ops;
common->ah = sc->ah;
common->hw = hw;
- common->cachelsz = csz << 2; /* convert to bytes */
/* Initialize device */
ret = ath5k_hw_attach(sc);
@@ -1184,9 +1166,7 @@ struct sk_buff *ath5k_rx_skb_alloc(struct ath5k_softc *sc, dma_addr_t *skb_addr)
* Allocate buffer with headroom_needed space for the
* fake physical layer header at the start.
*/
- skb = ath_rxbuf_alloc(common,
- common->rx_bufsize,
- GFP_ATOMIC);
+ skb = ath_rxbuf_alloc(common->rx_bufsize, GFP_ATOMIC);
if (!skb) {
ATH5K_ERR(sc, "can't alloc skbuff of size %u\n",
@@ -1636,10 +1616,9 @@ ath5k_rx_start(struct ath5k_softc *sc)
struct ath5k_buf *bf;
int ret;
- common->rx_bufsize = roundup(IEEE80211_MAX_LEN, common->cachelsz);
+ common->rx_bufsize = IEEE80211_MAX_LEN;
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "cachelsz %u rx_bufsize %u\n",
- common->cachelsz, common->rx_bufsize);
+ ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "rx_bufsize %u\n", common->rx_bufsize);
spin_lock_bh(&sc->rxbuflock);
sc->rxlink = NULL;
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 329e6bc..9949524 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -21,12 +21,6 @@
#include <linux/ath9k_platform.h>
#include "ath9k.h"
-/* return bus cachesize in 4B word units */
-static void ath_ahb_read_cachesize(struct ath_common *common, int *csz)
-{
- *csz = L1_CACHE_BYTES >> 2;
-}
-
static void ath_ahb_cleanup(struct ath_common *common)
{
struct ath_softc *sc = (struct ath_softc *)common->priv;
@@ -53,9 +47,7 @@ static bool ath_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
}
static struct ath_bus_ops ath_ahb_bus_ops = {
- .read_cachesize = ath_ahb_read_cachesize,
.cleanup = ath_ahb_cleanup,
-
.eeprom_read = ath_ahb_eeprom_read,
};
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 377b0ea..66d4a70 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -618,11 +618,6 @@ int ath_get_hal_qnum(u16 queue, struct ath_softc *sc);
int ath_get_mac80211_qnum(u32 queue, struct ath_softc *sc);
int ath_cabq_update(struct ath_softc *);
-static inline void ath_read_cachesize(struct ath_common *common, int *csz)
-{
- common->bus_ops->read_cachesize(common, csz);
-}
-
static inline void ath_bus_cleanup(struct ath_common *common)
{
common->bus_ops->cleanup(common);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 01ac897..af9c785 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1624,7 +1624,6 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
struct ath_hw *ah = NULL;
struct ath_common *common;
int r = 0, i;
- int csz = 0;
int qnum;
/* XXX: hardware will not be ready until ath_open() being called */
@@ -1656,14 +1655,6 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
common->priv = sc;
common->debug_mask = ath9k_debug;
- /*
- * Cache line size is used to size and align various
- * structures used to communicate with the hardware.
- */
- ath_read_cachesize(common, &csz);
- /* XXX assert csz is non-zero */
- common->cachelsz = csz << 2; /* convert to bytes */
-
r = ath9k_hw_init(ah);
if (r) {
ath_print(common, ATH_DBG_FATAL,
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 5321f73..b0f72e4 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -30,25 +30,6 @@ static struct pci_device_id ath_pci_id_table[] __devinitdata = {
{ 0 }
};
-/* return bus cachesize in 4B word units */
-static void ath_pci_read_cachesize(struct ath_common *common, int *csz)
-{
- struct ath_softc *sc = (struct ath_softc *) common->priv;
- u8 u8tmp;
-
- pci_read_config_byte(to_pci_dev(sc->dev), PCI_CACHE_LINE_SIZE, &u8tmp);
- *csz = (int)u8tmp;
-
- /*
- * This check was put in to avoid "unplesant" consequences if
- * the bootrom has not fully initialized all PCI devices.
- * Sometimes the cache line size register is not set
- */
-
- if (*csz == 0)
- *csz = DEFAULT_CACHELINE >> 2; /* Use the default size */
-}
-
static void ath_pci_cleanup(struct ath_common *common)
{
struct ath_softc *sc = (struct ath_softc *) common->priv;
@@ -97,7 +78,6 @@ static void ath_pci_bt_coex_prep(struct ath_common *common)
}
const static struct ath_bus_ops ath_pci_bus_ops = {
- .read_cachesize = ath_pci_read_cachesize,
.cleanup = ath_pci_cleanup,
.eeprom_read = ath_pci_eeprom_read,
.bt_coex_prep = ath_pci_bt_coex_prep,
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 36d23ef..341ff0a 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -346,11 +346,10 @@ int ath_rx_init(struct ath_softc *sc, int nbufs)
sc->sc_flags &= ~SC_OP_RXFLUSH;
spin_lock_init(&sc->rx.rxbuflock);
- common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN,
- min(common->cachelsz, (u16)64));
+ common->rx_bufsize = IEEE80211_MAX_MPDU_LEN;
- ath_print(common, ATH_DBG_CONFIG, "cachelsz %u rxbufsize %u\n",
- common->cachelsz, common->rx_bufsize);
+ ath_print(common, ATH_DBG_CONFIG, "rx_bufsize %u\n",
+ common->rx_bufsize);
/* Initialize rx descriptors */
@@ -363,7 +362,7 @@ int ath_rx_init(struct ath_softc *sc, int nbufs)
}
list_for_each_entry(bf, &sc->rx.rxbuf, list) {
- skb = ath_rxbuf_alloc(common, common->rx_bufsize, GFP_KERNEL);
+ skb = ath_rxbuf_alloc(common->rx_bufsize, GFP_KERNEL);
if (skb == NULL) {
error = -ENOMEM;
goto err;
@@ -810,7 +809,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
/* Ensure we always have an skb to requeue once we are done
* processing the current buffer's skb */
- requeue_skb = ath_rxbuf_alloc(common, common->rx_bufsize, GFP_ATOMIC);
+ requeue_skb = ath_rxbuf_alloc(common->rx_bufsize, GFP_ATOMIC);
/* If there is no memory we ignore the current RX'd frame,
* tell hardware it can give us a new frame using the old
diff --git a/drivers/net/wireless/ath/main.c b/drivers/net/wireless/ath/main.c
index 487193f..0a1c762 100644
--- a/drivers/net/wireless/ath/main.c
+++ b/drivers/net/wireless/ath/main.c
@@ -23,35 +23,18 @@ MODULE_AUTHOR("Atheros Communications");
MODULE_DESCRIPTION("Shared library for Atheros wireless LAN cards.");
MODULE_LICENSE("Dual BSD/GPL");
-struct sk_buff *ath_rxbuf_alloc(struct ath_common *common,
- u32 len,
- gfp_t gfp_mask)
+struct sk_buff *ath_rxbuf_alloc(u32 len, gfp_t gfp_mask)
{
struct sk_buff *skb;
u32 off;
- /*
- * Cache-line-align. This is important (for the
- * 5210 at least) as not doing so causes bogus data
- * in rx'd frames.
- */
-
- /* Note: the kernel can allocate a value greater than
- * what we ask it to give us. We really only need 4 KB as that
- * is this hardware supports and in fact we need at least 3849
- * as that is the MAX AMSDU size this hardware supports.
- * Unfortunately this means we may get 8 KB here from the
- * kernel... and that is actually what is observed on some
- * systems :( */
- skb = __dev_alloc_skb(len + common->cachelsz - 1, gfp_mask);
+ skb = __dev_alloc_skb(len + L1_CACHE_BYTES - 1, gfp_mask);
if (skb != NULL) {
- off = ((unsigned long) skb->data) % common->cachelsz;
+ off = ((unsigned long) skb->data) % L1_CACHE_BYTES;
if (off != 0)
- skb_reserve(skb, common->cachelsz - off);
- } else {
- printk(KERN_ERR "skbuff alloc of size %u failed\n", len);
+ skb_reserve(skb, L1_CACHE_BYTES - off);
+ } else
return NULL;
- }
return skb;
}
^ permalink raw reply related
* [PATCH] libertas if_usb: tiny usb-rx overhaul
From: Christian Lamparter @ 2009-11-04 22:12 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Dan Williams, libertas-dev
In-Reply-To: <20091104211600.GE10786@tuxdriver.com>
This patch reorganizes libertas' if_usb rx routines.
- URB_ZERO_PACKET flag has no use for urbs for
incoming endpoints.
- skb_tail_pointer(skb) should be used to get
the right rx_buf pointer.
- most + IPFIELD_ALIGN_OFFSET can be prevented by
moving skb_reserve up right after allocation.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
any Tested-by: ?
---
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index a8262de..f220db9 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -506,17 +506,16 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
goto rx_ret;
}
+ skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
cardp->rx_skb = skb;
/* Fill the receive configuration URB and initialise the Rx call back */
usb_fill_bulk_urb(cardp->rx_urb, cardp->udev,
usb_rcvbulkpipe(cardp->udev, cardp->ep_in),
- skb->data + IPFIELD_ALIGN_OFFSET,
+ skb_tail_pointer(skb),
MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
cardp);
- cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
-
lbs_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n", cardp->rx_urb);
if ((ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC))) {
lbs_deb_usbd(&cardp->udev->dev, "Submit Rx URB failed: %d\n", ret);
@@ -557,7 +556,7 @@ static void if_usb_receive_fwload(struct urb *urb)
}
if (cardp->fwdnldover) {
- __le32 *tmp = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
+ __le32 *tmp = (__le32 *)skb->data;
if (tmp[0] == cpu_to_le32(CMD_TYPE_INDICATION) &&
tmp[1] == cpu_to_le32(MACREG_INT_CODE_FIRMWARE_READY)) {
@@ -572,8 +571,7 @@ static void if_usb_receive_fwload(struct urb *urb)
return;
}
if (cardp->bootcmdresp <= 0) {
- memcpy (&bootcmdresp, skb->data + IPFIELD_ALIGN_OFFSET,
- sizeof(bootcmdresp));
+ memcpy(&bootcmdresp, skb->data, sizeof(bootcmdresp));
if (le16_to_cpu(cardp->udev->descriptor.bcdDevice) < 0x3106) {
kfree_skb(skb);
@@ -619,8 +617,7 @@ static void if_usb_receive_fwload(struct urb *urb)
return;
}
- memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
- sizeof(struct fwsyncheader));
+ memcpy(syncfwheader, skb->data, sizeof(struct fwsyncheader));
if (!syncfwheader->cmd) {
lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
@@ -665,7 +662,6 @@ static inline void process_cmdtypedata(int recvlength, struct sk_buff *skb,
return;
}
- skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
skb_put(skb, recvlength);
skb_pull(skb, MESSAGE_HEADER_LEN);
@@ -719,7 +715,7 @@ static void if_usb_receive(struct urb *urb)
int recvlength = urb->actual_length;
uint8_t *recvbuff = NULL;
uint32_t recvtype = 0;
- __le32 *pkt = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
+ __le32 *pkt = (__le32 *)skb->data;
uint32_t event;
lbs_deb_enter(LBS_DEB_USB);
@@ -732,7 +728,7 @@ static void if_usb_receive(struct urb *urb)
goto setup_for_next;
}
- recvbuff = skb->data + IPFIELD_ALIGN_OFFSET;
+ recvbuff = skb->data;
recvtype = le32_to_cpu(pkt[0]);
lbs_deb_usbd(&cardp->udev->dev,
"Recv length = 0x%x, Recv type = 0x%X\n",
^ permalink raw reply related
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 22:04 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Nick Kossifidis, linux-wireless, ath5k-devel, Stephen Hemminger,
Kyle McMartin
In-Reply-To: <20091104220034.GI10555@parisc-linux.org>
On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
> On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>> > Even better: I just confirmation from our systems team that our legacy
>> > devices and 11n PCI devices don't support MWR so I'll remove all that
>> > cruft crap.
>>
>> I meant MWI of course.
>
> Yes, but they don't necessarily just use cacheline size for MWI ... some
> devices use cacheline size for setting up data structures. Might be
> worth just checking explicitly that they don't use the cacheline size
> register for anything.
Oh right -- so the typical Atheros hack for this is to check the cache
line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
was doing now is removing all this cruft and replacing it with a
generic allocator for atheros drivers that aligns simply to the
L1_CACHE_BYTES. Sound kosher?
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Matthew Wilcox @ 2009-11-04 22:00 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, linux-wireless, ath5k-devel, Stephen Hemminger,
Kyle McMartin
In-Reply-To: <43e72e890911041352n3a398b41h8927387c228661c5@mail.gmail.com>
On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
> > Even better: I just confirmation from our systems team that our legacy
> > devices and 11n PCI devices don't support MWR so I'll remove all that
> > cruft crap.
>
> I meant MWI of course.
Yes, but they don't necessarily just use cacheline size for MWI ... some
devices use cacheline size for setting up data structures. Might be
worth just checking explicitly that they don't use the cacheline size
register for anything.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pavel Machek @ 2009-11-04 22:00 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Jiri Kosina, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <200911042217.49144.IvDoorn@gmail.com>
> > But yes, he got flamed for this for some odd reason. I got the impression
> > that the community around rt2x00 doesn't like (or understand) the way how
> > opensource development happens.
>
> Well you mean the open source development where non-contributors
> complain that the contributors work too slowly?
This was the case when non-contributor complained that patch adds
2KLoC of unneccessary code.
> Perhaps
> that is the policy in some companies which try to import it into the
> Open Source world...
Do you really have to attack everyone around?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Luis R. Rodriguez @ 2009-11-04 21:55 UTC (permalink / raw)
To: Adam Wozniak; +Cc: Christian Lamparter, Derek Smithies, linux-wireless, nbd
In-Reply-To: <4AF1F7F2.1020806@irobot.com>
On Wed, Nov 4, 2009 at 1:53 PM, Adam Wozniak <awozniak@irobot.com> wrote:
> My guess from this is that I'm using the single stage:
>
> # dmesg | grep ar9170
> [ 273.608189] usb 2-1: firmware: requesting ar9170.fw
> [ 274.019650] Registered led device: ar9170-phy1::tx
> [ 274.019698] Registered led device: ar9170-phy1::assoc
> [ 274.019751] usbcore: registered new interface driver ar9170usb
Affirmative.
Luis
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Adam Wozniak @ 2009-11-04 21:53 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Christian Lamparter, Derek Smithies, linux-wireless, nbd
In-Reply-To: <43e72e890911041350i75108dc3g454ab8577d8abacd@mail.gmail.com>
My guess from this is that I'm using the single stage:
# dmesg | grep ar9170
[ 273.608189] usb 2-1: firmware: requesting ar9170.fw
[ 274.019650] Registered led device: ar9170-phy1::tx
[ 274.019698] Registered led device: ar9170-phy1::assoc
[ 274.019751] usbcore: registered new interface driver ar9170usb
Luis R. Rodriguez wrote:
> On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
>
>> $ ls -la /lib/firmware/ar9170*
>> -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
>> -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
>> -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
>>
>> It is unclear to me which are actually used.
>>
>
> By default the ar9170.fw is tried first, if that fails then the others
> are tried. The 2-stage firmware will not be tried if your device
> cannot handle it but right now only the AVM Fritz devices can't handle
> the 2-stage firmware.
>
> Christian should we just remove 2-stage fw support?
>
> Luis
>
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 21:52 UTC (permalink / raw)
To: Nick Kossifidis
Cc: linux-wireless, ath5k-devel, Matthew Wilcox, Stephen Hemminger,
Kyle McMartin
In-Reply-To: <43e72e890911041352i334e170at71a519383d48a08@mail.gmail.com>
On Wed, Nov 4, 2009 at 1:52 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 1:36 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Wed, Nov 4, 2009 at 1:30 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> On Wed, Nov 4, 2009 at 12:12 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
>>>> 2009/11/4 Luis R. Rodriguez <mcgrof@gmail.com>:
>>>>> Curious if anyone recalls the issues seen with enabling MWI on ath5k.
>>>>> I could have sworn there was some discussion on this but for the life
>>>>> of me I cannot find it.
>>>>>
>>>>> Luis
>>>>
>>>> Maybe this one ?
>>>> http://osdir.com/ml/linux.drivers.ath5k.devel/2008-07/msg00088.html
>>>
>>> That was it, thanks! For the record then Kyle pointed to this bug:
>>>
>>> http://marc.info/?t=121430463700001&r=1&w=2
>>>
>>> as a reference for possible issues.
>>
>> Actually the threads above are for MSI, not MWI, which would be set
>> with pci_set_mwi() not pci_disable_msi().
>>
>> MWI is for enabling memory write invalidate.
>>
>> I guess we never had the MWI discussion then for ath5k,
>>
>> Either way I'm reluctant to enable it and was actually considering
>> simplifying the the PCI cache line size thing on ath/ath5k/ath9k. Will
>> send an RFC.
>
> Even better: I just confirmation from our systems team that our legacy
> devices and 11n PCI devices don't support MWR so I'll remove all that
> cruft crap.
I meant MWI of course.
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 21:52 UTC (permalink / raw)
To: Nick Kossifidis
Cc: linux-wireless, ath5k-devel, Matthew Wilcox, Stephen Hemminger,
Kyle McMartin
In-Reply-To: <43e72e890911041336n7ffae0d2u135321a588f3e613@mail.gmail.com>
On Wed, Nov 4, 2009 at 1:36 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 1:30 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Wed, Nov 4, 2009 at 12:12 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
>>> 2009/11/4 Luis R. Rodriguez <mcgrof@gmail.com>:
>>>> Curious if anyone recalls the issues seen with enabling MWI on ath5k.
>>>> I could have sworn there was some discussion on this but for the life
>>>> of me I cannot find it.
>>>>
>>>> Luis
>>>
>>> Maybe this one ?
>>> http://osdir.com/ml/linux.drivers.ath5k.devel/2008-07/msg00088.html
>>
>> That was it, thanks! For the record then Kyle pointed to this bug:
>>
>> http://marc.info/?t=121430463700001&r=1&w=2
>>
>> as a reference for possible issues.
>
> Actually the threads above are for MSI, not MWI, which would be set
> with pci_set_mwi() not pci_disable_msi().
>
> MWI is for enabling memory write invalidate.
>
> I guess we never had the MWI discussion then for ath5k,
>
> Either way I'm reluctant to enable it and was actually considering
> simplifying the the PCI cache line size thing on ath/ath5k/ath9k. Will
> send an RFC.
Even better: I just confirmation from our systems team that our legacy
devices and 11n PCI devices don't support MWR so I'll remove all that
cruft crap.
Luis
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ivo van Doorn @ 2009-11-04 21:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Bartlomiej Zolnierkiewicz, linux-wireless, linux-kernel, netdev,
Randy Dunlap, Luis Correia, John W. Linville, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <20091104083737.GA16978@elte.hu>
On Wednesday 04 November 2009, Ingo Molnar wrote:
>
> * Ivo van Doorn <ivdoorn@gmail.com> wrote:
>
> > > MAINTAINERS: add rt2800 entry
> >
> > I see you decided to take over the maintainership? Doesn't that need
> > the current maintainer to move away, or was this part of the "going
> > over other peoples head" plan?
> >
> > [...]
> >
> > These are too much (and too big) patches for me to review at once,
> > I'll look at them later.
>
> Frankly, having read through the recent discussions related to the
> rt2800pci/usb drivers, the subtle (and largely undeserved) group
> violence and abuse you are inflicting on Bart is stomach-turning.
>
> The non-working rt2800pci driver has been pending in your private tree
> for how long, 1.5 _years_?
Something like that.
> Look at the diffstat of Bart's driver:
>
> 15 files changed, 4036 insertions(+), 7158 deletions(-)
>
> He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_
> driver.
Bullshit, read the mails again.
I have acked a portion of fixes because those were small and obviously
correct. There are some minor bugfixes in them but none of them would
magically make the card work for everybody. So the number of lines is
decreased but the status of the driver is the same.
Some people actually require sleep during the night, perhaps that you don't need
that and can hence review 41 patches which changes thousands of lines on the
same day the patches were submitted.
> And _still_ your complaint about Bart's series is that he updated the
> MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should
> update it, he is the one doing the hard work of trying to bring it to
> users, trying to clean up a messy driver space, trying to turn crap into
> gold.
So if I want to focus on something different in the kernel, I just send 1 patch,
and a second to claim the maintainership of it even though there is an active
maintainer available?
> The thing is, if you dont have the time or interest to listen to and act
> upon review feedback, be constructive about it and fix (obvious)
> structural problems in your rt2800 code, you should just step aside and
> let Bart maintain what he is apparently more capable of maintaining than
> you are.
>
> What you are doing here is a thinly veiled land-grab: you did a minimal
> token driver for rt2800 that doesnt work, kept it in your private tree
> for _1.5 years_, and the moment someone _else_ came along and did
> something better and more functional in drivers/staging/, you discovered
> your sudden interest for it and moved the crappy driver upstream at
> lightning's speed (it is already in net-next AFAICS, despite negative
> test and review feedback) - ignoring and throwing away all the work that
> Bart has done.
Get your facts straight, the bullshit level in your mail is staggering.
You have no fucking clue who wrote the rt2800 driver which is in drivers/staging/,
you have no clue why it was added, and you don't even know what the intention
was for that driver from day 1 (which was clearly communicated!)
You even are missing the point _why_ the rt2x00 driver was 1.5 years in development,
but I'll highlight that part for you:
Because a lot of people prefer looking from the sideline, contributing _nothing_
and then after a year complain that the development is going too slowly and they
could have done better. Apparently that is the style you prefer, but that is most
definately _not_ how I think Open Source should work.
As for "throwing away that work" I ACKED 10 of his patches, and said I would review
the rest later! But like I said, apparently it is a bad habit for people to sleep during
the night.
> Such behavior wouldnt fly in _any_ other Linux subsystem, but apparently
> there is one set of rules for upstream kernel maintainers and then
> there's another, different set of rules for upstream wireless driver
> maintainers.
So non-wireless maintainers don't need to review patches before giving their Ack?
Well that makes the Acked-by and Signed-off rules completely meaningless,
I wonder why everybody is demanding it before patches are merged...
Ivo
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Luis R. Rodriguez @ 2009-11-04 21:50 UTC (permalink / raw)
To: Adam Wozniak; +Cc: Christian Lamparter, Derek Smithies, linux-wireless, nbd
In-Reply-To: <4AF1F653.4000905@irobot.com>
On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
>
> $ ls -la /lib/firmware/ar9170*
> -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
> -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
> -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
>
> It is unclear to me which are actually used.
By default the ar9170.fw is tried first, if that fails then the others
are tried. The 2-stage firmware will not be tried if your device
cannot handle it but right now only the AVM Fritz devices can't handle
the 2-stage firmware.
Christian should we just remove 2-stage fw support?
Luis
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Adam Wozniak @ 2009-11-04 21:46 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Derek Smithies, linux-wireless, nbd
In-Reply-To: <200911042242.48991.chunkeey@googlemail.com>
$ ls -la /lib/firmware/ar9170*
-rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
-rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
-rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
It is unclear to me which are actually used. I will try removing the
two stage firmware files and see what happens.
Christian Lamparter wrote:
> On Wednesday 04 November 2009 22:01:39 Derek Smithies wrote:
>
>> Hi,
>> On Wed, 4 Nov 2009, Christian Lamparter wrote:
>>
>>
>>> On Wednesday 04 November 2009 02:13:49 Adam Wozniak wrote:
>>>
>>>> I have two systems under test, both Dell laptops (a Latitude D630 and an
>>>> Inspiron 600m) both running Ubuntu 9.10 with the latest updates, and
>>>> bleeding edge compat-wireless-2009-11-02. I'm using identical AR9170
>>>> based D-Link DWA-160 USB 802.11adapters. I'm using nuttcp to measure
>>>> throughput. I'm running in ad-hoc mode. Both machines have the same
>>>> ar9170 files in /lib/firmware. The machines are sitting about 5 feet
>>>> apart in my office.
>>>>
> by the way: I forgot to ask, but which firmware do you use?
> If you still have *two - stage*, then get rid of it.
> Since one-stage fws contain a few fixes for most temporarily MAC/BB-hiccups.
>
>
>>>> I'm having occasional problems where throughput drops through the floor
>>>> (0.5Mbps - 1.5Mbps). When I cat
>>>> /sys/kernel/debug/ieee80211/*/stations/*/rc_stats, one of the machines
>>>> lists the full set of rates, but the other only lists 1M and 54M. After
>>>> a period of time, that machine drops 54M and lists only one rate
>>>> (1Mbps), and the throughput listed by nuttcp drops accordingly. I
>>>> assume that, for whatever reason, the rates drop off the list and
>>>> minstrel uses the only one left available to it.
>>>>
>>>> If I modify include/net/mac80211.h and force the inline function
>>>> rate_supported to always return 1, this fixes the problem. However, I
>>>> think this is a band aid around some other issue.
>>>>
>>>> Any clues or ideas what the real issue might be here?
>>>>
>> My guess::
>>
>> When an adhoc node (call it A) merges with a second adhoc node (call it
>> B) there is a capability comparison.
>> Node A looks at the rates supported by B and says,
>> "I must only transmit at rates supported by B"
>>
>> Some management frames don't contain a full report of the rates supported
>> by the sender.
>> My view is that node A (in this example) is incorrectly determining that B
>> only supports the 1mb/sec rate. Consequently, node A fills the
>> rate_supported array with one rate - 1mb/sec.
>>
> well, that's the thing... it sounds like something in cfg80211/mac80211 has
> gone wrong. Since ibss supported/basic rates IEs should always include all
> mandatory rates for the given band & mode. Therefore you should see the
> 2Mbit, 11Mbit, 6MBit, 12Mbit 24Mbit rates in rc_stats array as well.
>
>
>> =====
>>
> =====
>
>
>> There is no evidence that Minstrel is doing anything wrong.
>>
> ?but no one said it was minstrel fault? And it clearly isn't.
>
> But something OT: do you have already thoughts about
> _extending_ minstrel to support 802.11n MCS rates?
>
> The current endeavor is stuck and needs a kick-start.
> This is partly because of a hen-egg problem:
> no driver <-> no 11n rc. But it should be easy to get
> 11n capable hw now (e.g. Mikrotik's R52N) and
> ath9k should be the perfect testing platform right now.
>
> nbd has/had some thought about grouping rates and options
> (e.g SGI/40MHz) together to reduce the number of rates to
> improve the _search for best tp_ time. But dunno, maybe he
> has already something better than the proof-of-concept I wrote earlier.
>
> Regards,
> Chr
>
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Christian Lamparter @ 2009-11-04 21:42 UTC (permalink / raw)
To: Derek Smithies; +Cc: Adam Wozniak, linux-wireless, nbd
In-Reply-To: <alpine.DEB.2.00.0911050951000.16407@kauri.acheron.indranet.co.nz>
On Wednesday 04 November 2009 22:01:39 Derek Smithies wrote:
> Hi,
> On Wed, 4 Nov 2009, Christian Lamparter wrote:
>
> > On Wednesday 04 November 2009 02:13:49 Adam Wozniak wrote:
> >> I have two systems under test, both Dell laptops (a Latitude D630 and an
> >> Inspiron 600m) both running Ubuntu 9.10 with the latest updates, and
> >> bleeding edge compat-wireless-2009-11-02. I'm using identical AR9170
> >> based D-Link DWA-160 USB 802.11adapters. I'm using nuttcp to measure
> >> throughput. I'm running in ad-hoc mode. Both machines have the same
> >> ar9170 files in /lib/firmware. The machines are sitting about 5 feet
> >> apart in my office.
by the way: I forgot to ask, but which firmware do you use?
If you still have *two - stage*, then get rid of it.
Since one-stage fws contain a few fixes for most temporarily MAC/BB-hiccups.
> >> I'm having occasional problems where throughput drops through the floor
> >> (0.5Mbps - 1.5Mbps). When I cat
> >> /sys/kernel/debug/ieee80211/*/stations/*/rc_stats, one of the machines
> >> lists the full set of rates, but the other only lists 1M and 54M. After
> >> a period of time, that machine drops 54M and lists only one rate
> >> (1Mbps), and the throughput listed by nuttcp drops accordingly. I
> >> assume that, for whatever reason, the rates drop off the list and
> >> minstrel uses the only one left available to it.
> >>
> >> If I modify include/net/mac80211.h and force the inline function
> >> rate_supported to always return 1, this fixes the problem. However, I
> >> think this is a band aid around some other issue.
> >>
> >> Any clues or ideas what the real issue might be here?
>
> My guess::
>
> When an adhoc node (call it A) merges with a second adhoc node (call it
> B) there is a capability comparison.
> Node A looks at the rates supported by B and says,
> "I must only transmit at rates supported by B"
>
> Some management frames don't contain a full report of the rates supported
> by the sender.
> My view is that node A (in this example) is incorrectly determining that B
> only supports the 1mb/sec rate. Consequently, node A fills the
> rate_supported array with one rate - 1mb/sec.
well, that's the thing... it sounds like something in cfg80211/mac80211 has
gone wrong. Since ibss supported/basic rates IEs should always include all
mandatory rates for the given band & mode. Therefore you should see the
2Mbit, 11Mbit, 6MBit, 12Mbit 24Mbit rates in rc_stats array as well.
> =====
=====
> There is no evidence that Minstrel is doing anything wrong.
?but no one said it was minstrel fault? And it clearly isn't.
But something OT: do you have already thoughts about
_extending_ minstrel to support 802.11n MCS rates?
The current endeavor is stuck and needs a kick-start.
This is partly because of a hen-egg problem:
no driver <-> no 11n rc. But it should be easy to get
11n capable hw now (e.g. Mikrotik's R52N) and
ath9k should be the perfect testing platform right now.
nbd has/had some thought about grouping rates and options
(e.g SGI/40MHz) together to reduce the number of rates to
improve the _search for best tp_ time. But dunno, maybe he
has already something better than the proof-of-concept I wrote earlier.
Regards,
Chr
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 21:36 UTC (permalink / raw)
To: Nick Kossifidis
Cc: linux-wireless, ath5k-devel, Matthew Wilcox, Stephen Hemminger,
Kyle McMartin
In-Reply-To: <43e72e890911041330j581e7bacp4e7b83a11c1de0e8@mail.gmail.com>
On Wed, Nov 4, 2009 at 1:30 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 12:12 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
>> 2009/11/4 Luis R. Rodriguez <mcgrof@gmail.com>:
>>> Curious if anyone recalls the issues seen with enabling MWI on ath5k.
>>> I could have sworn there was some discussion on this but for the life
>>> of me I cannot find it.
>>>
>>> Luis
>>
>> Maybe this one ?
>> http://osdir.com/ml/linux.drivers.ath5k.devel/2008-07/msg00088.html
>
> That was it, thanks! For the record then Kyle pointed to this bug:
>
> http://marc.info/?t=121430463700001&r=1&w=2
>
> as a reference for possible issues.
Actually the threads above are for MSI, not MWI, which would be set
with pci_set_mwi() not pci_disable_msi().
MWI is for enabling memory write invalidate.
I guess we never had the MWI discussion then for ath5k,
Either way I'm reluctant to enable it and was actually considering
simplifying the the PCI cache line size thing on ath/ath5k/ath9k. Will
send an RFC.
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 21:30 UTC (permalink / raw)
To: Nick Kossifidis
Cc: linux-wireless, ath5k-devel, Matthew Wilcox, Stephen Hemminger
In-Reply-To: <40f31dec0911041212p16cfc78eia1ab1817e425e767@mail.gmail.com>
On Wed, Nov 4, 2009 at 12:12 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
> 2009/11/4 Luis R. Rodriguez <mcgrof@gmail.com>:
>> Curious if anyone recalls the issues seen with enabling MWI on ath5k.
>> I could have sworn there was some discussion on this but for the life
>> of me I cannot find it.
>>
>> Luis
>
> Maybe this one ?
> http://osdir.com/ml/linux.drivers.ath5k.devel/2008-07/msg00088.html
That was it, thanks! For the record then Kyle pointed to this bug:
http://marc.info/?t=121430463700001&r=1&w=2
as a reference for possible issues.
Luis
^ permalink raw reply
* Re: [PATCH] libertas if_usb: Fix crash on 64-bit machines
From: John W. Linville @ 2009-11-04 21:16 UTC (permalink / raw)
To: Dan Williams
Cc: David Woodhouse, Christian Lamparter, Larry Finger, libertas-dev,
linux-wireless, stern, davem
In-Reply-To: <1257364903.14545.51.camel@localhost.localdomain>
On Wed, Nov 04, 2009 at 12:01:43PM -0800, Dan Williams wrote:
> On Wed, 2009-11-04 at 19:36 +0000, David Woodhouse wrote:
> > On Wed, 2009-11-04 at 14:16 -0500, John W. Linville wrote:
> > > Is anyone evaluating these suggestions? Should I be expecting
> > > properly formatted patch emails?
> >
> > The suggestions make sense, but not for stable. Let's fix the crasher
> > bug first, and worry about the rest later.
>
> Sounds good to me...
Yes, of course.
So, Christian, will you be following-up?
Thanks!
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: pull request: wireless-next-2.6 2009-10-28
From: Ivo van Doorn @ 2009-11-04 21:17 UTC (permalink / raw)
To: Jiri Kosina
Cc: Pavel Machek, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <alpine.LRH.2.00.0911041403480.31913@twin.jikos.cz>
On Wednesday 04 November 2009, Jiri Kosina wrote:
> On Mon, 2 Nov 2009, Pavel Machek wrote:
>
> > > I've searched on my GMail archives and the only patch Bart has
> > > provided so far for the rt2x00 project is this:
> > >
> > > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > >
> > > Which, while technically correct, adds nothing to the project.
> > >
> > > So, I will personally continue to ignore Bart's comments, regards and
> > > rants, until he provides patches for rt2x00 that actually make the
> > > driver better.
> >
> > Well, he provided review feedback... he should be thanked for that,
> > not flamed for it.
>
> He has actually written real patches (and quite non-trivial both in amount
> and in functionality), see
>
> http://lkml.org/lkml/2009/11/3/372
Please look at the TIMESTAMP of the mail you refer to, and the TIMESTAMP
of the mail from Luis. And then you can make assumptions about the text...
> But yes, he got flamed for this for some odd reason. I got the impression
> that the community around rt2x00 doesn't like (or understand) the way how
> opensource development happens.
Well you mean the open source development where non-contributors
complain that the contributors work too slowly? Well if that is the way
things should go, then I don't want to be part of such idiocy. Perhaps
that is the policy in some companies which try to import it into the
Open Source world...
Ivo
^ 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