<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.network">
    <title>gmane.linux.network</title>
    <link>http://blog.gmane.org/gmane.linux.network</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273438"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273437"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273432"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273429"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273426"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273424"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273422"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273411"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273393"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273391"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273390"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273387"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273376"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273374"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273368"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273347"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273343"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273342"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273340"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.network/273338"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273438">
    <title>nl80211 NULL pointer dereference</title>
    <link>http://comments.gmane.org/gmane.linux.network/273438</link>
    <description>&lt;pre&gt;Hmm. Maybe this is old, but I don't think I've seen it before (who
knows, maybe it has killed the machine before, I had a hard hang the
other day).

It's a NULL pointer dereference in nl80211_set_reg() on my Pixel. The
machine kind of stayed up afterwards, although with no working
wireless, and it would not shut down cleanly presumably due to locks
held etc.

Any ideas? I'm including the few wireless-related messages that
happened justr before the oops. Being a pixel, this is with the ath9k
driver.

                     Linus

---
  wlp1s0: authenticate with 00:c0:23:ba:27:40
  wlp1s0: send auth to 00:c0:23:ba:27:40 (try 1/3)
  wlp1s0: authenticated
  ath9k 0000:01:00.0 wlp1s0: disabling HT as WMM/QoS is not supported by the AP
  ath9k 0000:01:00.0 wlp1s0: disabling VHT as WMM/QoS is not supported by the AP
  wlp1s0: associate with 00:c0:23:ba:27:40 (try 1/3)
  wlp1s0: RX AssocResp from 00:c0:23:ba:27:40 (capab=0x501 status=0 aid=4)
  wlp1s0: associated
  cfg80211: Calling CRDA for country: US

  BUG: unable&lt;/pre&gt;</description>
    <dc:creator>Linus Torvalds</dc:creator>
    <dc:date>2013-06-19T01:46:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273437">
    <title>Problems in tc-ematch.8</title>
    <link>http://comments.gmane.org/gmane.linux.network/273437</link>
    <description>&lt;pre&gt;This is automatically generated email about markup problems in a man
page for which you appear to be responsible.  If you are not the right
person or list, please tell me so I can correct my database.

See http://catb.org/~esr/doclifter/bugs.html for details on how and
why these patches were generated.  Feel free to email me with any
questions.  Note: These patches do not change the modification date of
any manual page.  You may wish to do that by hand.

I apologize if this message seems spammy or impersonal. The volume of
markup bugs I am tracking is over five hundred - there is no real
alternative to generating bugmail from a database and template.

--
                             Eric S. Raymond
Problems with tc-ematch.8:

Use of low-level troff hackery to set special indents or breaks can't
be translated. The page will have rendering faults in HTML, and
probably also under third-party man page browsers such as Xman,
Rosetta, and the KDE help browser.  This patch eliminates .br, .ta, .ti,
.ce, .in, and \h&lt;/pre&gt;</description>
    <dc:creator>esr&lt; at &gt;thyrsus.com</dc:creator>
    <dc:date>2013-06-19T01:02:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273432">
    <title>[PATCH v2 net-next 0/2] bnx2x: add support for low latency rx</title>
    <link>http://comments.gmane.org/gmane.linux.network/273432</link>
    <description>&lt;pre&gt;Hi Dave

This series adds to bnx2x driver capabilities for low latency rx.
It bases on ixgbe driver code and tested with TCP_RR/UDP_RR.
The results show about 50% boost in both scenarious. With second patch
we have additional 5%.

Please, consider applying it to net-next.

V1-&amp;gt;V2
* change function prototypes from int to bool (from Eric)
* do not allow poll when GRO/LRO enabled

Thanks,
Dmitry


&lt;/pre&gt;</description>
    <dc:creator>Dmitry Kravkov</dc:creator>
    <dc:date>2013-06-18T22:36:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273429">
    <title>[PATCH net] vxlan: fix check for migration of static entry</title>
    <link>http://comments.gmane.org/gmane.linux.network/273429</link>
    <description>&lt;pre&gt;The check introduced by:
commit 26a41ae604381c5cc0caf1c3261ca6b298b5fe69
Author: stephen hemminger &amp;lt;stephen&amp;lt; at &amp;gt;networkplumber.org&amp;gt;
Date:   Mon Jun 17 12:09:58 2013 -0700

    vxlan: only migrate dynamic FDB entries

was not correct because it is checking flag about type of FDB
entry, rather than the state (dynamic versus static). The confusion
arises because vxlan is reusing values from bridge, and bridge is
reusing values from neighbour table, and easy to get lost in translation.

Signed-off-by: Stephen Hemminger &amp;lt;stephen&amp;lt; at &amp;gt;networkplumber.org&amp;gt;
---
 drivers/net/vxlan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index dda997a..57325f3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -579,7 +579,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static bool vxlan_snoop(struct net_device *dev,
 return false;
 
 /* Don't migrate static entries, drop packets */
-if (!(f-&amp;gt;flags &amp;amp; NTF_SELF))
+if (f-&amp;gt;state &amp;amp; NUD_NOARP)
 return true;
 
 if (net_ratelimit())
&lt;/pre&gt;</description>
    <dc:creator>Stephen Hemminger</dc:creator>
    <dc:date>2013-06-18T21:27:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273426">
    <title>Suply Sample</title>
    <link>http://comments.gmane.org/gmane.linux.network/273426</link>
    <description>&lt;pre&gt;

Hello sir/madam how are you doing i hope fine. Sir i contacted you r company so we can go into seriouse business . I will like you to supply the following product in a large quantity to my company i have attach a sample of it kindly view the sample in the attachment and see if you can supply much of it to my compnay. View it and get back to me as soon as possible so i can place and order for it. I look forward to hear from you soon thanks and have a great day .

Kind regars

Donald


&lt;/pre&gt;</description>
    <dc:creator>Donald Ness</dc:creator>
    <dc:date>2013-06-18T18:40:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273424">
    <title>[PATCH V2] rtlwifi: rtl8192cu: Fix duplicate if test</title>
    <link>http://comments.gmane.org/gmane.linux.network/273424</link>
    <description>&lt;pre&gt;A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was found using cppcheck-1.49, and the
proper fix was verified against the pre-mac80211 version of the code.

This patch was originally included as commit 1288aa4, but was accidentally
reverted in a later patch.

Reported-by: David Binderman &amp;lt;dcb314&amp;lt; at &amp;gt;hotmail.com&amp;gt; [original report]
Reported-by: Andrea Morello &amp;lt;andrea.merello&amp;lt; at &amp;gt;gmail.com&amp;gt; [report of accidental reversion]
Signed-off-by: Larry Finger &amp;lt;Larry.Finger&amp;lt; at &amp;gt;lwfinger.net&amp;gt;
Cc: stable &amp;lt;stable&amp;lt; at &amp;gt;vger.kernel.org&amp;gt;  [back to 2.6.39]
---

John,

Although this patch is trivial and could be included in the 3.10 stream,
I think we should not burden DaveM nor Linus with it this late in the 3.10
cycle. Please push it into the 3.11 stream.

Thanks,

Larry
---

V2 - Fix error in stable mailing address
---
 drivers/net/wireless/rtlwifi/rtl8192cu/rf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c b/drivers/ne&lt;/pre&gt;</description>
    <dc:creator>Larry Finger</dc:creator>
    <dc:date>2013-06-18T18:25:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273422">
    <title>[PATCH] rtlwifi: rtl8192cu: Fix duplicate if test</title>
    <link>http://comments.gmane.org/gmane.linux.network/273422</link>
    <description>&lt;pre&gt;A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was found using cppcheck-1.49, and the
proper fix was verified against the pre-mac80211 version of the code.

This patch was originally included as commit 1288aa4, but was accidentally
reverted in a later patch.

Reported-by: David Binderman &amp;lt;dcb314&amp;lt; at &amp;gt;hotmail.com&amp;gt; [original report]
Reported-by: Andrea Morello &amp;lt;andrea.merello&amp;lt; at &amp;gt;gmail.com&amp;gt; [report of accidental reversion]
Signed-off-by: Larry Finger &amp;lt;Larry.Finger&amp;lt; at &amp;gt;lwfinger.net&amp;gt;
Cc: stable &amp;lt;stable&amp;lt; at &amp;gt;kernel.org&amp;gt;  [back to 2.6.39]
---

John,

Although this patch is trivial and could be included in the 3.10 stream,
I think we should not burden DaveM nor Linus with it this late in the 3.10
cycle. Please push it into the 3.11 stream.

Thanks,

Larry
---
 drivers/net/wireless/rtlwifi/rtl8192cu/rf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
index 953f1a0..21&lt;/pre&gt;</description>
    <dc:creator>Larry Finger</dc:creator>
    <dc:date>2013-06-18T18:18:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273411">
    <title>[PATCH net] sfc: Remove write permission from phy_type attribute</title>
    <link>http://comments.gmane.org/gmane.linux.network/273411</link>
    <description>&lt;pre&gt;Driver probe currently results in:

WARNING: at drivers/base/core.c:576 device_create_file+0x57/0x7e()
Attribute phy_type: write permission without 'store'

Signed-off-by: Ben Hutchings &amp;lt;bhutchings&amp;lt; at &amp;gt;solarflare.com&amp;gt;
---
 drivers/net/ethernet/sfc/efx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 39e4cb3..4a14a94 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2139,7 +2139,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; show_phy_type(struct device *dev, struct device_attribute *attr, char *buf)
 struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
 return sprintf(buf, "%d\n", efx-&amp;gt;phy_type);
 }
-static DEVICE_ATTR(phy_type, 0644, show_phy_type, NULL);
+static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
 
 static int efx_register_netdev(struct efx_nic *efx)
 {
&lt;/pre&gt;</description>
    <dc:creator>Ben Hutchings</dc:creator>
    <dc:date>2013-06-18T16:45:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273393">
    <title>[PATCH net-next V1 0/2] Low latency Socket support</title>
    <link>http://comments.gmane.org/gmane.linux.network/273393</link>
    <description>&lt;pre&gt;Hi Dave,

Please pull those 2 patches, which add support in Low Latency Socket (LLS) to
mlx4_en.

Will send performance numbers later on

Thanks,
Amir

Changes from v0:
- Make sure we respect RCU grace period after calling napi_hash_del
- Disable GRO if LL polling is in process
- Allways enable LLS statistics when LLS is in use.
- Move code related to statistics that was mistakenly placed in patch 1/1 into
  patch 2/2
- MLX4_EN_CQ_STATEXXXX =&amp;gt; MLX4_EN_CQ_STATE_XXXX
- Use bool instead of int

Amir Vadai (2):
  net/mlx4_en: Add Low Latency Socket (LLS) support
  net/mlx4_en: Low Latency recv statistics

 drivers/net/ethernet/mellanox/mlx4/en_cq.c      |   3 +
 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c |  20 +++-
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c  |  47 ++++++++-
 drivers/net/ethernet/mellanox/mlx4/en_rx.c      |  15 ++-
 drivers/net/ethernet/mellanox/mlx4/mlx4_en.h    | 127 ++++++++++++++++++++++++
 5 files changed, 207 insertions(+), 5 deletions(-)

&lt;/pre&gt;</description>
    <dc:creator>Amir Vadai</dc:creator>
    <dc:date>2013-06-18T13:18:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273391">
    <title>[PATCH net-next] tcp:typo unset should be unsent</title>
    <link>http://comments.gmane.org/gmane.linux.network/273391</link>
    <description>&lt;pre&gt;Signed-off-by: Weiping Pan &amp;lt;wpan&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 net/ipv4/tcp_output.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 3dd46ea..e2c1333 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -185,7 +185,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static inline void tcp_event_ack_sent(struct sock *sk, unsigned int pkts)
 u32 tcp_default_init_rwnd(u32 mss)
 {
 /* Initial receive window should be twice of TCP_INIT_CWND to
- * enable proper sending of new unset data during fast recovery
+ * enable proper sending of new unsent data during fast recovery
  * (RFC 3517, Section 4, NextSeg() rule (2)). Further place a
  * limit when mss is larger than 1460.
  */
&lt;/pre&gt;</description>
    <dc:creator>Weiping Pan</dc:creator>
    <dc:date>2013-06-18T13:00:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273390">
    <title>redirect host vs ip route cache</title>
    <link>http://comments.gmane.org/gmane.linux.network/273390</link>
    <description>&lt;pre&gt;Hello guys,

the network scheme is the following:

Servers in network 10.0.0.0/24 -&amp;gt; 10.0.0.1 (core) -&amp;gt; 10.0.0.2 (router with 
NAT to 1.2.3.4) -&amp;gt; internet

As you might have guessed I have the problem with "router with NAT".
It is Debian with kernel 3.2.0-0.bpo.4-amd64.

When I try to ping/telnet/etc. I get a problem.

Example:

Server 10.0.0.123 ping 4.2.2.4:

# ping 4.2.2.4
PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data.
From 10.0.0.1: icmp_seq=3 Redirect Host(New nexthop: 10.0.0.2)
From 1.2.3.4 icmp_seq=1 Destination Host Unreachable 

On 10.0.0.2 we can see in ip route cache:

10.0.0.123 from 4.2.2.4 dev eth0  src 1.2.3.4
    cache  ipid 0x3837 rtt 75ms rttvar 60ms cwnd 10 iif eth0.635
4.2.2.4 from 10.0.0.123 tos lowdelay via 10.0.0.2 dev eth0.635  src 10.0.0.2 
    cache &amp;lt;src-direct,redirected&amp;gt;  ipid 0x6955 iif eth0
4.2.2.4 from 10.0.0.123 via 10.0.0.2 dev eth0.635  src 10.0.0.2 
    cache &amp;lt;src-direct&amp;gt;  ipid 0x6955 iif eth0
4.2.2.4 via 10.0.0.2 dev eth0.635  src 1.2.3.4
    cache &amp;lt;redirected&amp;gt;  ipid 0x6955
&lt;/pre&gt;</description>
    <dc:creator>Sergey</dc:creator>
    <dc:date>2013-06-18T12:42:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273387">
    <title>[PATCH net-next] bonding: trivial: make alb use bond_slave_has_mac()</title>
    <link>http://comments.gmane.org/gmane.linux.network/273387</link>
    <description>&lt;pre&gt;Also, cleanup bond_alb_handle_active_change() from 2 identical ifs.

Signed-off-by: Veaceslav Falico &amp;lt;vfalico&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 drivers/net/bonding/bond_alb.c | 53 +++++++++---------------------------------
 1 file changed, 11 insertions(+), 42 deletions(-)

diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 27fe329..4ea8ed1 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1129,6 +1129,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void alb_change_hw_addr_on_detach(struct bonding *bond, struct slave *sla
 {
 int perm_curr_diff;
 int perm_bond_diff;
+struct slave *found_slave;
 
 perm_curr_diff = !ether_addr_equal_64bits(slave-&amp;gt;perm_hwaddr,
   slave-&amp;gt;dev-&amp;gt;dev_addr);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1136,21 +1137,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void alb_change_hw_addr_on_detach(struct bonding *bond, struct slave *sla
   bond-&amp;gt;dev-&amp;gt;dev_addr);
 
 if (perm_curr_diff &amp;amp;&amp;amp; perm_bond_diff) {
-struct slave *tmp_slave;
-int i, found = 0;
-
-bond_for_each_slave(bond, tmp_slave, i) {
-if (ether_addr_equal_64bits&lt;/pre&gt;</description>
    <dc:creator>Veaceslav Falico</dc:creator>
    <dc:date>2013-06-18T11:44:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273376">
    <title>UDP "accept" proposed</title>
    <link>http://comments.gmane.org/gmane.linux.network/273376</link>
    <description>&lt;pre&gt;One of the frustrations of creating UDP servers using BSD sockets is 
that there isn't an easy way for a server to pass off a socket for a 
particular client instance to a handler thread or process.

By contrast, with TCP you can "accept" an incoming connection, and pass 
the socket representing that connection off to any arbitrary handler.

But UDP servers that want to play well with stateful firewalls and NAT 
are forced to aggregate their entire connection pool onto a single 
socket, since BSD sockets don't have the equivalent of an "accept" 
mechanism to provide a connection-specific socket.

This is a disaster from a performance perspective because you can't take 
a UDP server that binds to a single port and efficiently scale it up 
across multiple threads or processors because you must operate off a 
single socket.

So why can't I "accept" a UDP socket?  The conventional response would 
be that UDP is connectionless and that "accept" is meaningless outside 
the context of a connection.  UDP may be conn&lt;/pre&gt;</description>
    <dc:creator>James Yonan</dc:creator>
    <dc:date>2013-06-18T08:48:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273374">
    <title>[net PATCH 1/1] drivers: net: cpsw: fix cpsw clock gating issue across suspend/resume</title>
    <link>http://comments.gmane.org/gmane.linux.network/273374</link>
    <description>&lt;pre&gt;Due to some hardware integration issue, CPSW sliver modules requires a
reset across suspend/resume cycle for a successful clock gating to
CPGMAC (CPSW and Davinci MDIO) in AM335x PG1.0.
This issue is fixed in PG2.x, though to support suspend/resume on PG1.0
this reset is required.

Signed-off-by: Mugunthan V N &amp;lt;mugunthanvnm&amp;lt; at &amp;gt;ti.com&amp;gt;
---
 drivers/net/ethernet/ti/cpsw.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 2fd69db..e66a202 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1976,6 +1976,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int cpsw_suspend(struct device *dev)
 
 if (netif_running(ndev))
 cpsw_ndo_stop(ndev);
+soft_reset("sliver 0", &amp;amp;priv-&amp;gt;slaves[0].sliver-&amp;gt;soft_reset);
+soft_reset("sliver 1", &amp;amp;priv-&amp;gt;slaves[1].sliver-&amp;gt;soft_reset);
 pm_runtime_put_sync(&amp;amp;pdev-&amp;gt;dev);
 
 return 0;
&lt;/pre&gt;</description>
    <dc:creator>Mugunthan V N</dc:creator>
    <dc:date>2013-06-18T09:34:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273368">
    <title>[PATCH net-next 0/5] Further SCTP changes</title>
    <link>http://comments.gmane.org/gmane.linux.network/273368</link>
    <description>&lt;pre&gt;Mostly it's all about getting rid of unnecessary code, and/or making
it more clean and readable.

Code has been tested with lksctp-tools functional test suite and
also my small sctp stress test helper that was used to discover
the recent null-ptr derefs. This test was also sucessfully run against
auth_enabled=0 and auth_enabled=1, where I also previously applied
the following two patches:

  - http://marc.info/?l=linux-crypto-vger&amp;amp;m=137121898331017&amp;amp;w=2
    -&amp;gt; not yet applied, still pending review for crypto tree
  - 1abd165 (net: sctp: fix NULL pointer dereference in socket destruction)
    -&amp;gt; cherry picked from net tree

Daniel Borkmann (5):
  net: sctp: remove TEST_FRAME ifdef
  ktime: add ms_to_ktime() and ktime_add_ms() helpers
  net: sctp: migrate cookie life from timeval to ktime
  net: sctp: decouple cleaning socket data from endpoint
  net: sctp: minor: sctp_seq_dump_local_addrs add missing newline

 include/linux/ktime.h      | 13 +++++++++++++
 include/net/sctp/sctp.h    | 25 ----------------------&lt;/pre&gt;</description>
    <dc:creator>Daniel Borkmann</dc:creator>
    <dc:date>2013-06-18T08:55:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273347">
    <title>[PATCH net-next 0/2] bnx2x: add support for low latency rx</title>
    <link>http://comments.gmane.org/gmane.linux.network/273347</link>
    <description>&lt;pre&gt;Hi Dave

This series adds to bnx2x driver capabilities for low latency rx.
It bases on ixgbe driver code and tested with TCP_RR/UDP_RR.
The results show about 50% boost in both scenarious. With second patch
we have additional 5%.

Please, consider applying it to net-next.

Thanks,
Dmitry


&lt;/pre&gt;</description>
    <dc:creator>Dmitry Kravkov</dc:creator>
    <dc:date>2013-06-18T07:42:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273343">
    <title>[RFC patch RESEND net-next 1/1] tcp: introduce TCP experimental option for SMC-R</title>
    <link>http://comments.gmane.org/gmane.linux.network/273343</link>
    <description>&lt;pre&gt;From: Ursula Braun &amp;lt;ubraun&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

Since I haven't received any comments to my posting from 2013/06/05
I plan to submit my patch for real inclusion into net-next. Any
objections before I start submitting?

RDMA is considered to become an important technology for IBM System z
(which is "s390" in Linux kernel terminology).
We intend to introduce a new socket protocol family providing Shared
Memory Communications over RDMA called SMC-R. The respective IETF draft
can be found at [1]. Its objective is to come up with a low latency, but
also low CPU cost communication vehicle exploiting RDMA technology
transparently while keeping the TCP/IP administration model and allowing
fallback to TCP sockets if necessary. The SMC-R protocol makes use of
the existing TCP 3-way hand shake, the TCP connection and IP topology to
preserve the traditional network administrative model including network
security. The SMC-R protocol also enables redundancy and load balancing
across multiple RDMA-capable devices.

An esse&lt;/pre&gt;</description>
    <dc:creator>Ursula Braun</dc:creator>
    <dc:date>2013-06-18T07:07:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273342">
    <title>[PATCH v2.33] datapath: Add basic MPLS support to kernel</title>
    <link>http://comments.gmane.org/gmane.linux.network/273342</link>
    <description>&lt;pre&gt;Allow datapath to recognize and extract MPLS labels into flow keys
and execute actions which push, pop, and set labels on packets.

Based heavily on work by Leo Alterman, Ravi K, Isaku Yamahata and Joe Stringer.

Cc: Ravi K &amp;lt;rkerur&amp;lt; at &amp;gt;gmail.com&amp;gt;
Cc: Leo Alterman &amp;lt;lalterman&amp;lt; at &amp;gt;nicira.com&amp;gt;
Cc: Isaku Yamahata &amp;lt;yamahata&amp;lt; at &amp;gt;valinux.co.jp&amp;gt;
Cc: Joe Stringer &amp;lt;joe&amp;lt; at &amp;gt;wand.net.nz&amp;gt;
Signed-off-by: Simon Horman &amp;lt;horms&amp;lt; at &amp;gt;verge.net.au&amp;gt;

---

This patch depends on "gre: Restructure tunneling" which it aims
to be compatible with.

This is the remaining patch of the series "MPLS actions and matches".
To aid review it and its dependency are available in git at:

        git://github.com/horms/openvswitch.git devel/mpls-v2.33

v2.33
* Ensure that inner_protocol is always set to to the current
  skb-&amp;gt;protocol value in ovs_execute_actions(). This ensures
  it is set to the correct value in the absence of a push_mpls action.
  Also remove setting of inner_protocol in push_mpls() as
  it duplicates the code now in ovs_execute_actions().
* Call _&lt;/pre&gt;</description>
    <dc:creator>Simon Horman</dc:creator>
    <dc:date>2013-06-18T07:06:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273340">
    <title>[stmmac] On mtu change, Not able to ping Host</title>
    <link>http://comments.gmane.org/gmane.linux.network/273340</link>
    <description>&lt;pre&gt;Hi All,
We are working on ARM based SoC and using STMMAC Ethernet driver.
In our scenario, we are setting MTU size as more than Ethernet frame size.

Scenario:
1) Setting MTU for Host side, Target side(ARM based SoC) as 5000 bytes.
2) pinging host with packet size 3000, it is fail to ping host.
3) ping host with packet size less than 1586, it is able to ping host

Can you please guide me on this issue?

Thank you.
Siva
&lt;/pre&gt;</description>
    <dc:creator>sivareddy kallam</dc:creator>
    <dc:date>2013-06-18T05:57:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273338">
    <title>[PATCH (net.git)] stmmac: fix EEE setup</title>
    <link>http://comments.gmane.org/gmane.linux.network/273338</link>
    <description>&lt;pre&gt;This patch fixes the EEE setup allowing to configure this support
when the link changes.

Signed-off-by: Giuseppe Cavallaro &amp;lt;peppe.cavallaro&amp;lt; at &amp;gt;st.com&amp;gt;
---
 drivers/net/ethernet/stmicro/stmmac/common.h      |    4 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   66 ++++++++++-----------
 2 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 7788fbe..9517697 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -297,8 +297,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct dma_features {
 #define MAC_RNABLE_RX0x00000004/* Receiver Enable */
 
 /* Default LPI timers */
-#define STMMAC_DEFAULT_LIT_LS_TIMER0x3E8
-#define STMMAC_DEFAULT_TWT_LS_TIMER0x0
+#define STMMAC_DEFAULT_LIT_LS0x3E8
+#define STMMAC_DEFAULT_TWT_LS0x0
 
 #define STMMAC_CHAIN_MODE0x1
 #define STMMAC_RING_MODE0x2
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro&lt;/pre&gt;</description>
    <dc:creator>Giuseppe CAVALLARO</dc:creator>
    <dc:date>2013-06-18T05:03:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.network/273337">
    <title>Problems in bridge.8, ip-netns.8, ip-maddress.8, ip-tunnel.8, ip-route.8, ip-neighbour.8, ip-rule.8</title>
    <link>http://comments.gmane.org/gmane.linux.network/273337</link>
    <description>&lt;pre&gt;This is automatically generated email about markup problems in a man
page for which you appear to be responsible.  If you are not the right
person or list, please tell me so I can correct my database.

See http://catb.org/~esr/doclifter/bugs.html for details on how and
why these patches were generated.  Feel free to email me with any
questions.  Note: These patches do not change the modification date of
any manual page.  You may wish to do that by hand.

I apologize if this message seems spammy or impersonal. The volume of
markup bugs I am tracking is over five hundred - there is no real
alternative to generating bugmail from a database and template.

--
                             Eric S. Raymond
Problems with ip-route.8:

Presentation-level use of SS could not be structurally
translated. I changed lower-level instances to .TP.

--- ip-route.8-unpatched2013-06-01 06:58:12.898961138 -0400
+++ ip-route.82013-06-01 06:58:34.070960742 -0400
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -246,10 +246,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 .I policy routing
 is used.
 
-.SS ip route a&lt;/pre&gt;</description>
    <dc:creator>esr&lt; at &gt;thyrsus.com</dc:creator>
    <dc:date>2013-06-18T05:14:05</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.network">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.network</link>
  </textinput>
</rdf:RDF>
