* Re: [PATCH] ipv4: fix route mark sparse warning
From: David Miller @ 2012-10-11 2:55 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20121010112725.57a6f4a6@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 10 Oct 2012 11:27:25 -0700
> Sparse complains about RTA_MARK which is should be host order according
> to include file and usage in iproute.
>
> net/ipv4/route.c:2223:46: warning: incorrect type in argument 3 (different base types)
> net/ipv4/route.c:2223:46: expected restricted __be32 [usertype] value
> net/ipv4/route.c:2223:46: got unsigned int [unsigned] [usertype] flowic_mark
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2] xen: netback: handle compound page fragments on transmit.
From: David Miller @ 2012-10-11 2:54 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev, xen-devel, eric.dumazet, konrad, linux
In-Reply-To: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 10 Oct 2012 14:48:42 +0100
> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.
>
> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: Pull ip header into skb->data before looking into ip header.
From: David Miller @ 2012-10-11 2:53 UTC (permalink / raw)
To: sarveshwar.bandi; +Cc: netdev
In-Reply-To: <6f6f2599-15e5-49a7-973c-d2c36483427d@CMEXHTCAS1.ad.emulex.com>
From: <sarveshwar.bandi@emulex.com>
Date: Wed, 10 Oct 2012 16:45:01 +0530
> From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
>
> If lower layer driver leaves the ip header in the skb fragment, it needs to
> be first pulled into skb->data before inspecting ip header length or ip version
> number.
>
> Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Applied.
^ permalink raw reply
* Re: [patch] isdn: fix a wrapping bug in isdn_ppp_ioctl()
From: David Miller @ 2012-10-11 2:46 UTC (permalink / raw)
To: dan.carpenter; +Cc: isdn, standby24x7, netdev, kernel-janitors
In-Reply-To: <20121010093816.GA3669@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 10 Oct 2012 12:42:18 +0300
> "protos" is an array of unsigned longs and "i" is the number of bits in
> an unsigned long so we need to use 1UL as well to prevent the shift
> from wrapping around.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
I'll apply this, thanks.
^ permalink raw reply
* Re: [PATCHv2 0/8] vxlan: bug fixes
From: David Miller @ 2012-10-11 2:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20121010063545.453368147@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 09 Oct 2012 23:35:45 -0700
> Revision to earlier patch set for vxlan, includes a couple
> more issues.
Applied, but that checksum issue is extremely unfortunate.
Why does postpull rcsum work for GRE but not VXLAN?
^ permalink raw reply
* Re: [RFC PATCH] net/core: support runtime PM on net_device
From: Ming Lei @ 2012-10-11 2:41 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, Rafael J. Wysocki, Alan Stern, netdev, linux-pm
In-Reply-To: <1661593.Shb8QLRF9A@linux-lqwf.site>
Oliver, sorry for not CC list.
On Wed, Oct 10, 2012 at 9:17 PM, Oliver Neukum <oneukum@suse.de> wrote:
> On Wednesday 10 October 2012 20:58:33 Ming Lei wrote:
>> In ioctl path on net_device, the physical deivce is often
>> touched, but the physical device may have been put into runtime
>> suspend state already, so cause some utilitis(ifconfig, ethtool,
>> ...) to return failure in this situation.
>>
>> This patch enables runtime PM on net_device and mark it as
>> no_callbacks, and resumes the net_device if physical device
>> is to be accessed, then suspends it after completion of the
>> access.
>>
>> This patch fixes the problem above.
>>
>
> [..]
>> + if (pm_runtime_get_sync(&dev->dev) < 0)
>> + return -ENODEV;
>
> -EIO would be appropriate.
-ENODEV should be fine, at least some current drivers
return it in this situation.
>
>> + err = __dev_ifsioc(net, ifr, cmd);
>> +
>> + pm_runtime_put(&dev->dev);
>> +
>> + return err;
>> +}
>> +
>> /*
>> * This function handles all "interface"-type I/O control requests. The actual
>> * 'doing' part of this is dev_ifsioc above.
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index 4d64cc2..2dc43da 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -25,6 +25,7 @@
>> #include <linux/slab.h>
>> #include <linux/rtnetlink.h>
>> #include <linux/sched.h>
>> +#include <linux/pm_runtime.h>
>>
>> /*
>> * Some useful ethtool_ops methods that're device independent.
>> @@ -1464,10 +1465,13 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
>> return -EPERM;
>> }
>>
>> + if ((ret = pm_runtime_get_sync(&dev->dev)) < 0)
>> + return -ENODEV;
>> +
>> if (dev->ethtool_ops->begin) {
>
> Perhaps you should check that first.
No, ->begin() may access physical device too, also no matter
->begin is defined or not, the 'cmd' will be sent to device driver.
>
>> rc = dev->ethtool_ops->begin(dev);
>> if (rc < 0)
>> - return rc;
>> + goto exit;
>> }
>> old_features = dev->features;
>>
>> @@ -1648,6 +1652,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
>>
>> if (old_features != dev->features)
>> netdev_features_change(dev);
>> -
>> +exit:
>> + pm_runtime_put(&dev->dev);
>> return rc;
>> }
>> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
>> index bcf02f6..c9adb89 100644
>> --- a/net/core/net-sysfs.c
>> +++ b/net/core/net-sysfs.c
>> @@ -23,6 +23,7 @@
>> #include <linux/export.h>
>> #include <linux/jiffies.h>
>> #include <net/wext.h>
>> +#include <linux/pm_runtime.h>
>>
>> #include "net-sysfs.h"
>>
>> @@ -1415,6 +1416,9 @@ int netdev_register_kobject(struct net_device *net)
>> if (error)
>> return error;
>>
>> + pm_runtime_no_callbacks(dev);
>> + pm_runtime_enable(dev);
> Why?
Firstly, 'net_device' is a 'class' device, and its class of 'net_class' doesn't
define runtime pm callback. Also no drivers define its runtime pm callback
in its device_type, so I mark it as no_callback.
Also if not enabling runtime pm for net_device, pm_runtime_get_sync()
will return -EACCESS.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH] of/mdio: Staticise !CONFIG_OF stubs
From: David Miller @ 2012-10-11 2:38 UTC (permalink / raw)
To: broonie; +Cc: srinivas.kandagatla, fengguang.wu, netdev
In-Reply-To: <20121010.223427.1187011104173761756.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 10 Oct 2012 22:34:27 -0400 (EDT)
> From: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Date: Wed, 10 Oct 2012 13:33:38 +0900
>
>> The !CONFIG_OF stubs aren't static so if multiple files include the
>> header with this configuration then the linker will see multiple
>> definitions of the stubs.
>>
>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> Applied.
Did you actually try to compile this?
In file included from drivers/net/phy/mdio_bus.c:29:0:
include/linux/of_mdio.h:29:12: warning: ‘of_mdiobus_register’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:34:27: warning: ‘of_phy_find_device’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:39:27: warning: ‘of_phy_connect’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:47:27: warning: ‘of_phy_connect_fixed_link’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:54:24: warning: ‘of_mdio_find_bus’ defined but not used [-Wunused-function]
In file included from drivers/net/phy/mdio-gpio.c:32:0:
include/linux/of_mdio.h:34:27: warning: ‘of_phy_find_device’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:39:27: warning: ‘of_phy_connect’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:47:27: warning: ‘of_phy_connect_fixed_link’ defined but not used [-Wunused-function]
include/linux/of_mdio.h:54:24: warning: ‘of_mdio_find_bus’ defined but not used [-Wunused-function]
If you're going to mark this stuff static, you gotta mark that
shit inline too.
I'll fix this up, but test your changes please.
^ permalink raw reply
* Re: alignment faults in 3.6
From: Jon Masters @ 2012-10-11 2:34 UTC (permalink / raw)
To: Måns Rullgård; +Cc: netdev, linux-arm-kernel
In-Reply-To: <yw1xtxu1pwtv.fsf@unicorn.mansr.com>
On 10/10/2012 10:27 PM, Måns Rullgård wrote:
> There are exactly two possible solutions:
>
> 1. Change the networking code so those structs are always aligned. This
> might not be (easily) possible.
> 2. Mark the structs __packed and fix any typecasts like the ones seen in
> this thread. This will have an adverse effect in cases where the
> structs are in fact aligned.
>
> Both solutions lie squarely in the networking code. It's time to
> involve that list, or we'll never get anywhere.
Sure, please do let's figure out the plan. But my question is tangential
- I am after input from rmk on whether that patch he posted to fix the
atomicity of missaligned faults is going to be something we should plan
to be pulling into 3.6 for Fedora (after there's an official version) to
correct the might_fault warnings, etc.
Meanwhile, a separate fix of some kind is still likely to be needed
because we don't want to take a large number of alignment traps.
Jon.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] of/mdio: Staticise !CONFIG_OF stubs
From: David Miller @ 2012-10-11 2:34 UTC (permalink / raw)
To: broonie; +Cc: srinivas.kandagatla, fengguang.wu, netdev
In-Reply-To: <1349843618-11209-1-git-send-email-broonie@opensource.wolfsonmicro.com>
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Wed, 10 Oct 2012 13:33:38 +0900
> The !CONFIG_OF stubs aren't static so if multiple files include the
> header with this configuration then the linker will see multiple
> definitions of the stubs.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Applied.
^ permalink raw reply
* Re: [Patch v2 5/5] pktgen: replace scan_ip6() with in6_pton()
From: David Miller @ 2012-10-11 2:34 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1349840900-24138-5-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 10 Oct 2012 11:48:20 +0800
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [Patch v2 4/5] pktgen: enable automatic IPv6 address setting
From: David Miller @ 2012-10-11 2:34 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1349840900-24138-4-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 10 Oct 2012 11:48:19 +0800
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [Patch v2 3/5] pktgen: display IPv4 address in human-readable format
From: David Miller @ 2012-10-11 2:34 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1349840900-24138-3-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 10 Oct 2012 11:48:18 +0800
> It is weird to display IPv4 address in %x format, what's more,
> IPv6 address is disaplayed in human-readable format too. So,
> make it human-readable.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [Patch v2 2/5] pktgen: set different default min_pkt_size for different protocols
From: David Miller @ 2012-10-11 2:34 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1349840900-24138-2-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 10 Oct 2012 11:48:17 +0800
> ETH_ZLEN is too small for IPv6, so this default value is not
> suitable.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [Patch v2 1/5] pktgen: fix crash when generating IPv6 packets
From: David Miller @ 2012-10-11 2:33 UTC (permalink / raw)
To: amwang; +Cc: netdev, stable
In-Reply-To: <1349840900-24138-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 10 Oct 2012 11:48:16 +0800
> For IPv6, sizeof(struct ipv6hdr) = 40, thus the following
> expression will result negative:
>
> datalen = pkt_dev->cur_pkt_size - 14 -
> sizeof(struct ipv6hdr) - sizeof(struct udphdr) -
> pkt_dev->pkt_overhead;
>
> And, the check "if (datalen < sizeof(struct pktgen_hdr))" will be
> passed as "datalen" is promoted to unsigned, therefore will cause
> a crash later.
>
> This is a quick fix by checking if "datalen" is negative. The following
> patch will increase the default value of 'min_pkt_size' for IPv6.
>
> This bug should exist for a long time, so Cc -stable too.
>
> Cc: <stable@vger.kernel.org>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: alignment faults in 3.6
From: Måns Rullgård @ 2012-10-11 2:27 UTC (permalink / raw)
To: Jon Masters; +Cc: netdev, linux-arm-kernel
In-Reply-To: <507619FA.6080001@jonmasters.org>
Jon Masters <jonathan@jonmasters.org> writes:
> Hi everyone,
>
> On 10/05/2012 10:33 AM, Rob Herring wrote:
>> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
>>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
>>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
>>>>> Does it matter? I'm just relaying the argument against adding __packed
>>>>> which was used before we were forced (by the networking folk) to implement
>>>>> the alignment fault handler.
>>>>
>>>> It doesn't really matter what will be accepted or not as adding __packed
>>>> to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
>>>> The only way I've found to eliminate the alignment fault is adding a
>>>> barrier between the 2 loads. That seems like a compiler issue to me if
>>>> there is not a better fix.
This turns out to be caused by pointers being typecast to normal
(aligned) types.
>>> Even so, please test the patch I've sent you in the sub-thread - that
>>> needs testing whether or not GCC is at fault. Will's patch to add the
>>> warnings _has_ uncovered a potential issue with the use of __get_user()
>>> in some parts of the ARM specific kernel, and I really need you to test
>>> that while you're experiencing this problem.
>>
>> I've tested your patch and it appears to fix things. Thanks!
[...]
>> Now on to getting rid of faults on practically every single received IP
>> packet:
>>
>> Multi: 9871002
>>
>> RX packets:9872010 errors:0 dropped:0 overruns:0 frame:0
>
> This will still be a problem, indeed. At least we can be aware we're
> taking a large number of faults and hope for a netdev solution.
There are exactly two possible solutions:
1. Change the networking code so those structs are always aligned. This
might not be (easily) possible.
2. Mark the structs __packed and fix any typecasts like the ones seen in
this thread. This will have an adverse effect in cases where the
structs are in fact aligned.
Both solutions lie squarely in the networking code. It's time to
involve that list, or we'll never get anywhere.
--
Måns Rullgård
mans@mansr.com
^ permalink raw reply
* Re: [PATCH net-next? V2] pktgen: Use simpler test for non-zero ipv6 address
From: Cong Wang @ 2012-10-11 2:15 UTC (permalink / raw)
To: Joe Perches; +Cc: Eric Dumazet, netdev, LKML, Brian Haley
In-Reply-To: <1349897005.2035.24.camel@joe-AO722>
On Thu, Oct 11, 2012 at 3:23 AM, Joe Perches <joe@perches.com> wrote:
> Reduces object size and should be slightly faster.
>
> allyesconfig:
> $ size net/core/pktgen.o*
> text data bss dec hex filename
> 52284 4321 11840 68445 10b5d net/core/pktgen.o.new
> 52310 4293 11848 68451 10b63 net/core/pktgen.o.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
Looks good.
This should go to -net, net-next is not open currently.
Thanks.
^ permalink raw reply
* Re: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Dong Aisheng @ 2012-10-11 1:41 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Shawn Guo, Linux Netdev List, Linux-CAN,
Hui Wang
In-Reply-To: <5075D4DA.7010407@pengutronix.de>
On Wed, Oct 10, 2012 at 10:04:42PM +0200, Marc Kleine-Budde wrote:
> On 10/08/2012 09:59 AM, Dong Aisheng-B29396 wrote:
> [...]
>
> >>>> Concerning the bug, I know that the i.MX35 does have it. Maybe other
> >>>> Flexcan cores than on the i.MX28 does *not* have it either. If you
> >>>> have a chance, please check on the P1010, i.MX6Q, i.MX51, i.MX53,
> >>>> etc.
> >>>
> >>> >From what I can tell, i.MX35, i.MX51 and i.MX53 use the same version,
> >>> so they should all have the bug. And for i.MX6Q, since it uses a
> >>> newer version even than i.MX28, I would believe it's affected by the bug.
> >>> But I'm copying Dong who should have better knowledge about this to
> >>> confirm.
> >>
> >> Thank for clarification. I have a i.MX6Q board but without CAN adapter :(,
> >> unfortunately. Otherwise I would try it out myself.
> >>
> > How did you verify this issue?
> > I just checked our ic guy of flexcan, it seems he also had no sense of this issue.
>
> Wolfgang added this table to the driver code, which is a very good idea.
> I've some (nitpicky) questions :)
>
> > Below is some version info what I got:
> > Mx6s use FlexCAN3, with IP version 10.00.12.00
> ^^^
> Is this core different from the mx6q?
Yes, it's a single core named i.MX6 Solo.
For details, please see:
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=IMX6X_SERIES
> Has the flexcan on mx6 a glitch filter?
>
Yes.
> > Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
> > Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
> > Mx35 use FlexCAN2 (without glitch filter) , with IP version 03.00.00.00
> > Mx25 use FlexCAN2 (without glitch filter), with IP version 03.00.00.00
>
> Do you have access to the powerpc designs which have a flexcan core,
> too? I'm interested to complete the above table with powerpcs cores
> (p1010 and similar).
Sorry, we don't have access.
Regards
Dong Aisheng
>
> Marc
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
^ permalink raw reply
* [PATCH NET] e1000e: Change wthresh to 1 to avoid possible Tx stalls
From: Jesse Brandeburg @ 2012-10-11 1:34 UTC (permalink / raw)
To: netdev; +Cc: Hiroaki SHIMODA, eric.dumazet, therbert, Jesse Brandeburg
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
This patch originated from Hiroaki SHIMODA but has been modified
by Intel with some minor cleanups and additional commit log text.
Denys Fedoryshchenko and others reported Tx stalls on e1000e with
BQL enabled. Issue was root caused to hardware delays. They were
introduced because some of the e1000e hardware with transmit
writeback bursting enabled, waits until the driver does an
explict flush OR there are WTHRESH descriptors to write back.
Sometimes the delays in question were on the order of seconds,
causing visible lag for ssh sessions and unacceptable tx
completion latency, especially for BQL enabled kernels.
To avoid possible Tx stalls, change WTHRESH back to 1.
The current plan is to investigate a method for re-enabling
WTHRESH while not harming BQL, but those patches will be later
for net-next if they work.
please enqueue for stable since v3.3 as this bug was introduced in
commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
Author: Tom Herbert <therbert@google.com>
Date: Mon Nov 28 16:33:16 2011 +0000
e1000e: Support for byte queue limits
Changes to e1000e to use byte queue limits.
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
CC: eric.dumazet@gmail.com
CC: therbert@google.com
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/e1000e/e1000.h | 6 +++---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h b/drivers/net/ethernet/intel/e1000e/e1000.h
index cb3356c..04668b4 100644
--- a/drivers/net/ethernet/intel/e1000e/e1000.h
+++ b/drivers/net/ethernet/intel/e1000e/e1000.h
@@ -175,13 +175,13 @@ struct e1000_info;
/*
* in the case of WTHRESH, it appears at least the 82571/2 hardware
* writes back 4 descriptors when WTHRESH=5, and 3 descriptors when
- * WTHRESH=4, and since we want 64 bytes at a time written back, set
- * it to 5
+ * WTHRESH=4, so a setting of 5 gives the most efficient bus
+ * utilization but to avoid possible Tx stalls, set it to 1
*/
#define E1000_TXDCTL_DMA_BURST_ENABLE \
(E1000_TXDCTL_GRAN | /* set descriptor granularity */ \
E1000_TXDCTL_COUNT_DESC | \
- (5 << 16) | /* wthresh must be +1 more than desired */\
+ (1 << 16) | /* wthresh must be +1 more than desired */\
(1 << 8) | /* hthresh */ \
0x1f) /* pthresh */
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index de57a2b..f444eb0 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -2831,7 +2831,7 @@ static void e1000_configure_tx(struct e1000_adapter *adapter)
* set up some performance related parameters to encourage the
* hardware to use the bus more efficiently in bursts, depends
* on the tx_int_delay to be enabled,
- * wthresh = 5 ==> burst write a cacheline (64 bytes) at a time
+ * wthresh = 1 ==> burst write is disabled to avoid Tx stalls
* hthresh = 1 ==> prefetch when one or more available
* pthresh = 0x1f ==> prefetch if internal cache 31 or less
* BEWARE: this seems to work but should be considered first if
^ permalink raw reply related
* [RFC net-next] treewide: s/is_<foo>_ether_addr/eth_addr_<foo>
From: Joe Perches @ 2012-10-11 0:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, LKML, Brian Haley
In-Reply-To: <1349897923.2035.31.camel@joe-AO722>
Maybe all the is_<foo>_ether_addr functions should be renamed
to eth_addr_<foo> for more api/style symmetry.
$ git grep --name-only -E "\bis_\w+_ether_addr" | \
xargs sed -r -i -e 's/\bis_(\w+)_ether_addr\b/eth_addr_\1/g'
$ git diff --shortstat
304 files changed, 690 insertions(+), 690 deletions(-)
Maybe add #defines of the old names for a few releases.
^ permalink raw reply
* Re: [PATCH 0/3] virtio-net: inline header support
From: Rusty Russell @ 2012-10-11 0:03 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, Michael S. Tsirkin, netdev, linux-kernel, virtualization,
Sasha Levin, avi, Thomas Lendacky
In-Reply-To: <5073D1D8.3060905@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 09/10/2012 06:59, Rusty Russell ha scritto:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>>>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>>>> said to Anthony, the best rules are "always" and "never", so I'd really
>>>> rather not have to grandfather that in.
>>>
>>> It is, but we can add a rule that if the (transport) flag
>>> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
>>> virtio-blk.
>>
>> Could we do that? It's the cmd length I'm concerned about; is it always
>> 32 in practice for some reason?
>
> It is always 32 or less except in very obscure cases that are pretty
> much confined to iSCSI. We don't care about the obscure cases, and the
> extra bytes don't hurt.
>
> BTW, 32 is the default cdb_size used by virtio-scsi.
>
>> Currently qemu does:
>>
>> struct sg_io_hdr hdr;
>> memset(&hdr, 0, sizeof(struct sg_io_hdr));
>> hdr.interface_id = 'S';
>> hdr.cmd_len = req->elem.out_sg[1].iov_len;
>> hdr.cmdp = req->elem.out_sg[1].iov_base;
>> hdr.dxfer_len = 0;
>>
>> If it's a command which expects more output data, there's no way to
>> guess where the boundary is between that command and the data.
>
> Yep, so I understood the problem right.
OK. Well, Anthony wants qemu to be robust in this regard, so I am
tempted to rework all the qemu drivers to handle arbitrary layouts.
They could use a good audit anyway.
This would become a glaring exception, but I'm tempted to fix it to 32
bytes at the same time as we get the new pci layout (ie. for the virtio
1.0 spec). The Linux driver would carefully be backwards compatible, of
course, and the spec would document why.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] Add CDC-ACM support for the CX93010-2x UCMxx USB Modem
From: Jean-Christian de Rivaz @ 2012-10-10 22:49 UTC (permalink / raw)
To: davem; +Cc: netdev, oneukum
This USB V.92/V.32bis Controllered Modem have the USB vendor ID 0x0572
and device ID 0x1340. It need the NO_UNION_NORMAL quirk to be recognized.
Reference:
http://www.conexant.com/servlets/DownloadServlet/DSH-201723-005.pdf?docid=1725&revid=5
See idVendor and idProduct in table 6-1. Device Descriptors
Signed-off-by: Jean-Christian de Rivaz <jc@eclis.ch>
---
drivers/usb/class/cdc-acm.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 36f2be4..981f213 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1551,6 +1551,9 @@ static const struct usb_device_id acm_ids[] = {
Maybe we should define a new
quirk for this. */
},
+ { USB_DEVICE(0x0572, 0x1340), /* Conexant CX93010-2x UCMxx */
+ .driver_info = NO_UNION_NORMAL,
+ },
{ USB_DEVICE(0x1bbb, 0x0003), /* Alcatel OT-I650 */
.driver_info = NO_UNION_NORMAL, /* reports zero length descriptor */
},
--
1.7.2.5
^ permalink raw reply related
* unresponsive vlan on top of bond with fail_over_mac=active
From: Michal Kubecek @ 2012-10-10 23:11 UTC (permalink / raw)
To: netdev; +Cc: Jay Vosburgh, Andy Gospodarek
Hello,
a customer of ours has the following problem:
A bond is set up in active-backup mode with fail_over_mac=1 (active). On
top of it, a VLAN is created so that it inherits MAC address of the bond
which is the same as address of its active slave.
When failover occurs, the bond switches its MAC address to address of
the new active slave but VLAN interface keeps the old address and it
stops receiving packets from outside.
The customer suggested that upon failover, not only bond should switch
its MAC address to the new active slave but also all VLAN interfaces on
top of it. I don't like this approach too much as there is already a
different mechanism for the problem: network device's uc list. Since
commits
7d26bb10 bonding: emit event when bonding changes MAC
2af73d4b net/bonding: emit address change event also in bond_release
VLAN device's MAC address is copied into bond's uc list. Unfortunately
there is no code taking care of syncing the bond's uc list to its
slaves (so that the slave drops the packets for the VLAN). My idea is to
do this either via ndo_set_rx_mode method or in response to an event.
But before proposing a patch, I would like to ask: which approach is
preferrable: copying active slave's hw address to all VLAN devices
defined on top of the bond or syncing bond's uc list to its slaves?
Thanks in advance,
Michal Kubecek
^ permalink raw reply
* Re: [GIT PULL nf] IPVS fix for 3.7
From: Pablo Neira Ayuso @ 2012-10-10 22:02 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Hans Schillstrom,
Jesper Dangaard Brouer, Arnd Bergmann
In-Reply-To: <1349758037-25317-1-git-send-email-horms@verge.net.au>
On Tue, Oct 09, 2012 at 01:47:16PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider the following fix for IPVS from Arnd Bergmann for
> inclusion in 3.7. I would also like it considered for 3.6, 3.5, 3.4, 3.3
> and 3.0 stable.
Pulled, thanks Simon. Will pass this to stable.
^ permalink raw reply
* Re: [PATCH] net/ethernet/jme: disable ASPM
From: Kevin Baradon @ 2012-10-10 20:50 UTC (permalink / raw)
To: David Miller; +Cc: mjg59, cooldavid, netdev
In-Reply-To: <20121008.153953.2134806395029777705.davem@davemloft.net>
Le Mon, 08 Oct 2012 15:39:53 -0400 (EDT),
David Miller <davem@davemloft.net> a écrit :
> From: Matthew Garrett <mjg59@srcf.ucam.org>
> Date: Mon, 8 Oct 2012 20:33:16 +0100
>
> > On Mon, Oct 08, 2012 at 03:24:26PM -0400, David Miller wrote:
> >
> >> This should be a PCI quirk shouldn't it?
> >
> > No, it's a driver-level policy decision.
>
> Then at a bare minimum this change should be using one of the ASPM
> helpers provided by drivers/pci/pcie/aspm.c such as
> pci_disable_link_state().
pci_disable_link_state() is already used in this patch.
Am I missing something else?
Below you will find updated patch with corrected indentation.
-- >8 --
Subject: [PATCH] net/ethernet/jme: disable ASPM
Based on patch from Matthew Garrett <mjg@redhat.com> (https://lkml.org/lkml/2011/11/11/168).
http://driveragent.com/archive/30421/7-0-14 indicates that ASPM is
disabled on the 250 and 260. Duplicate for sanity.
Fixes random RX engine hangs I experienced with JMC250 on Clevo W270HU.
Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
Cc: Guo-Fu Tseng <cooldavid@cooldavid.org>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/jme.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index c911d88..f8064df 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -27,6 +27,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/pci.h>
+#include <linux/pci-aspm.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
@@ -2973,6 +2974,9 @@ jme_init_one(struct pci_dev *pdev,
/*
* set up PCI device basics
*/
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+ PCIE_LINK_STATE_CLKPM);
+
rc = pci_enable_device(pdev);
if (rc) {
pr_err("Cannot enable PCI device\n");
--
1.7.10.4
^ permalink raw reply related
* Re: pull-request: can 2012-10-10
From: Marc Kleine-Budde @ 2012-10-10 20:42 UTC (permalink / raw)
To: davem; +Cc: linux-can, socketcan, netdev, dhowells, Marc Kleine-Budde
In-Reply-To: <1349901576-30774-1-git-send-email-mkl@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
On 10/10/2012 10:39 PM, Marc Kleine-Budde wrote:
> Hello David,
>
> this pull request for net, i.e. the v3.7 release cycle, contains the patch by
> David Howells to move the UAPI related headers for the CAN subsystem.
I cherry picked David's patch, hope this is correct. Let me know, if a
merge is preferred here and I'll do so.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ 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