* Re: pull request: wireless-next 2013-10-17
From: David Miller @ 2013-10-17 20:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20131017182339.GC1812@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 17 Oct 2013 14:23:40 -0400
> This is a batch of updates intended for the 3.13 stream...
>
> The biggest item of interest in here is wcn36xx, the new mac80211
> driver for Qualcomm WCN3660/WCN3680 hardware.
>
> Regarding the mac80211 bits, Johannes says:
>
> "We have an assortment of cleanups and new features, of which the
> biggest one is probably the channel-switch support in IBSS. Nothing
> else really stands out much."
>
> On top of that, the ath9k and rt2x00 get a lot of update action from
> Felix Fietkau and Gabor Juhos, respectively. There are a handful of
> updates to other drivers here and there as well.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Kristian Evensen @ 2013-10-17 20:14 UTC (permalink / raw)
To: Joe Perches; +Cc: Network Development
In-Reply-To: <1382030610.22110.112.camel@joe-AO722>
Hi,
On Thu, Oct 17, 2013 at 7:23 PM, Joe Perches <joe@perches.com> wrote:
>
> Perhaps this memset should be moved into the
> list_for_each_entry_safe loop where cfg is used.
Thanks for your comment. I decided to put it there to avoid calling it
for each route that will be deleted. Since the struct is never
modified (only read in fib_rtmsg()) and we have the rtnl_lock, I
assumed it to be safe. Are there cases where this assumption is wrong?
-Kristian
^ permalink raw reply
* Re: [PATCH] bridge: Correctly clamp MAX forward_delay when enabling STP
From: David Miller @ 2013-10-17 20:12 UTC (permalink / raw)
To: herbert; +Cc: vyasevic, netdev, shemminger
In-Reply-To: <20131016005657.GA5394@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 16 Oct 2013 08:56:57 +0800
> On Tue, Oct 15, 2013 at 02:57:45PM -0400, Vlad Yasevich wrote:
>> Commit be4f154d5ef0ca147ab6bcd38857a774133f5450
>> bridge: Clamp forward_delay when enabling STP
>> had a typo when attempting to clamp maximum forward delay.
>>
>> It is possible to set bridge_forward_delay to be higher then
>> permitted maximum when STP is off. When turning STP on, the
>> higher then allowed delay has to be clamed down to max value.
>>
>> CC: Herbert Xu <herbert@gondor.apana.org.au>
>> CC: Stephen Hemminger <shemminger@vyatta.com>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>
> Good catch!
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Kristian Evensen @ 2013-10-17 20:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Network Development
In-Reply-To: <alpine.LFD.2.03.1310172245440.2016@ssi.bg>
Hi,
On Thu, Oct 17, 2013 at 9:52 PM, Julian Anastasov <ja@ssi.bg> wrote:
> IIRC, such notifications were not implemented
> to avoid storms to routing daemons. Not sure if this is
> still true.
Thanks for letting me know. I was wondering if this was the case, but
then I saw that the deletion of IPv6 routes are announced (when
running "ip link set dev X down") and assumed that message storms was
(is?) not considered a problem.
-Kristian
^ permalink raw reply
* Re: [PATCH net-next] ipv4: shrink rt_cache_stat
From: David Miller @ 2013-10-17 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381916944.2045.124.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Oct 2013 02:49:04 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Half of the rt_cache_stat fields are no longer used after IP
> route cache removal, lets shrink this per cpu area.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net bridge: remove unused field
From: David Miller @ 2013-10-17 20:10 UTC (permalink / raw)
To: jhs; +Cc: shemminger, netdev
In-Reply-To: <525C5DED.1080406@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 14 Oct 2013 17:11:09 -0400
> Trivial patch
I know it seems rediculous, but anything we export to userspace, as we
do in this UAPI header, could be potentially be used by some piece of
source out there.
I'd rather just leave it be, you can add a comment saying it's unused
if you wish, but I'd really rather not remove it and run the risk of
breaking someone's build out there.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] tcp: remove the sk_can_gso() check from tcp_set_skb_tso_segs()
From: David Miller @ 2013-10-17 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1381865094.2045.69.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Oct 2013 12:24:54 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> sk_can_gso() should only be used as a hint in tcp_sendmsg() to build GSO
> packets in the first place. (As a performance hint)
>
> Once we have GSO packets in write queue, we can not decide they are no
> longer GSO only because flow now uses a route which doesn't handle
> TSO/GSO.
>
> Core networking stack handles the case very well for us, all we need
> is keeping track of packet counts in MSS terms, regardless of
> segmentation done later (in GSO or hardware)
>
> Right now, if tcp_fragment() splits a GSO packet in two parts,
> @left and @right, and route changed through a non GSO device,
> both @left and @right have pcount set to 1, which is wrong,
> and leads to incorrect packet_count tracking.
>
> This problem was added in commit d5ac99a648 ("[TCP]: skb pcount with MTU
> discovery")
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Also applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/2] tcp: must unclone packets before mangling them
From: David Miller @ 2013-10-17 20:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1381863270.2045.62.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Oct 2013 11:54:30 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP stack should make sure it owns skbs before mangling them.
>
> We had various crashes using bnx2x, and it turned out gso_size
> was cleared right before bnx2x driver was populating TC descriptor
> of the _previous_ packet send. TCP stack can sometime retransmit
> packets that are still in Qdisc.
>
> Of course we could make bnx2x driver more robust (using
> ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack.
>
> We have identified two points where skb_unclone() was needed.
>
> This patch adds a WARN_ON_ONCE() to warn us if we missed another
> fix of this kind.
>
> Kudos to Neal for finding the root cause of this bug. Its visible
> using small MSS.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: pull request: wireless 2013-10-15
From: David Miller @ 2013-10-17 20:06 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131015175611.GA15706-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 15 Oct 2013 13:56:12 -0400
> Please pull this batch of fixes intended for the 3.12 stream!
>
> For the mac80211 bits, Johannes says:
>
> "Jouni fixes a remain-on-channel vs. scan bug, and Felix fixes client TX
> probing on VLANs."
>
> And also:
>
> "This time I have two fixes from Emmanuel for RF-kill issues, and fixed
> two issues reported by Evan Huus and Thomas Lindroth respectively."
>
> On top of those...
>
> Avinash Patil adds a couple of mwifiex fixes to properly inform cfg80211
> about some different types of disconnects, avoiding WARNINGs.
>
> Mark Cave-Ayland corrects a pointer arithmetic problem in rtlwifi,
> avoiding incorrect automatic gain calculations.
>
> Solomon Peachy sends a cw1200 fix for locking around calls to
> cw1200_irq_handler, addressing "lost interrupt" problems.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
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
* Re: [PATCH] X.25: Fix address field length calculation
From: David Miller @ 2013-10-17 20:04 UTC (permalink / raw)
To: GKelleter; +Cc: andrew.hendry, linux-x25, netdev, linux-kernel
In-Reply-To: <525D5131.9070007@datus.com>
From: Kelleter, Günther <GKelleter@datus.com>
Date: Tue, 15 Oct 2013 14:29:06 +0000
> Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
>
> Signed-off-by: Guenther Kelleter <gkelleter@datus.com>
> ---
> Wrong length calculation leads to rejection of CALL ACCEPT packets.
This patch doesn't apply because it was severely corrupted by your
email client, turn off all encodings etc. in your client, send
a test patch to yourself, and do not submit this patch again until
you can successfully apply the patch you receive in those test emails.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: David Miller @ 2013-10-17 20:01 UTC (permalink / raw)
To: mrkiko.rs
Cc: gregkh, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel, anto.pellizzari83
In-Reply-To: <1381842408-10800-2-git-send-email-mrkiko.rs@gmail.com>
From: Enrico Mioso <mrkiko.rs@gmail.com>
Date: Tue, 15 Oct 2013 15:06:48 +0200
> This is a QMI device, manufactured by TCT Mobile Phones.
> A companion patch blacklisting this device's QMI interface in the option.c
> driver has been sent.
>
> Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
> Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next REPOST] 8390 ei_debug : Reenable the use of debugging in 8390 based chips
From: David Miller @ 2013-10-17 19:59 UTC (permalink / raw)
To: tedheadster; +Cc: netdev
In-Reply-To: <1381805161-18833-1-git-send-email-tedheadster@gmail.com>
From: Matthew Whitehead <tedheadster@gmail.com>
Date: Mon, 14 Oct 2013 22:46:01 -0400
> Ethernet boards based on the 8390 chip had an '#ifdef notdef' disabling the
> use of the debug variable ei_debug. Reenable it for those of us who still
> occasionally use it.
>
> Also handle the case of the 'ne' driver which uses 8390p.o rather than
> 8390.o. In that case ei_debug is aliased to eip_debug so it doesn't clash
> with the previously exported ei_debug.
>
> Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
I'd rather not encourage the use of things like this.
We have a standard, run time, way to enable and disable debugging
output on a per-netdevice basis. And the "default" value of which can
be controlled by a module parameter if need be.
Please convert the driver to this method instead.
Thank you.
^ permalink raw reply
* Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled
From: David Miller @ 2013-10-17 19:57 UTC (permalink / raw)
To: rdunlap; +Cc: thierry.reding, linux-next, linux-kernel, broonie, netdev
In-Reply-To: <525C47C0.2000907@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 14 Oct 2013 12:36:32 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix (a few hundred) build errors due to missing semi-colon when
> KMEMCHECK is enabled:
>
> include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
> include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH net V2 2/2] virtio-net: refill only when device is up during setting queues
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <1381807139-3450-2-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:59 +0800
> We used to schedule the refill work unconditionally after changing the
> number of queues. This may lead an issue if the device is not
> up. Since we only try to cancel the work in ndo_stop(), this may cause
> the refill work still work after removing the device. Fix this by only
> schedule the work when device is up.
>
> The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2.
> (virtio-net: fix the race between channels setting and refill)
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks Jason.
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: mst, netdev, linux-kernel, virtualization
In-Reply-To: <1381807139-3450-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:58 +0800
> We're trying to re-configure the affinity unconditionally in cpu hotplug
> callback. This may lead the issue during resuming from s3/s4 since
>
> - virt queues haven't been allocated at that time.
> - it's unnecessary since thaw method will re-configure the affinity.
>
> Fix this issue by checking the config_enable and do nothing is we're not ready.
>
> The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [patch] yam: remove a no-op in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014123726.GA17034@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:46:15 +0300
> We overwrite the ->bitrate with the user supplied information on the
> next line.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [patch] yam: integer underflow in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014121931.GI6247@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:28:38 +0300
> We cap bitrate at YAM_MAXBITRATE in yam_ioctl(), but it could also be
> negative. I don't know the impact of using a negative bitrate but let's
> prevent it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Julian Anastasov @ 2013-10-17 19:52 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev
In-Reply-To: <1382028894-14236-1-git-send-email-kristian.evensen@gmail.com>
Hello,
On Thu, 17 Oct 2013, Kristian Evensen wrote:
> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> When a link is set as down using for example "ip link set dev X down", routes
> are deleted, but RTM_DELROUTE messages are not sent to RTNLGRP_IPV4_ROUTE. This
> patch makes trie_flush_list() send a RTM_DELROUTE for each route that is
> removed, and makes rtnelink route deletion behavior consistent across commands.
> The parameter lists for trie_flush_list() and trie_flush_leaf() are expanded to
> include required information otherwise unavailable in trie_flush_list().
>
> One use case that is simplified by this patch is IPv4 WAN connection monitoring.
> Instead of listening for and handling both RTM_*ROUTE and RTM_*LINK-messages, it
> is sufficient to handle RTM_*ROUTE.
IIRC, such notifications were not implemented
to avoid storms to routing daemons. Not sure if this is
still true.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] net/ethernet: cpsw: Bugfix interrupts before enabling napi
From: David Miller @ 2013-10-17 19:48 UTC (permalink / raw)
To: mpa; +Cc: florian, mugunthanvnm, peter, linux-arm-kernel, netdev, kernel
In-Reply-To: <1381691821-25498-1-git-send-email-mpa@pengutronix.de>
From: Markus Pargmann <mpa@pengutronix.de>
Date: Sun, 13 Oct 2013 21:17:01 +0200
> If interrupts happen before napi_enable was called, the driver will not
> work as expected. Network transmissions are impossible in this state.
> This bug can be reproduced easily by restarting the network interface in
> a loop. After some time any network transmissions on the network
> interface will fail.
>
> This patch fixes the bug by enabling napi before enabling the network
> interface interrupts.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: David Miller @ 2013-10-17 19:47 UTC (permalink / raw)
To: paul; +Cc: seif, netdev, thomas.petazzoni, dima
In-Reply-To: <3511324.zOrNRFllMJ@sifl>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 14 Oct 2013 11:12:47 -0400
> On Saturday, October 12, 2013 10:21:50 PM Seif Mazareeb wrote:
>> When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could
>> loop forever in the main loop if opt[opt_iter +1] == 0, this will causing a
>> kernel crash in an SMP system, since the CPU executing this function will
>> stall /not respond to IPIs.
>>
>> This problem can be reproduced by running the IP Stack Integrity Checker
>> (http://isic.sourceforge.net) using the following command on a Linux machine
>> connected to DUT:
>>
>> "icmpsic -s rand -d <DUT IP address> -r 123456"
>> wait (1-2 min)
>>
>> Signed-off-by: Seif Mazareeb <seif@marvell.com>
>
> Thanks for sticking with this.
>
> Acked-by: Paul Moore <paul@paul-moore.com>
This patch, like all the others Seif submitted, has been corrupted by
his email client and is this unusable.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: refactor sk_page_frag_refill()
From: David Miller @ 2013-10-17 19:46 UTC (permalink / raw)
To: eric.dumazet
Cc: mwdalton, dborkman, netdev, ffusco, ycheng, ncardwell,
digitaleric
In-Reply-To: <1381639591.3392.31.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 12 Oct 2013 21:46:31 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While working on virtio_net new allocation strategy to increase
> payload/truesize ratio, we found that refactoring sk_page_frag_refill()
> was needed.
>
> This patch splits sk_page_frag_refill() into two parts, adding
> page_frag_refill() which can be used without a socket.
>
> While we are at it, add a minimum frag size of 32 for
> sk_page_frag_refill()
>
> Michael will either use netdev_alloc_frag() from softirq context,
> or page_frag_refill() from process context in refill_work() (GFP_KERNEL
> allocations)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Please rename this to something like "skb_page_frag_refill" so that it
is clear that this is a networking interface.
Thanks Eric.
^ permalink raw reply
* Re: [PATCH] bnx2x: record rx queue for LRO packets
From: David Miller @ 2013-10-17 19:43 UTC (permalink / raw)
To: dmitry; +Cc: eric.dumazet, netdev, eilong, willemb
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F20DD4605@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Sun, 13 Oct 2013 06:23:31 +0000
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Eric Dumazet
>> Sent: Sunday, October 13, 2013 12:09 AM
>> To: David Miller
>> Cc: netdev; Eilon Greenstein; Willem de Bruijn
>> Subject: [PATCH] bnx2x: record rx queue for LRO packets
>>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> RPS support is kind of broken on bnx2x, because only non LRO packets get
>> proper rx queue information. This triggers reorders, as it seems bnx2x like to
>> generate a non LRO packet for segment including TCP PUSH flag : (this might
>> be pure coincidence, but all the reorders I've seen involve segments with a
>> PUSH)
>>
>> 11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985797>
>> 11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>>
>> We must call skb_record_rx_queue() to properly give to RPS (and more
>> generally for TX queue selection on forward path) the receive queue
>> information.
>>
>> Similar fix is needed for skb_mark_napi_id(), but will be handled in a
>> separate patch to ease stable backports.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
...
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] usbnet: fix error return code in usbnet_probe()
From: David Miller @ 2013-10-17 19:40 UTC (permalink / raw)
To: weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w
Cc: oneukum-l3A5Bk7waGM, yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAPgLHd9jQfT2Kzi5o+3KPy0hFrkHL135K2aYp7OXcbLX4Cmkcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Wei Yongjun <weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sat, 12 Oct 2013 14:24:08 +0800
> From: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
>
> Fix to return -ENOMEM in the padding pkt alloc fail error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Applied, thanks Wei.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH v2] Stmmac: fix a bug when clk_csr is euqal to 0x0
From: David Miller @ 2013-10-17 19:39 UTC (permalink / raw)
To: mcuos.com; +Cc: netdev, peppe.cavallaro
In-Reply-To: <CAKT61h9Cv=g5stPBnp25XiUyfPy_NxBKxtAABUHm+GajCHMGWA@mail.gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Sat, 12 Oct 2013 10:04:20 +0800
> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
> the MDC clock. So this patch is to add other judge condition.
>
> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
There are still many problems with this patch.
Do not capitalize "Stmmac" in the subject prefix, use plain "stmmac: "
There is a typo in "equal" in the subject line.
> @@ -148,6 +149,8 @@ Where:
> GMAC also enables the 4xPBL by default.
> o fixed_burst/mixed_burst/burst_len
> o clk_csr: fixed CSR Clock range selection.
> + o dynamic_mdc_clk_en: If it is set to >=1 MDC clk will be selected
> dynamically,
> + or else you must set a fixed CSR Clock range to clk_src.
> o has_gmac: uses the GMAC core.
> o enh_desc: if sets the MAC will use the enhanced descriptor structure.
> o tx_coe: core is able to perform the tx csum in HW.
The patch has been corrupted by your email client.
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] xen-netback: IPv6 offload support
From: David Miller @ 2013-10-17 19:36 UTC (permalink / raw)
To: paul.durrant; +Cc: xen-devel, netdev
In-Reply-To: <1381942232-26268-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 16 Oct 2013 17:50:27 +0100
> This patch series adds support for checksum and large packet offloads into
> xen-netback.
> Testing has mainly been done using the Microsoft network hardware
> certification suite running in Server 2008R2 VMs with Citrix PV frontends.
Series applied, thanks.
^ 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