* RE
From: MR.YEUNG LAP MING. @ 2012-06-01 11:34 UTC (permalink / raw)
--
I HAVE AN URGENT PROPOSAL FOR YOU.PLEASE REPLY THROUGH THIS MAIL IF YOU
ARE INTERESTED FOR DETAILS.(mr.yeung.lapming04@msn.com).
^ permalink raw reply
* RE
From: MR.YEUNG LAP MING. @ 2012-06-01 10:21 UTC (permalink / raw)
To: yeung
--
I HAVE AN URGENT PROPOSAL FOR YOU.PLEASE REPLY THROUGH THIS MAIL IF YOU
ARE INTERESTED FOR DETAILS.(mr.yeung.lapming04@msn.com).
^ permalink raw reply
* Re: r8169: IO_PAGE_FAULT & netdev watchdog
From: Francois Romieu @ 2012-06-01 12:59 UTC (permalink / raw)
To: Vincent Pelletier; +Cc: netdev
In-Reply-To: <201205312331.06623.plr.vincent@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]
Vincent Pelletier <plr.vincent@gmail.com> :
[...]
> I'm getting consistently errors when using btlaunchmanycurses (multi-torrent
> downloader) after a few minutes. I usually first notice the network being down
> (no trafic) then find this in syslog (see at bottom).
>
> Then, I "ifdown eth0;rmmod r8169;modprobe r8169" (which implicitely ifup's),
> but network never comes back - at least no trafic can go through - until
> reboot.
Same thing if you reset and remove the pci device through sysfs then ask
the PCI bridge to scan it again ?
> www.kerneloops.org being down (aparently for quite some time...) I though I
> should report here.
>
> I'm quite sure this problem also occured on 3.2, but I don't know the exact
> version I was using at that time. I only have this motherboard since a few
> months, and previous one didn't have an IOMMU - which in my understanding is
> what causes (well, detects actually) this error.
https://bugzilla.kernel.org/show_bug.cgi?id=42899 contains similar if not
identical IOMMU messages (this #bz is messy but it may be of intereset to
add yourself to the Cc: list btw).
AFAIUI the IOMMU complains because the r8169 tried to perform a read access.
The target address matches the start of a descriptor ring one. However it
happens long after the r8169 initialized the chipset and the driver would
work rather poorly if it could not access its descriptor rings. The r8169
bug is real but the IOMMU message seems rather useless if not bogus.
> May 31 22:54:55 x2 kernel: [78579.111904] AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x0019 address=0x0000000000003000 flags=0x0050]
> May 31 22:55:07 x2 kernel: [78590.832047] ------------[ cut here ]------------
> May 31 22:55:07 x2 kernel: [78590.832067] WARNING: at /build/buildd-linux-2.6_3.3.4-1~experimental.1-amd64-_y3OdD/linux-2.6-3.3.4/debian/build/source_amd64_none/net/sched/sch_generic.c:256 dev_watchdog+0xf2/0x151()
> May 31 22:55:07 x2 kernel: [78590.832080] Hardware name: GA-990FXA-UD3
> May 31 22:55:07 x2 kernel: [78590.832087] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
You can apply the attached patch but it may not do much for your problem.
The patch below could make a difference though. Does it ?
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bbacb37..da46588 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3766,6 +3766,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_34:
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
default:
--
Ueimor
[-- Attachment #2: 0001-PATCH-r8169-fix-unsigned-int-wraparound-with-TSO.patch --]
[-- Type: text/plain, Size: 4949 bytes --]
>From 3068d55417db4c8e3414ce840afb932fdf1f0f76 Mon Sep 17 00:00:00 2001
Message-Id: <3068d55417db4c8e3414ce840afb932fdf1f0f76.1338553193.git.romieu@fr.zoreil.com>
From: Julien Ducourthial <jducourt@free.fr>
Date: Fri, 1 Jun 2012 14:17:43 +0200
Subject: [PATCH] [PATCH] r8169: fix unsigned int wraparound with TSO
X-Organisation: Land of Sunshine Inc.
[ Upstream commit 477206a018f902895bfcd069dd820bfe94c187b1 ]
The r8169 may get stuck or show bad behaviour after activating TSO :
the net_device is not stopped when it has no more TX descriptors.
This problem comes from TX_BUFS_AVAIL which may reach -1 when all
transmit descriptors are in use. The patch simply tries to keep positive
values.
Tested with 8111d(onboard) on a D510MO, and with 8111e(onboard) on a
Zotac 890GXITX.
Signed-off-by: Julien Ducourthial <jducourt@free.fr>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/realtek/r8169.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f545093..ce6b44d 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -61,8 +61,12 @@
#define R8169_MSG_DEFAULT \
(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
-#define TX_BUFFS_AVAIL(tp) \
- (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx - 1)
+#define TX_SLOTS_AVAIL(tp) \
+ (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx)
+
+/* A skbuff with nr_frags needs nr_frags+1 entries in the tx queue */
+#define TX_FRAGS_READY_FOR(tp,nr_frags) \
+ (TX_SLOTS_AVAIL(tp) >= (nr_frags + 1))
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
The RTL chips use a 64 element hash table based on the Ethernet CRC. */
@@ -5115,7 +5119,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
u32 opts[2];
int frags;
- if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
+ if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
goto err_stop_0;
}
@@ -5169,7 +5173,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
mmiowb();
- if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) {
+ if (!TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
/* Avoid wrongly optimistic queue wake-up: rtl_tx thread must
* not miss a ring update when it notices a stopped queue.
*/
@@ -5183,7 +5187,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
* can't.
*/
smp_mb();
- if (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)
+ if (TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS))
netif_wake_queue(dev);
}
@@ -5306,7 +5310,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp)
*/
smp_mb();
if (netif_queue_stopped(dev) &&
- (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
+ TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
/*
--
1.7.10.2
---
drivers/net/ethernet/realtek/r8169.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index da46588..59dd29e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -62,8 +62,12 @@
#define R8169_MSG_DEFAULT \
(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
-#define TX_BUFFS_AVAIL(tp) \
- (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx - 1)
+#define TX_SLOTS_AVAIL(tp) \
+ (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx)
+
+/* A skbuff with nr_frags needs nr_frags+1 entries in the tx queue */
+#define TX_FRAGS_READY_FOR(tp,nr_frags) \
+ (TX_SLOTS_AVAIL(tp) >= (nr_frags + 1))
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
The RTL chips use a 64 element hash table based on the Ethernet CRC. */
@@ -5513,7 +5517,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
u32 opts[2];
int frags;
- if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
+ if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
goto err_stop_0;
}
@@ -5561,10 +5565,10 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
RTL_W8(TxPoll, NPQ);
- if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) {
+ if (!TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
netif_stop_queue(dev);
smp_rmb();
- if (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)
+ if (TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS))
netif_wake_queue(dev);
}
@@ -5666,7 +5670,7 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
tp->dirty_tx = dirty_tx;
smp_wmb();
if (netif_queue_stopped(dev) &&
- (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
+ TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
/*
--
1.7.10.2
^ permalink raw reply related
* Re: [PATCH] cipso: handle CIPSO options correctly when NetLabel is disabled
From: Paul Moore @ 2012-06-01 13:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-security-module
In-Reply-To: <20120531.190705.3612500429295140.davem@davemloft.net>
On Thursday, May 31, 2012 07:07:05 PM David Miller wrote:
> From: Paul Moore <pmoore@redhat.com>
> Date: Thu, 31 May 2012 16:09:23 -0400
>
> > When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
> > receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
> > returns non-zero). In most cases this is the correct and desired
> > behavior, however, in the case where we are simply forwarding the
> > traffic, e.g. acting as a network bridge, this becomes a problem.
> >
> > This patch fixes the forwarding problem by providing the basic CIPSO
> > validation code directly in ip_options_compile() without the need for
> > the NetLabel or CIPSO code. The new validation code can not perform
> > any of the CIPSO option label/value verification that
> > cipso_v4_validate() does, but it can verify the basic CIPSO option
> > format.
> >
> > The behavior when NetLabel is enabled is unchanged.
> >
> > Signed-off-by: Paul Moore <pmoore@redhat.com>
>
> I don't like this at all.
>
> The only conclusion I can come to is that cipso_v4_validate() is doing
> the wrong thing when NETLABEL is disabled.
>
> There is never a good reason to crap all over a function with ifdefs.
> This is especially true when it's being done to paper over a function
> with poor semantics.
>
> The whole idea is to abstract and put all of this kind of logic into
> cipso_v4_validate().
I originally had the #ifdef'd code in the non-CONFIG_NETLABEL
cipso_v4_validate() in include/net/cipso_ipv4.h but thought it was too much
code to put there. No worries, I'll just move it back and resubmit.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply
* [PATCH v2] cipso: handle CIPSO options correctly when NetLabel is disabled
From: Paul Moore @ 2012-06-01 15:54 UTC (permalink / raw)
To: netdev; +Cc: linux-security-module
When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
returns non-zero). In most cases this is the correct and desired
behavior, however, in the case where we are simply forwarding the
traffic, e.g. acting as a network bridge, this becomes a problem.
This patch fixes the forwarding problem by providing the basic CIPSO
validation code directly in ip_options_compile() without the need for
the NetLabel or CIPSO code. The new validation code can not perform
any of the CIPSO option label/value verification that
cipso_v4_validate() does, but it can verify the basic CIPSO option
format.
The behavior when NetLabel is enabled is unchanged.
CC: stable@vger.kernel.org
Signed-off-by: Paul Moore <pmoore@redhat.com>
--
ChangeLog
-v2
* Moved the CONFIG_NETLABEL=n code into cipso_ipv4.h
-v1
* Initial version
---
include/net/cipso_ipv4.h | 29 ++++++++++++++++++++++++++++-
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/include/net/cipso_ipv4.h b/include/net/cipso_ipv4.h
index 9808877..a7a683e 100644
--- a/include/net/cipso_ipv4.h
+++ b/include/net/cipso_ipv4.h
@@ -42,6 +42,7 @@
#include <net/netlabel.h>
#include <net/request_sock.h>
#include <linux/atomic.h>
+#include <asm/unaligned.h>
/* known doi values */
#define CIPSO_V4_DOI_UNKNOWN 0x00000000
@@ -285,7 +286,33 @@ static inline int cipso_v4_skbuff_getattr(const struct sk_buff *skb,
static inline int cipso_v4_validate(const struct sk_buff *skb,
unsigned char **option)
{
- return -ENOSYS;
+ unsigned char *opt = *option;
+ unsigned char err_offset = 0;
+ u8 opt_len = opt[1];
+ u8 opt_iter;
+
+ if (opt_len < 8) {
+ err_offset = 1;
+ goto out;
+ }
+
+ if (get_unaligned_be32(&opt[2]) == 0) {
+ err_offset = 2;
+ goto out;
+ }
+
+ for (opt_iter = 6; opt_iter < opt_len;) {
+ if (opt[opt_iter + 1] > (opt_len - opt_iter)) {
+ err_offset = opt_iter + 1;
+ goto out;
+ }
+ opt_iter += opt[opt_iter + 1];
+ }
+
+out:
+ *option = opt + err_offset;
+ return err_offset;
+
}
#endif /* CONFIG_NETLABEL */
^ permalink raw reply related
* Re: [Announce] LARTC wiki available
From: Niccolò Belli @ 2012-06-01 16:42 UTC (permalink / raw)
To: lartc; +Cc: netfilter@vger.kernel.org,
Linux Networking Developer Mailing List
In-Reply-To: <4EFB3B2B.7060200@linuxsystems.it>
Since I keep receiving lots of visits to lartc.linuxsystems.it from
spinics archives & co, I'd like to point out I closed the wiki when the
original domain changed maintainer:
http://www.spinics.net/lists/lartc/msg22400.html
http://lartc.org is alive and kicking and there is no need for another
wiki anymore. I'd like to thank both Bert and Carl-Daniel.
Niccolò
Il 28/12/2011 16:52, Niccolò Belli ha scritto:
> Hi,
> I still didn't find a viable solution for the LARTC wiki, so I decided
> to start hosting it on my own server. Later we can easily switch
> somewhere else if we keep using the same wiki engine (and maybe even
> with another wiki engine).
> I decided to use wikimedia because it's the only one I know of, so if
> someone knows a better alternative please let me know, we are still in
> time for a change.
> Since I never used a wiki seriously I will probably need someone else
> who can help me maintaining it, please let me know if you are
> experienced and willing to help.
>
> Here is the wiki: http://lartc.linuxsystems.it/
> And here is the new mailing list for those who still don't know:
> http://vger.kernel.org/vger-lists.html#lartc
>
> I just copy-pasted the Linux Advanced Routing & Traffic Control HOWTO
> atm, it still needs to be wikified and we still need to choose how to
> organize the contents.
>
> Cheers,
> Niccolò
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-01 17:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: hans.schillstrom, netdev, ncardwell, therbert, brouer
In-Reply-To: <1338526137.2760.1425.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 01 Jun 2012 06:48:57 +0200
> RFC is like 'I throw a patch, I am not even 50% confident of it, please
> comment and fix my bugs'. Most busy people just ignore it.
And I will ignore it too if you put RFC in the subject line :)
^ permalink raw reply
* Re: [PATCH v2] cipso: handle CIPSO options correctly when NetLabel is disabled
From: David Miller @ 2012-06-01 18:18 UTC (permalink / raw)
To: pmoore; +Cc: netdev, linux-security-module
In-Reply-To: <20120601155456.5114.68007.stgit@sifl>
From: Paul Moore <pmoore@redhat.com>
Date: Fri, 01 Jun 2012 11:54:56 -0400
> When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
> receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
> returns non-zero). In most cases this is the correct and desired
> behavior, however, in the case where we are simply forwarding the
> traffic, e.g. acting as a network bridge, this becomes a problem.
>
> This patch fixes the forwarding problem by providing the basic CIPSO
> validation code directly in ip_options_compile() without the need for
> the NetLabel or CIPSO code. The new validation code can not perform
> any of the CIPSO option label/value verification that
> cipso_v4_validate() does, but it can verify the basic CIPSO option
> format.
>
> The behavior when NetLabel is enabled is unchanged.
>
> CC: stable@vger.kernel.org
> Signed-off-by: Paul Moore <pmoore@redhat.com>
>
I like this a lot better, applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH 1/2] 8139cp: set ring address before enabling receiver
From: David Miller @ 2012-06-01 18:23 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst
In-Reply-To: <20120601041939.4311.55827.stgit@dhcp-8-146.nay.redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 01 Jun 2012 12:19:39 +0800
> Currently, we enable the receiver before setting the ring address which could
> lead the card DMA into unexpected areas. Solving this by set the ring address
> before enabling the receiver.
>
> btw. I find and test this in qemu as I didn't have a 8139cp card in hand. please
> review it carefully.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
I hate bugs like this, the other common issue is enabling interrupts
before the chip is fully programmed.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] 8139cp/8139too: terminate the eeprom access with the right opmode
From: David Miller @ 2012-06-01 18:23 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst
In-Reply-To: <20120601041948.4311.42372.stgit@dhcp-8-146.nay.redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 01 Jun 2012 12:19:48 +0800
> Currently, we terminate the eeprom access through clearing the CS by:
>
> RTL_W8 (Cfg9346, ~EE_CS); or writeb (~EE_CS, ee_addr);
>
> This would left the eeprom into "Config. Register Write Enable:"
> state which is not expcted as the highest two bits were set to
> 0x11 ( expected is the "Normal" mode (0x00)). Solving this by write
> 0x0 instead of ~EE_CS when terminating the eeprom access.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] tcp: reflect SYN queue_mapping into SYNACK packets
From: David Miller @ 2012-06-01 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: hans.schillstrom, netdev, ncardwell, brouer, therbert
In-Reply-To: <1338551270.2760.1505.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 01 Jun 2012 13:47:50 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> While testing how linux behaves on SYNFLOOD attack on multiqueue device
> (ixgbe), I found that SYNACK messages were dropped at Qdisc level
> because we send them all on a single queue.
>
> Obvious choice is to reflect incoming SYN packet @queue_mapping to
> SYNACK packet.
>
> Under stress, my machine could only send 25.000 SYNACK per second (for
> 200.000 incoming SYN per second). NIC : ixgbe with 16 rx/tx queues.
>
> After patch, not a single SYNACK is dropped.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: do not create inetpeer on SYNACK message
From: David Miller @ 2012-06-01 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: hans.schillstrom, netdev, brouer, ncardwell, therbert
In-Reply-To: <1338534026.2760.1451.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 01 Jun 2012 09:00:26 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Another problem on SYNFLOOD/DDOS attack is the inetpeer cache getting
> larger and larger, using lots of memory and cpu time.
>
> tcp_v4_send_synack()
> ->inet_csk_route_req()
> ->ip_route_output_flow()
> ->rt_set_nexthop()
> ->rt_init_metrics()
> ->inet_getpeer( create = true)
>
> This is a side effect of commit a4daad6b09230 (net: Pre-COW metrics for
> TCP) added in 2.6.39
>
> Possible solution :
>
> Instruct inet_csk_route_req() to remove FLOWI_FLAG_PRECOW_METRICS
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
This is definitely the right thing to do.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] r8169: call netif_napi_del at errpaths and at driver unload
From: David Miller @ 2012-06-01 18:25 UTC (permalink / raw)
To: devendra.aaru; +Cc: romieu, netdev, linux-kernel
In-Reply-To: <1338465080-22720-1-git-send-email-devendra.aaru@gmail.com>
From: Devendra Naga <devendra.aaru@gmail.com>
Date: Thu, 31 May 2012 17:21:20 +0530
> when register_netdev fails, the init'ed NAPIs by netif_napi_add must be
> deleted with netif_napi_del, and also when driver unloads, it should
> delete the NAPI before unregistering netdevice using unregister_netdev.
>
> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Francois, I'm assuming you will merge this to me after you've
done some testing.
^ permalink raw reply
* [PATCH] net: add device tree support for davinci mdio
From: s-paulraj-l0cyMroinI0 @ 2012-06-01 18:38 UTC (permalink / raw)
To: grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
From: Sandeep Paulraj <s-paulraj-l0cyMroinI0@public.gmane.org>
This patch adds device tree support in the DaVinci MDIO driver.
The driver is currently being used in DaVinci and OMAP based SOCs; not all of
which have device tree support.
The davinci mdio driver has a way to set the bus frequency
using platform data. There is however no way to pass this information
from device tree.
This patch first looks for a device tree node; if it finds
a node then it looks for the bus frequency from the device tree
bindings. Else it tries to obtain this from platform data.
The new bindings are also explained in the the Documentation for
davini_mdio
Signed-off-by: Sandeep Paulraj <s-paulraj-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/net/davinci_mdio.txt | 16 ++++++++++++++++
drivers/net/ethernet/ti/davinci_mdio.c | 19 ++++++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/davinci_mdio.txt
diff --git a/Documentation/devicetree/bindings/net/davinci_mdio.txt b/Documentation/devicetree/bindings/net/davinci_mdio.txt
new file mode 100644
index 0000000..545e216
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davinci_mdio.txt
@@ -0,0 +1,16 @@
+MDIO on DaVinci SOCs
+
+Currently defined compatibles:
+- ti,davinci-mdio
+
+Required properties:
+- bus-frequency: The operating frequency of the mdio bus
+
+Example:
+
+mdio: mdio@2090300 {
+ compatible = "ti,davinci-mdio";
+ reg = <0x2090300 0x100>;
+ bus-frequency = <50000000>;
+ };
+
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index af8b8fc..efa13c5 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -34,6 +34,7 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
+#include <linux/of.h>
#include <linux/davinci_emac.h>
/*
@@ -286,11 +287,13 @@ static int davinci_mdio_write(struct mii_bus *bus, int phy_id,
static int __devinit davinci_mdio_probe(struct platform_device *pdev)
{
struct mdio_platform_data *pdata = pdev->dev.platform_data;
+ struct device_node *node = pdev->dev.of_node;
struct device *dev = &pdev->dev;
struct davinci_mdio_data *data;
struct resource *res;
struct phy_device *phy;
int ret, addr;
+ u32 bus_freq;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
@@ -298,7 +301,15 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
return -ENOMEM;
}
- data->pdata = pdata ? (*pdata) : default_pdata;
+ if (node) {
+ ret = of_property_read_u32(node, "bus-frequency", &bus_freq);
+ if (ret < 0) {
+ dev_info(&pdev->dev, "Using default bus frequency\n");
+ bus_freq = 50000000;
+ }
+ data->pdata.bus_freq = bus_freq;
+ } else
+ data->pdata = pdata ? (*pdata) : default_pdata;
data->bus = mdiobus_alloc();
if (!data->bus) {
@@ -450,11 +461,17 @@ static const struct dev_pm_ops davinci_mdio_pm_ops = {
.resume = davinci_mdio_resume,
};
+static struct of_device_id __devinitdata of_match[] = {
+ { .compatible = "ti,davinci-mdio", },
+ {},
+};
+
static struct platform_driver davinci_mdio_driver = {
.driver = {
.name = "davinci_mdio",
.owner = THIS_MODULE,
.pm = &davinci_mdio_pm_ops,
+ .of_match_table = of_match,
},
.probe = davinci_mdio_probe,
.remove = __devexit_p(davinci_mdio_remove),
--
1.7.9.5
^ permalink raw reply related
* Re: r8169: IO_PAGE_FAULT & netdev watchdog
From: Vincent Pelletier @ 2012-06-01 19:20 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20120601125949.GA11973@electric-eye.fr.zoreil.com>
Thanks for the quick reply.
Le vendredi 01 juin 2012 14:59:49, vous avez écrit :
> Same thing if you reset and remove the pci device through sysfs then ask
> the PCI bridge to scan it again ?
I didn't try it before - but I should have, I know this.
rmmod; reset; modprobe -> doesn't work
rmmod; reset; remove; rescan -> doesn't work either (?!)
> https://bugzilla.kernel.org/show_bug.cgi?id=42899 contains similar if not
> identical IOMMU messages (this #bz is messy but it may be of intereset to
> add yourself to the Cc: list btw).
I found it a bit after my post (while watching the archives, in case someone
replied without CC :) ). I posted on that bug as I couldn't find a way to just
add me to bug CC.
> The r8169 bug is real but the IOMMU message seems rather useless if not
> bogus.
Just being curious, feel free to skip over my questions:
If it's bogus, could it be a mis-interpretation of its state when the error
occurs (I don't know how CPU knows a fault happened, I guess some IRQ + some
register contain error status, address of error, some process/context
identifier) ? Or hardware bug ? Or MMU misconfiguration for some reason ?
If it's not bogus, would it be the sign of firmware bug (accessing some
unpredictable memory upon certain conditions) ?
> You can apply the attached patch but it may not do much for your problem.
> The patch below could make a difference though. Does it ?
I'll try either and both. Given the poor result I got from
reset/remove/rescan, I guess I should reboot between attempts, right ?
Should I prevent original module auto-loading at boot ? Maybe more than just
r8169 ?
Regards,
--
Vincent Pelletier
^ permalink raw reply
* Re: [Announce] LARTC wiki available
From: Julien Vehent @ 2012-06-01 19:12 UTC (permalink / raw)
To: Niccolò Belli
Cc: lartc, netfilter, Linux Networking Developer Mailing List
In-Reply-To: <4FC8F0E4.6060102@linuxsystems.it>
On 2012-06-01 12:42, Niccolò Belli wrote:
> http://lartc.org is alive and kicking and there is no need for
> another
> wiki anymore. I'd like to thank both Bert and Carl-Daniel.
>
> Niccolò
>
Very cool !
I'll try to find some time and move over some of the content I have here:
http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking:traffic_control
--
Julien Vehent - http://1nw.eu/!j
^ permalink raw reply
* Re: [PATCH] r8169: call netif_napi_del at errpaths and at driver unload
From: Francois Romieu @ 2012-06-01 19:29 UTC (permalink / raw)
To: David Miller; +Cc: devendra.aaru, netdev, linux-kernel
In-Reply-To: <20120601.142531.544977894901194434.davem@davemloft.net>
David Miller <davem@davemloft.net> :
[...]
> Francois, I'm assuming you will merge this to me after you've
> done some testing.
You can apply it directly.
I have done several loops both with a forced error patch and the normal
removal of the module without problem. No trivial crash. Four 816x network
adapters. Reference one still comes up.
--
Ueimor
^ permalink raw reply
* RE: [BUG/PATCH] ppp_mppe discards 50% of packets from some servers
From: Phil Hord (hordp) @ 2012-06-01 20:09 UTC (permalink / raw)
To: netdev
In-Reply-To: <4FA45809.2020003@cisco.com>
Having received no replies on this issue, should I assume this is the
wrong place to report it, that I reported it in the wrong format, that
the patch is too hacky for consideration, or no one has time to care
(yet)?
Phil
Please pardon my top-posting... This MUA sucks.
-----Original Message-----
From: Phil Hord (hordp)
Sent: Friday, May 04, 2012 6:28 PM
To: netdev@vger.kernel.org
Subject: [BUG/PATCH] ppp_mppe discards 50% of packets from some servers
[BUG] ppp_mppe discards 50% of packets from some servers
[2.] Full description of the problem/report:
When I connect to a server using MPPE, I receive about every other
packet with the FLUSHED bit turned off. These packets are dropped by
ppp_mppe.c just like the SPEC says they should be. I am not able to
maintain tcp connections through the VPN with these packets being
discarded.
I found a patch discussed here:
http://ubuntuforums.org/showthread.php?t=1095189
^ permalink raw reply
* Re: r8169: IO_PAGE_FAULT & netdev watchdog
From: Francois Romieu @ 2012-06-01 20:13 UTC (permalink / raw)
To: Vincent Pelletier; +Cc: netdev
In-Reply-To: <201206012120.43235.plr.vincent@gmail.com>
Vincent Pelletier <plr.vincent@gmail.com> :
[...]
> If it's bogus, could it be a mis-interpretation of its state when the error
> occurs (I don't know how CPU knows a fault happened, I guess some IRQ + some
> register contain error status, address of error, some process/context
> identifier) ?
See "AMD I/O Virtualization Technology (IOMMU) Specification".
> Or hardware bug ? Or MMU misconfiguration for some reason ?
I don't have time to poke deeply enough into the iommu code.
[...]
> If it's not bogus, would it be the sign of firmware bug (accessing some
> unpredictable memory upon certain conditions) ?
That's what I thought first. Or I should have added something to the r8169
driver. However it's quite reproducible, the failing address is one of the
mapped Rx or Tx descriptor ring address - don't remember which one, see
the PR at korg - and it does not fit the timing pattern.
[...]
> I'll try either and both. Given the poor result I got from
> reset/remove/rescan, I guess I should reboot between attempts, right ?
Yes. The inlined patch could help avoiding the problem but it is not
supposed to help a failed network adapter recovering.
> Should I prevent original module auto-loading at boot ? Maybe more than just
> r8169 ?
It should not be required. YMMV.
--
Ueimor
^ permalink raw reply
* [PATCH] mcs7830: Implement link state detection
From: Ondrej Zary @ 2012-06-01 20:29 UTC (permalink / raw)
To: Andreas Mohr; +Cc: netdev, Kernel development list
Add .status callback that detects link state changes.
Tested with MCS7832CV-AA chip (9710:7830, identified as rev.C by the driver).
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=28532
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -629,11 +629,31 @@ static int mcs7830_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
return skb->len > 0;
}
+static void mcs7830_status(struct usbnet *dev, struct urb *urb)
+{
+ u8 *buf = urb->transfer_buffer;
+ bool link;
+
+ if (urb->actual_length < 16)
+ return;
+
+ link = !(buf[1] & 0x20);
+ if (netif_carrier_ok(dev->net) != link) {
+ if (link) {
+ netif_carrier_on(dev->net);
+ usbnet_defer_kevent(dev, EVENT_LINK_RESET);
+ } else
+ netif_carrier_off(dev->net);
+ netdev_dbg(dev->net, "Link Status is: %d\n", link);
+ }
+}
+
static const struct driver_info moschip_info = {
.description = "MOSCHIP 7830/7832/7730 usb-NET adapter",
.bind = mcs7830_bind,
.rx_fixup = mcs7830_rx_fixup,
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_LINK_INTR,
+ .status = mcs7830_status,
.in = 1,
.out = 2,
};
@@ -642,7 +662,8 @@ static const struct driver_info sitecom_info = {
.description = "Sitecom LN-30 usb-NET adapter",
.bind = mcs7830_bind,
.rx_fixup = mcs7830_rx_fixup,
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_LINK_INTR,
+ .status = mcs7830_status,
.in = 1,
.out = 2,
};
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 1/2] e1000e: Disable ASPM L1 on 82574
From: Chris Boot @ 2012-06-01 21:17 UTC (permalink / raw)
To: Chris Boot; +Cc: e1000-devel, netdev, linux-kernel, stable, nix
In-Reply-To: <1335216578-21542-2-git-send-email-bootc@bootc.net>
On 23/04/2012 22:29, Chris Boot wrote:
> ASPM on the 82574 causes trouble. Currently the driver disables L0s for
> this NIC but only disables L1 if the MTU is >1500. This patch simply
> causes L1 to be disabled regardless of the MTU setting.
>
> Signed-off-by: Chris Boot <bootc@bootc.net>
> Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
> Cc: Nix <nix@esperi.org.uk>
> Link: https://lkml.org/lkml/2012/3/19/362
> ---
> drivers/net/ethernet/intel/e1000e/82571.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/82571.c b/drivers/net/ethernet/intel/e1000e/82571.c
> index b3fdc69..c6d95f2 100644
> --- a/drivers/net/ethernet/intel/e1000e/82571.c
> +++ b/drivers/net/ethernet/intel/e1000e/82571.c
> @@ -2061,8 +2061,9 @@ const struct e1000_info e1000_82574_info = {
> | FLAG_HAS_SMART_POWER_DOWN
> | FLAG_HAS_AMT
> | FLAG_HAS_CTRLEXT_ON_LOAD,
> - .flags2 = FLAG2_CHECK_PHY_HANG
> + .flags2 = FLAG2_CHECK_PHY_HANG
> | FLAG2_DISABLE_ASPM_L0S
> + | FLAG2_DISABLE_ASPM_L1
> | FLAG2_NO_DISABLE_RX,
> .pba = 32,
> .max_hw_frame_size = DEFAULT_JUMBO,
Now that this patch is in master (d4a4206e) and has presumably been
widely tested, what's the possibility of it making it into stable? I
really should have included a CC to stable when I sent it...
This patch should probably also be accompanied with 59aed952 (e1000e:
Remove special case for 82573/82574 ASPM L1 disablement) on top, to
remove a special case that's no longer required once this is applied.
Thanks,
Chris
--
Chris Boot
bootc@bootc.net
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* RE: [PATCH] tcp: do not create inetpeer on SYNACK message
From: Hans Schillström @ 2012-06-01 21:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Jesper Dangaard Brouer, David Miller, Neal Cardwell,
Tom Herbert
In-Reply-To: <1338534026.2760.1451.camel@edumazet-glaptop>
Hi Eric
>Another problem on SYNFLOOD/DDOS attack is the inetpeer cache getting
>larger and larger, using lots of memory and cpu time.
>
>>tcp_v4_send_synack()
>->inet_csk_route_req()
> ->ip_route_output_flow()
> ->rt_set_nexthop()
> ->rt_init_metrics()
> ->inet_getpeer( create = true)
>
>This is a side effect of commit a4daad6b09230 (net: Pre-COW metrics for
>TCP) added in 2.6.39
>
>Possible solution :
>
>Instruct inet_csk_route_req() to remove FLOWI_FLAG_PRECOW_METRICS
>
It think we are on the right way now,
Some results from one of our testers:
before applying "reflect SYN queue_mapping into SYNACK"
"(The latest one from Eric is not included. I am building with
that one right now.)
Results were that with the same number of SYN/s, load went down
30% on each of the three Cpus that were handling the SYNs.
Great !!!"
I'm looking forward to see the results of the latests patch.
Then I think conntrack need a little shape up, like a "mini-conntrack"
it is way to expensive to alloc a full "coontack for every SYN.
I have a bunch of patches and ideas for that...
Thanks Eric for a great job
/Hans
^ permalink raw reply
* Re: [PATCH] r8169: call netif_napi_del at errpaths and at driver unload
From: David Miller @ 2012-06-01 22:44 UTC (permalink / raw)
To: romieu; +Cc: devendra.aaru, netdev, linux-kernel
In-Reply-To: <20120601192944.GA21881@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 1 Jun 2012 21:29:44 +0200
> David Miller <davem@davemloft.net> :
> [...]
>> Francois, I'm assuming you will merge this to me after you've
>> done some testing.
>
> You can apply it directly.
>
> I have done several loops both with a forced error patch and the normal
> removal of the module without problem. No trivial crash. Four 816x network
> adapters. Reference one still comes up.
Ok, applied, thanks.
^ permalink raw reply
* ṕ ȫ ḳ ệ ŕ ȫ π l i π ệ
From: Vicenta Hemm @ 2012-06-01 22:51 UTC (permalink / raw)
To: netdev@cybertec.co.in
He finished to one of the three noteworthy rings adorning concert Parfenovitchs several times.
ǖƙahttp://ἡḳú.twonysix.com??ȱȟ
The eraseed gaiety, deity had prepared till that novelty as a young fiance, an furious and immensely despondent cheek to his happiness, had devilishly been splited by her modesty, jaded to an awe-inspiring cause, and on the incidence that midday had shown mesh, not imperfect, not insatiable, not fertile, but fork and indistinct and narrow.
^ permalink raw reply
* Re: [PATCH 3/3] Revert Backoff [v3]: Calculate TCP's connection close threshold as a time value.
From: Jerry Chu @ 2012-06-01 22:58 UTC (permalink / raw)
To: Damian Lukowski; +Cc: Netdev, David Miller, Ilpo Järvinen
In-Reply-To: <CAFbMe2Mu46N8kRrYkGzYRLuntEd2J9aO_d0Jw_y0gsQA4q-qHw@mail.gmail.com>
> From: Damian Lukowski <damian@tvk.rwth-aachen.de>
> Date: Wed, Aug 26, 2009 at 3:16 AM
> Subject: [PATCH 3/3] Revert Backoff [v3]: Calculate TCP's connection close
> threshold as a time value.
> To: Netdev <netdev@vger.kernel.org>
>
>
> RFC 1122 specifies two threshold values R1 and R2 for connection timeouts,
> which may represent a number of allowed retransmissions or a timeout value.
> Currently linux uses sysctl_tcp_retries{1,2} to specify the thresholds
> in number of allowed retransmissions.
>
> For any desired threshold R2 (by means of time) one can specify tcp_retries2
> (by means of number of retransmissions) such that TCP will not time out
> earlier than R2. This is the case, because the RTO schedule follows a fixed
> pattern, namely exponential backoff.
>
> However, the RTO behaviour is not predictable any more if RTO backoffs can
> be
> reverted, as it is the case in the draft
> "Make TCP more Robust to Long Connectivity Disruptions"
> (http://tools.ietf.org/html/draft-zimmermann-tcp-lcd).
>
> In the worst case TCP would time out a connection after 3.2 seconds, if the
> initial RTO equaled MIN_RTO and each backoff has been reverted.
>
> This patch introduces a function retransmits_timed_out(N),
> which calculates the timeout of a TCP connection, assuming an initial
> RTO of MIN_RTO and N unsuccessful, exponentially backed-off retransmissions.
>
> Whenever timeout decisions are made by comparing the retransmission counter
> to some value N, this function can be used, instead.
>
> The meaning of tcp_retries2 will be changed, as many more RTO
> retransmissions
> can occur than the value indicates. However, it yields a timeout which is
> similar to the one of an unpatched, exponentially backing off TCP in the
> same
> scenario. As no application could rely on an RTO greater than MIN_RTO, there
> should be no risk of a regression.
This looks like a typical "fix one problem, introducing a few more" patch :(.
What do you mean by "no application could rely on an RTO greater than
MIN_RTO..."
above? How can you make the assumption that RTO is not too far off
from TCP_RTO_MIN?
While you tried to address a problem where the retransmission count
was high but the actual
timeout duration was too short, have you considered the other case
around, i.e., the timeout
duration is long but the retransmission count is too short? This is
exactly what's happening
to us with your patch. We've much reduced TCP_RTO_MIN for our internal
traffic, but not
noticing your change has severely shortened the R1 & R2 recommended by
RFC1122 for our
long haul traffic until now. In many cases R1 threshold was met upon
the first retrans timeout.
I think retransmits_timed_out() should check against both time
duration and retrans count
(icsk_retransmits).
Thought?
Jerry
>
> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
> ---
> include/net/tcp.h | 18 ++++++++++++++++++
> net/ipv4/tcp_timer.c | 11 +++++++----
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c35b329..17d1a88 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1247,6 +1247,24 @@ static inline struct sk_buff
> *tcp_write_queue_prev(struct sock *sk, struct sk_bu
> #define tcp_for_write_queue_from_safe(skb, tmp, sk) \
> skb_queue_walk_from_safe(&(sk)->sk_write_queue, skb, tmp)
>
> +static inline bool retransmits_timed_out(const struct sock *sk,
> + unsigned int boundary)
> +{
> + int limit, K;
> + if (!inet_csk(sk)->icsk_retransmits)
> + return false;
> +
> + K = ilog2(TCP_RTO_MAX/TCP_RTO_MIN);
> +
> + if (boundary <= K)
> + limit = ((2 << boundary) - 1) * TCP_RTO_MIN;
> + else
> + limit = ((2 << K) - 1) * TCP_RTO_MIN +
> + (boundary - K) * TCP_RTO_MAX;
> +
> + return (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >= limit;
> +}
> +
> static inline struct sk_buff *tcp_send_head(struct sock *sk)
> {
> return sk->sk_send_head;
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index a3ba494..2972d7b 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -137,13 +137,14 @@ static int tcp_write_timeout(struct sock *sk)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
> int retry_until;
> + bool do_reset;
>
> if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
> if (icsk->icsk_retransmits)
> dst_negative_advice(&sk->sk_dst_cache);
> retry_until = icsk->icsk_syn_retries ? :
> sysctl_tcp_syn_retries;
> } else {
> - if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
> + if (retransmits_timed_out(sk, sysctl_tcp_retries1)) {
> /* Black hole detection */
> tcp_mtu_probing(icsk, sk);
>
> @@ -155,13 +156,15 @@ static int tcp_write_timeout(struct sock *sk)
> const int alive = (icsk->icsk_rto < TCP_RTO_MAX);
>
> retry_until = tcp_orphan_retries(sk, alive);
> + do_reset = alive ||
> + !retransmits_timed_out(sk, retry_until);
>
> - if (tcp_out_of_resources(sk, alive ||
> icsk->icsk_retransmits < retry_until))
> + if (tcp_out_of_resources(sk, do_reset))
> return 1;
> }
> }
>
> - if (icsk->icsk_retransmits >= retry_until) {
> + if (retransmits_timed_out(sk, retry_until)) {
> /* Has it gone just too far? */
> tcp_write_err(sk);
> return 1;
> @@ -385,7 +388,7 @@ void tcp_retransmit_timer(struct sock *sk)
> out_reset_timer:
> icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto,
> TCP_RTO_MAX);
> - if (icsk->icsk_retransmits > sysctl_tcp_retries1)
> + if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1))
> __sk_dst_reset(sk);
>
> out:;
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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