* Re: [RFC] [PATCH] ethtool: Change ethtool_op_set_flags to validate flags
From: David Miller @ 2010-06-30 20:47 UTC (permalink / raw)
To: sgruszka; +Cc: bhutchings, amit.salecha, netdev, amwang, anirban.chakraborty
In-Reply-To: <20100630132111.72559f9f@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed, 30 Jun 2010 13:21:11 +0200
> On Tue, 29 Jun 2010 17:01:01 +0100
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
>> This is the sort of change I'd like to see.
...
> Looks good for me as well.
>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Me too.
Ben, please submit this formally.
^ permalink raw reply
* Re: [PATCH v3] fragment: add fast path for in-order fragments
From: David Miller @ 2010-06-30 20:44 UTC (permalink / raw)
To: xiaosuo
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev,
erblichs
In-Reply-To: <1277822377-742-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 29 Jun 2010 22:39:37 +0800
> add fast path for in-order fragments
>
> As the fragments are sent in order in most of OSes, such as Windows, Darwin and
> FreeBSD, it is likely the new fragments are at the end of the inet_frag_queue.
> In the fast path, we check if the skb at the end of the inet_frag_queue is the
> prev we expect.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Mitchell Erblich @ 2010-06-30 20:43 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <AANLkTimpofANvn-sDZrE3kdq9owzYe8DJa8OfuVK04cM@mail.gmail.com>
On Jun 30, 2010, at 1:14 PM, Ivan Novick wrote:
> On Wed, Jun 30, 2010 at 1:06 PM, Mitchell Erblich
> <erblichs@earthlink.net> wrote:
>> On Jun 30, 2010, at 11:04 AM, Ivan Novick wrote:
> ... snip ...
>> Sometimes, adding tracing within the tcps, can identify if.
>> the tcp flow has periods of idleness,
>> the tcp flow is/has been application limited versus network limited,
>> whether the flow is in SS or CA?
>> CA normally has DELayed ACks, which reduces the number
>> of ACKs to 1/2 or more,
>> Whether Fast re-xmit is triggered by 2 or 3 DupAcks.
>> whether any burst avoidance has occured,
>> etc,
>
> Hi Mitchell,
>
> When you say adding tracing within the tcps... what method are you
> referring to, to add this tracing? Is it some tool or setting or are
> you talking about adding custom debugging output to the kernel?
>
> Cheers,
> Ivan
Ivan,
Custom debug code that was added into the fast-path
when extensive tcp flow analysis is desired.
Uses a runtime /proc var to not effect the fast-path
that by default is dis-abled.
Mitchell Erblich
^ permalink raw reply
* Re: [PATCH net-next-2.6] snmp: 64bit ipstats_mib for all arches
From: David Miller @ 2010-06-30 20:30 UTC (permalink / raw)
To: yoshfuji; +Cc: eric.dumazet, netdev
In-Reply-To: <4C2A0C22.4010202@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Wed, 30 Jun 2010 00:07:14 +0900
> Hello.
>
> Thank you for doing this work!
>
> Eric Dumazet wrote:
>> /proc/net/snmp and /proc/net/netstat expose SNMP counters.
>> Width of these counters is either 32 or 64 bits, depending on the size
>> of "unsigned long" in kernel.
>> This means user program parsing these files must already be prepared
>> to
>> deal with 64bit values, regardless of user program being 32 or 64 bit.
>
> Well, I'm rather not in favor of breaking user-space apps.
Eric has explained that applications must already be able to cope with
64-bit values here. I think this is a valid change to make and
telling users that non-broken (read as: 64-bit) stats are only
available via netlink is not a reasonable thing at all.
I'm going to apply Eric's patch.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net: memory barrier fixes on IBM p7 platform
From: David Miller @ 2010-06-30 20:27 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100629101117.GA2338@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 29 Jun 2010 15:41:17 +0530
> The ibm p7 architecure seems to reorder memory accesses more
> aggressively than previous ppc64 architectures. This requires memory
> barriers to ensure that rx/tx doorbells are pressed only after
> memory to be DMAed is written.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied, but I had to fix something:
> @@ -972,7 +976,8 @@ static struct be_eth_rx_compl *be_rx_compl_get(struct be_adapter *adapter)
>
> if (rxcp->dw[offsetof(struct amap_eth_rx_compl, valid) / 32] == 0)
> return NULL;
> -
> +
> + rmb();
That first addition does nothing but add erroneous trailing
whitespace.
You can physically see that something must be wrong here just by look
at this patch chunk, please review things more thoroughly before
submitting in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix b44 RX FIFO overflow recovery.
From: David Miller @ 2010-06-30 20:25 UTC (permalink / raw)
To: james.dutton; +Cc: netdev
In-Reply-To: <AANLkTik2BadzkkVcmlhgWh6rcLDm1kEu0RDqWuILnwVZ@mail.gmail.com>
From: James Courtier-Dutton <james.dutton@gmail.com>
Date: Wed, 30 Jun 2010 21:11:18 +0100
> diff --git a/drivers/net/b44.c b/drivers/net/b44.c
> index 69d9f3d..72537c1 100644
> --- a/drivers/net/b44.c
> +++ b/drivers/net/b44.c
> @@ -852,12 +852,46 @@ static int b44_poll(struct napi_struct *napi, int budget)
> /* spin_unlock(&bp->tx_lock); */
> }
> spin_unlock_irqrestore(&bp->lock, flags);
> + if (bp->istat & ISTAT_DSCE)
> + {
> + printk(KERN_INFO "b44_poll: ISTAT_DSCE\n");
> + }
Using braces here is overkill, and even if it was appropriate it's formatted
incorrectly, it should be:
if (x)
y;
for single-line code blocks, and:
if (x) {
y;
z;
}
For multi-line code blocks.
^ permalink raw reply
* Re: b44: Reset due to FIFO overflow.
From: David Miller @ 2010-06-30 20:22 UTC (permalink / raw)
To: james.dutton; +Cc: eric.dumazet, erblichs, netdev
In-Reply-To: <AANLkTimK4mGdsSq206aqfusXPvnQczbYDlOWSYXAbOQJ@mail.gmail.com>
From: James Courtier-Dutton <james.dutton@gmail.com>
Date: Mon, 28 Jun 2010 11:17:59 +0100
> Interesting, which hardware, apart from the b44, is it that "requires"
> a hardware reset after a RX FIFO overflow.
This problem is quite common, actually.
Even though it shouldn't be, this is seemingly one of the least tested
paths of a networking chip.
You'd think the recovery would be easy, flush the fifos and drop the
packet, then rewind the RX descriptor pointer.
But it's not and I've seen everything from RX descriptor corruption
to random DMA splats elsewhere corrupting memory entirely, as a result
of a networking card taking a RX fifo overflow.
^ permalink raw reply
* Re: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
From: David Miller @ 2010-06-30 20:16 UTC (permalink / raw)
To: pedro.netdev; +Cc: netdev, kaber, bhutchings, eric.dumazet
In-Reply-To: <c38a6e1add643eb78bd0d28ee3984cf4@dondevamos.com>
From: Pedro Garcia <pedro.netdev@dondevamos.com>
Date: Mon, 28 Jun 2010 01:21:19 +0200
> Last version of the patch. Now I think it is OK, of course pending
> Eric's signed-off-by for the accel HW part.
Eric, please review.
>
> If this is too long for a changelog, tell me and I will try to sum it
> up:
To me, not commit message is too long, the more the better. :)
> + if ((event == NETDEV_UP) &&
> + (dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + (dev->netdev_ops->ndo_vlan_rx_add_vid)) {
There is no reason to surround this final NULL pointer check with
parenthesis, it just makes reading it confusing.
> + if (vlan_dev)
> + skb->dev = vlan_dev;
> + else
> + if (vlan_id)
> + goto drop;
Please format this as:
if (a)
b;
else if (c)
d;
> + if (vlan_dev)
> + skb->dev = vlan_dev;
> + else
> + if (vlan_id)
> + goto drop;
Same here.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Ivan Novick @ 2010-06-30 20:14 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <9E73042B-BF54-48FD-8755-C215FD03C9AE@earthlink.net>
On Wed, Jun 30, 2010 at 1:06 PM, Mitchell Erblich
<erblichs@earthlink.net> wrote:
> On Jun 30, 2010, at 11:04 AM, Ivan Novick wrote:
... snip ...
> Sometimes, adding tracing within the tcps, can identify if.
> the tcp flow has periods of idleness,
> the tcp flow is/has been application limited versus network limited,
> whether the flow is in SS or CA?
> CA normally has DELayed ACks, which reduces the number
> of ACKs to 1/2 or more,
> Whether Fast re-xmit is triggered by 2 or 3 DupAcks.
> whether any burst avoidance has occured,
> etc,
Hi Mitchell,
When you say adding tracing within the tcps... what method are you
referring to, to add this tracing? Is it some tool or setting or are
you talking about adding custom debugging output to the kernel?
Cheers,
Ivan
^ permalink raw reply
* Re: [patch] cpmac: use resource_size()
From: David Miller @ 2010-06-30 20:12 UTC (permalink / raw)
To: error27; +Cc: florian, jpirko, eric.dumazet, netdev, kernel-janitors
In-Reply-To: <20100628211933.GL19184@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 28 Jun 2010 23:19:33 +0200
> The original code is off by one because we should start counting at
> zero. So the size of the resource is end - start + 1. I switched it to
> use resource_size() to do the calculation.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied to net-next-2.6, thanks Dan.
^ permalink raw reply
* [PATCH] Fix b44 RX FIFO overflow recovery.
From: James Courtier-Dutton @ 2010-06-30 20:11 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
Hi,
This patch improves the recovery after a RX FIFO overflow on the b44
Ethernet NIC.
Before it would do a complete chip reset, resulting is loss of link
for a few seconds.
This patch improves this to do recovery in about 20ms without loss of link.
Kind Regards
James
b44: Handle RX FIFO overflow better.
Signed off by: James@superbug.co.uk
[-- Attachment #2: b44-fix-rx-overflow.txt --]
[-- Type: text/plain, Size: 1363 bytes --]
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 69d9f3d..72537c1 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -852,12 +852,46 @@ static int b44_poll(struct napi_struct *napi, int budget)
/* spin_unlock(&bp->tx_lock); */
}
spin_unlock_irqrestore(&bp->lock, flags);
+ if (bp->istat & ISTAT_DSCE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DSCE\n");
+ }
+ if (bp->istat & ISTAT_DATAE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DATAE\n");
+ }
+ if (bp->istat & ISTAT_DPE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DPE\n");
+ }
+ if (bp->istat & ISTAT_RDU)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_RDU\n");
+ }
+ if (bp->istat & ISTAT_RFO)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_RFO\n");
+ spin_lock_irqsave(&bp->lock, flags);
+ b44_disable_ints(bp);
+ /* This resets the ISTAT_RFO flag */
+ ssb_device_enable(bp->sdev, 0);
+ b44_init_rings(bp);
+ b44_init_hw(bp, B44_FULL_RESET_SKIP_PHY);
+ netif_wake_queue(bp->dev);
+ spin_unlock_irqrestore(&bp->lock, flags);
+ work_done = 0;
+ }
+ if (bp->istat & ISTAT_TFU)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_TFU\n");
+ }
+
work_done = 0;
if (bp->istat & ISTAT_RX)
work_done += b44_rx(bp, budget);
- if (bp->istat & ISTAT_ERRORS) {
+ if ((bp->istat & ISTAT_ERRORS) && !(bp->istat & ISTAT_RFO)) {
spin_lock_irqsave(&bp->lock, flags);
b44_halt(bp);
b44_init_rings(bp);
^ permalink raw reply related
* Re: [PATCH 0/4] Introduce and use printk pointer extension %pV
From: David Miller @ 2010-06-30 20:07 UTC (permalink / raw)
To: joe; +Cc: akpm, linux-kernel, netdev, greg
In-Reply-To: <cover.1277636090.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 27 Jun 2010 04:02:32 -0700
> Recursive printk can reduce the total image size of an x86 defconfig about 1%
> by reducing duplicated KERN_<level> strings and centralizing the functions
> used by macros in new separate functions.
>
> Joe Perches (4):
> vsprintf: Recursive vsnprintf: Add "%pV", struct va_format
> device.h drivers/base/core.c Convert dev_<level> logging macros to functions
> netdevice.h net/core/dev.c: Convert netdev_<level> logging macros to functions
> netdevice.h: Change netif_<level> macros to call netdev_<level> functions
I'm fine with this, thanks Joe.
Greg, could you ACK this and let me know if it's OK if it swings
through my net-next-2.6 tree?
Thanks.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Mitchell Erblich @ 2010-06-30 20:06 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <AANLkTinJC6uS1GTbKJWL9AlEs2e5GleQvJbTUZrsQHaE@mail.gmail.com>
On Jun 30, 2010, at 11:04 AM, Ivan Novick wrote:
> Hello all,
>
> Attached is a packet capture from my application that is running on
> RedHat Enterprise Linux 5.4
>
> I am seeing a Retransmission timeout but I was hoping this case would
> go into fast retransmit and not RTO.
>
> I am wondering why did the sender not send more data? If the sender
> was to send more data and extend the window then it would seem the
> duplicate acks or SACKS should trigger fast retransmit.
>
> The application does not constantly send data, but data should arrive
> to be sent before 200 milliseconds that it takes for the RTO.
>
> Is it possible that there was no data to send and the window is not
> advanced and the sender is waiting for an ACK. Then data arrives half
> way into the RTO 200 milliseconds while waiting for an outstanding ACK
> but the window is not advanced?
>
> You can see right after the RTO and retransmission additional data is
> sent, so there is additional data. In theory that additional data
> could be arriving right at the 200 milliseconds point, but we see this
> pattern in the dump regularly and I believe data is there before the
> end of the 200 milliseconds RTO.
>
> As a related point the advertised window from the receiver seems to be
> a constant value of 22060, so either the receiver is handling its data
> fast enough to never have to reduce its window... or this number is
> really not used to indicate space available currently in the receive
> window?
>
> Any feedback to help understand why we are not doing fast retransmit
> and or why the sender is not extending the window would be greatly
> appreciated.
>
> Cheers,
> Ivan Novick
> <sender_backoff.cap>
Ivan, et al,
Without looking at your dump, not getting DUPAcks then
- their isn't enough in-flight data/ segments to generate enough ACKs (Duplicate ACKs)
assuming you get ACKs with non-increasing SEQs
- or the/some ACKs are being dropped.
Normally to fix this is to set the MTU / MSS size to say 576 at the two
end points if this is re-runnable, OR make it a thin flow
With a real quick look at your dump,
my first question is why the .1 -> .2 always has a small window of 46
one way data transfer?
Now, taking a look at the dump with a -r ,
What makes you think that DupACKs are being sent?
To then cause a Fast Re-transmit?
Sometimes, adding tracing within the tcps, can identify if.
the tcp flow has periods of idleness,
the tcp flow is/has been application limited versus network limited,
whether the flow is in SS or CA?
CA normally has DELayed ACks, which reduces the number
of ACKs to 1/2 or more,
Whether Fast re-xmit is triggered by 2 or 3 DupAcks.
whether any burst avoidance has occured,
etc,
Mitchell Erblich
^ permalink raw reply
* Re: [PATCH 1/2 v3] mv643xx_eth: use sw csum for big packets
From: David Miller @ 2010-06-30 20:01 UTC (permalink / raw)
To: saeed; +Cc: netdev
In-Reply-To: <1277634403-1018-1-git-send-email-saeed@marvell.com>
From: Saeed Bishara <saeed@marvell.com>
Date: Sun, 27 Jun 2010 13:26:43 +0300
> Some controllers (KW, Dove) limits the TX IP/layer4 checksum offloading to a max size.
>
> Signed-off-by: Saeed Bishara <saeed@marvell.com>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: b44: Reset due to FIFO overflow.
From: James Courtier-Dutton @ 2010-06-30 19:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Mitchell Erblich, netdev
In-Reply-To: <1277788678.4235.1285.camel@edumazet-laptop>
On 29 June 2010 06:17, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> rx ring buffer is about 200 frames on b44. One single tcp flow should
> fit.
>
> Limit is 511. James, did you try to increase rx ring ?
>
> ethtool -G eth0 rx 511
>
Any value given to that command results in a non operating NIC.
rmmod b44
modprobe b44 fixes that.
I have narrowed down the problem now.
I can now reset the RX fifo after the RFO in less than 20 ms without
the Ethernet Link going down.
When I get a moment, I will post a patch so other people can test it.
Kind Regards
James
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Brian Bloniarz @ 2010-06-30 19:26 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <AANLkTinJC6uS1GTbKJWL9AlEs2e5GleQvJbTUZrsQHaE@mail.gmail.com>
On 06/30/2010 02:04 PM, Ivan Novick wrote:
> I am wondering why did the sender not send more data? If the sender
> was to send more data and extend the window then it would seem the
> duplicate acks or SACKS should trigger fast retransmit.
Hi Ivan,
Like you said, the receive window can't explain why the sender wouldn't
send. The congestion window is another possible reason why the sender
might not send, though it's sorta impossible to tell if that's really
it from a small tcpdump. Maybe investigating the details of congestion
control might yield something?
HTH,
-Brian
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: Johannes Berg @ 2010-06-30 19:15 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100630.120551.170116973.davem@davemloft.net>
On Wed, 2010-06-30 at 12:05 -0700, David Miller wrote:
> > + /*
> > + * Receiving all multicast frames is always enabled by the
> > + * default flags setup in iwl_connection_init_rx_config()
> > + * since we currently do not support programming multicast
> > + * filters into the device.
> > + */
> > *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> > FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
>
> Note that this is an amazingly serious limitation.
>
> This basically makes iwl chips unsuitable for use on networks where
> real multicast use is common.
Lots of wireless devices have this limitation unfortunately. I think we
-might- be able to have proper filters for iwl, but haven't found out
quite how yet unfortunately, if it's actually implemented properly on
the device and there's not just some fake API.
johannes
^ permalink raw reply
* Re: [PATCH] act_mirred: combine duplicate code
From: David Miller @ 2010-06-30 19:13 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, netdev
In-Reply-To: <1277894942.3509.25.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 30 Jun 2010 06:49:02 -0400
> On Wed, 2010-06-30 at 06:24 -0400, jamal wrote:
>
>> m->tcf_qstats.drops.
>
> Sorry - this nagged me - we are already incrementing overlimits - we
> should increment drops. Scratch that too. I am going to say your patch
> as is:
> signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied.
Jamal, please capitalize "Signed-off-by" in the future, thanks.
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: David Miller @ 2010-06-30 19:12 UTC (permalink / raw)
To: herbert; +Cc: hadi, xiaosuo, netdev
In-Reply-To: <20100630103005.GA24688@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 30 Jun 2010 18:30:05 +0800
> On Wed, Jun 30, 2010 at 06:25:21AM -0400, jamal wrote:
>> On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
>> > act_nat: use stack variable
>> >
>> > structure tc_nat isn't too big for stack, so we can put it in stack.
>> >
>> > Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>>
>> Doesnt look unreasonable - will let Herbert make the call..
>
> Looks good to me too.
Applied.
^ permalink raw reply
* Re: [PATCH] net/neighbour.h: fix typo
From: David Miller @ 2010-06-30 19:07 UTC (permalink / raw)
To: segooon
Cc: trivial, tj, ebiederm, eric.dumazet, shemminger, netdev,
linux-kernel
In-Reply-To: <1277914095-25905-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Wed, 30 Jun 2010 20:08:15 +0400
> 'Shoul' must be 'should'.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: David Miller @ 2010-06-30 19:05 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100630185319.GA2618-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 30 Jun 2010 14:53:20 -0400
> Here are a few more fixes intended for 2.6.35. Included are a couple of
> small regression fixes for iwlwifi, one that causes connection stalls with
> 802.11n on some devices and another which could disable multicast traffic.
> Also included is an ath9k fix which avoids a null pointer dereference
> resulting from a timer leak.
>
> Please let me know if there are problems!
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks John.
> @@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
>
> mutex_unlock(&priv->mutex);
>
> + /*
> + * Receiving all multicast frames is always enabled by the
> + * default flags setup in iwl_connection_init_rx_config()
> + * since we currently do not support programming multicast
> + * filters into the device.
> + */
> *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
Note that this is an amazingly serious limitation.
This basically makes iwl chips unsuitable for use on networks where
real multicast use is common.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull request: wireless-2.6 2010-06-30
From: John W. Linville @ 2010-06-30 18:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
David,
Here are a few more fixes intended for 2.6.35. Included are a couple of
small regression fixes for iwlwifi, one that causes connection stalls with
802.11n on some devices and another which could disable multicast traffic.
Also included is an ath9k fix which avoids a null pointer dereference
resulting from a timer leak.
Please let me know if there are problems!
John
---
The following changes since commit d3ead2413cb99d3e6265577b12537434e229d8c2:
Guillaume Gaudonville (1):
ixgbe: skip non IPv4 packets in ATR filter
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (1):
iwlwifi: fix multicast
Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in starting ani
Wey-Yi Guy (1):
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 6 +-----
drivers/net/wireless/iwlwifi/iwl-core.c | 7 ++++++-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fbb7dec..5ea8773 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -445,6 +445,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index abfa049..1e2a68e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -336,6 +336,10 @@ set_timer:
static void ath_start_ani(struct ath_common *common)
{
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -872,11 +876,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1478,8 +1484,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1500,6 +1508,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
index 44ef5d9..01658cf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
@@ -212,11 +212,7 @@ static void iwlagn_chain_noise_reset(struct iwl_priv *priv)
static void iwlagn_rts_tx_cmd_flag(struct ieee80211_tx_info *info,
__le32 *tx_flags)
{
- if ((info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) ||
- (info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT))
- *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
- else
- *tx_flags &= ~TX_CMD_FLG_RTS_CTS_MSK;
+ *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
}
/* Calc max signal level (dBm) among 3 possible receivers */
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 426e955..5bbc529 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1314,7 +1314,6 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
changed_flags, *total_flags);
CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_ALLMULTI, RXON_FILTER_ACCEPT_GRP_MSK);
CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
@@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
*total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
}
--
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 related
* Re: [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163915.GC23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:15 +0400
> MPC8313ECE says:
>
> "If the controller receives a 1- or 2-byte frame (such as an illegal
> runt packet or a packet with RX_ER asserted) before GRS is asserted
> and does not receive any other frames, the controller may fail to set
> GRSC even when the receive logic is completely idle. Any subsequent
> receive frame that is larger than two bytes will reset the state so
> the graceful stop can complete. A MAC receiver (Rx) reset will also
> reset the state."
>
> This patch implements the proposed workaround:
>
> "If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
> register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
> the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
> If the register fields are not equal, wait for another timeout
> period and check again."
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163913.GB23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:13 +0400
> MPC8313ECE says:
>
> "For TOE=1 huge or jumbo frames, the data required to generate the
> checksum may exceed the 2500-byte threshold beyond which the controller
> constrains itself to one memory fetch every 256 eTSEC system clocks.
>
> This throttling threshold is supposed to trigger only when the
> controller has sufficient data to keep transmit active for the duration
> of the memory fetches. The state machine handling this threshold,
> however, fails to take large TOE frames into account. As a result,
> TOE=1 frames larger than 2500 bytes often see excess delays before start
> of transmission."
>
> This patch implements the workaround as suggested by the errata
> document, i.e.:
>
> "Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
> memory throttling.
> When using packets larger than 2700 bytes, it is recommended to turn TOE
> off."
>
> To be sure, we limit the TOE frames to 2500 bytes, and do software
> checksumming instead.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163912.GA23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:12 +0400
> MPC8313ECE says:
>
> "If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
> which are larger than MAXFRM, the controller truncates the frames to
> length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
> also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
> or MAXFRM-1, even though those frames are not truncated.
> No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
>
> There are two options to workaround the issue:
>
> "1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
> frames. Software can determine if a frame is larger than MAXFRM by
> reading RxBD[LG] or RxBD[Data Length].
>
> 2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
> normal-length frames are not marked as truncated. Software can examine
> RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
>
> This patch implements the first workaround option by setting HUGEFRAME
> bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ 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