On Fri, Jun 26, 2015 at 9:21 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 6/26/2015 3:08 PM, Geert Uytterhoeven wrote:
>
>> If NO_DMA=y:
>
>
>> ERROR: "dma_sync_single_for_cpu"
>> [drivers/net/ethernet/via/via-rhine.ko] undefined!
>> ERROR: "dma_set_mask" [drivers/net/ethernet/via/via-rhin
Hi Oliver!
I wish sincerely to thank you again for your time and patience.
On Fri, 26 Jun 2015, Oliver Neukum wrote:
Date: Fri, 26 Jun 2015 10:14:02
From: Oliver Neukum
To: Enrico Mioso
Cc: linux-...@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH RFC] 2/2 huawei_cdc_ncm: introduc
Hi,
Thanks for the Update.
I agree with Jonathon and this change has to be picked by the stable
release. Configuration like this might end up creating huge
duplication of frames for end nodes.
Regards,
Ajith
On 27 June 2015 at 05:27, Jonathan Toppins wrote:
> On 6/26/15 5:19 PM, Jay Vosburgh
On 06/26/2015 04:09 PM, Tom Herbert wrote:
Add calls to gro_cells infrastructure to do GRO when receiving on a tunnel.
Testing:
Ran 200 netperf TCP_STREAM instance
- With fix (GRO enabled on VXLAN interface)
Verify GRO is happening.
9084 MBps tput
3.44% CPU utilization
- Without fi
On 06/25/2015 06:37 PM, Ajith Adapa wrote:
Hi,
How can I know the current maintainer for Linux Bonding Driver ?
You can look in the MAINTAINERS file in a current source-tree:
BONDING DRIVER
M: Jay Vosburgh
M: Veaceslav Falico
M: Andy Gospodarek
L: netdev@vger.kernel.or
On 6/26/15 5:19 PM, Jay Vosburgh wrote:
Ajith Adapa wrote:
On 26 June 2015 at 07:45, Jay Vosburgh wrote:
echo 'module bonding =p' > /sys/kernel/debug/dynamic_debug/control
Hi,
thanks for the reply.
I tried this out a bit here, and could reproduce the problem on
3.13, but not on 4
The following lockdep splat was seen due to the wrong context for
grabbing in_dev.
===
[ INFO: suspicious RCU usage. ]
4.1.0-next-20150626-dbg-00020-g54a6d91-dirty #244 Not tainted
---
include/linux/inetdevice.h:205 suspicious
On Fri, Jun 26, 2015 at 3:48 PM, Francois Romieu wrote:
> Andy Lutomirski :
>> [re-add netdev -- I assume you meant to reply all]
>
> Thanks. Late friday.
>
>> On Fri, Jun 26, 2015 at 1:32 PM, Francois Romieu
>> wrote:
>> > Andy Lutomirski :
>> > [...]
>> >> Could we add some option to do SNAT
Nicolae Rosia :
[...]
> I gave it a shot. Can you please take a look?
> I don't know how to deal with multiple queues since Zynq 7000 has one
> queue per interface.
macb_interrupt knows the queue. macb_poll doesn't. Either you store it
somewhere or you go for per queue napi struct.
--
Ueimor
--
Add calls to gro_cells infrastructure to do GRO when receiving on a tunnel.
Testing:
Ran 200 netperf TCP_STREAM instance
- With fix (GRO enabled on VXLAN interface)
Verify GRO is happening.
9084 MBps tput
3.44% CPU utilization
- Without fix (GRO disabled on VXLAN interface)
Verified
Andy Lutomirski :
> [re-add netdev -- I assume you meant to reply all]
Thanks. Late friday.
> On Fri, Jun 26, 2015 at 1:32 PM, Francois Romieu wrote:
> > Andy Lutomirski :
> > [...]
> >> Could we add some option to do SNAT and inverse DNAT before routing?
> >
> > I haven't used it for ages but
On 6/26/15, 3:33 PM, Stephen Hemminger wrote:
On Fri, 26 Jun 2015 14:49:11 -0700
roopa wrote:
Hi Stephen,
I don't see the below fix in the 4.1 tarball you point below:
https://patchwork.ozlabs.org/patch/479743/
I am not sure yet if there was a problem with my submission. I intended
for it to
On Fri, 26 Jun 2015 14:49:11 -0700
roopa wrote:
> Hi Stephen,
>
> I don't see the below fix in the 4.1 tarball you point below:
> https://patchwork.ozlabs.org/patch/479743/
>
> I am not sure yet if there was a problem with my submission. I intended
> for it to go into 4.1.
>
> Thanks,
> Roopa
On Fri, 26 Jun 2015 09:31:45 +0200
Bastian Bittorf wrote:
> * Vadim Kochan [15.06.2015 18:36]:
> > > root@box:~ ip route list exact '0.0.0.0/8'
> > > root@box:~ echo $?
> > > 0
> > >
> > > i expected an RC of != 0 when there is no match.
> > > is this by design?
> > >
> > > root@box:~ ip -V
>
From: Phil Hofer
The mvneta driver for Marvell 370 had TCP performance problems
over IPv6. (In my tests of 10s runs with 64kB packets, I got about
560Mbps on IPv6 and 950Mbps on IPv4.) After this patch, IPv6
performance jumps up to about 860Mbps.
This patch adds NETIF_F_CSUM_IPV6 to the list of
Hi Stephen,
I don't see the below fix in the 4.1 tarball you point below:
https://patchwork.ozlabs.org/patch/479743/
I am not sure yet if there was a problem with my submission. I intended
for it to go into 4.1.
Thanks,
Roopa
On 6/26/15, 1:06 PM, Stephen Hemminger wrote:
Update to iproute2
On 2015-06-26 12:59, Tom Herbert wrote:
On Fri, Jun 26, 2015 at 12:31 PM, Ramu Ramamurthy
wrote:
On 2015-06-26 11:04, Tom Herbert wrote:
I am testing the simplest configuration which has 1 TCP flow
generated by
iperf from
a VM connected to a linux bridge with a vxlan tunnel interface. The
On Thu, Jun 25, 2015 at 06:19:07AM -0700, David Miller wrote:
> Just make a ax25_sock structure that provides the ax25_cb pointer.
Nice minimal solution, thanks!
I have the big solution my queue which combines struct sock with ax25_cb
into struct ax25_sock but that's more complex because current
Ajith Adapa wrote:
>On 26 June 2015 at 07:45, Jay Vosburgh wrote:
>> echo 'module bonding =p' > /sys/kernel/debug/dynamic_debug/control
>Hi,
>
>thanks for the reply.
I tried this out a bit here, and could reproduce the problem on
3.13, but not on 4.0.0. A bit of checking suggests that
[re-add netdev -- I assume you meant to reply all]
On Fri, Jun 26, 2015 at 1:32 PM, Francois Romieu wrote:
> Andy Lutomirski :
> [...]
>> Could we add some option to do SNAT and inverse DNAT before routing?
>
> I haven't used it for ages but what's wrong with iptables + fwmark ?
>
> It takes pla
On Fri, Jun 26, 2015 at 01:31:09PM -0700, Phil Hofer wrote:
> I've made some changes based on advice from Willy Tarreau.
> The changes don't influence the IPv6 performance numbers on our board
> relative to the previous patch. I still get about 90% of IPv4
> performance.
>
> Enabling NETIF_F_TSO6
Update to iproute2 for 4.1
4.1 is released and this is the corresponding iproute2.
Noteable features:
* new command for controlling TIPC
* BPF support in tc
* Lots of RED cleanup work
* Enhancements to ss
* color option to ip command
Source:
http://www.kernel.org/pub/linux/utils/
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Friday, June 26, 2015 8:32 AM
> To: David Miller
> Cc: netdev; Michal Kalderon; Yuval Mintz; Ariel Elior; David
> Decotigny; Michel Lespinasse
> Subject: [PATCH net] bnx2x: fix lockdep splat
>
> From: Eric Dumazet
>
> Michel reported f
I've made some changes based on advice from Willy Tarreau.
The changes don't influence the IPv6 performance numbers on our board
relative to the previous patch. I still get about 90% of IPv4
performance.
Enabling NETIF_F_TSO6 still causes problems; that will probably have
to be addressed in a sepa
On Fri, Jun 26, 2015 at 10:33 AM, Craig Gallek wrote:
> On Fri, Jun 26, 2015 at 1:17 AM, Eric Dumazet wrote:
>> On Fri, 2015-06-26 at 00:44 -0400, Dave Jones wrote:
>>> I taught Trinity about NETLINK_LISTEN_ALL_NSID and NETLINK_LIST_MEMBERSHIPS
>>> yesterday, and this evening, this fell out..
>>>
On Fri, Jun 26, 2015 at 12:31 PM, Ramu Ramamurthy
wrote:
> On 2015-06-26 11:04, Tom Herbert wrote:
>>>
>>> I am testing the simplest configuration which has 1 TCP flow generated by
>>> iperf from
>>> a VM connected to a linux bridge with a vxlan tunnel interface. The 10G
>>> nic
>>> (82599 ES) has
My apologies.
I have a follow-up on the way with some of Willy's suggested changes as well.
On Fri, Jun 26, 2015 at 11:52 AM, Thomas Petazzoni
wrote:
> Hello Phil,
>
> On Fri, 26 Jun 2015 11:12:03 -0700, Phil Hofer wrote:
>> TCP performance over IPv6 was only about 60% of IPv4 performance. This
It's quite clear to me why NAT rules that rewrite the destination
address have to happen before routing -- the kernel needs to do that
to route the packets to their destination.
It's much less clear to me why the kernel insists on rewriting source
addresses after routing. Certainly it makes rp_fi
On 2015-06-26 11:04, Tom Herbert wrote:
I am testing the simplest configuration which has 1 TCP flow generated
by
iperf from
a VM connected to a linux bridge with a vxlan tunnel interface. The
10G nic
(82599 ES) has
multiple receive queues, but in this simple test, it is likely
immaterial
(b
Hello Phil,
On Fri, 26 Jun 2015 11:12:03 -0700, Phil Hofer wrote:
> TCP performance over IPv6 was only about 60% of IPv4 performance. This
> patch makes up most (but not all) of the difference.
>
> Signed off by: Thomas Petazzoni (thomas.petazz...@free-electrons.com)
What makes you think you can
On 26/06/15 02:58, Shengzhou Liu wrote:
> As some C45 10G PHYs(e.g. Cortina CS4315/CS4340 PHY) have
> zero Devices In package, current driver can't get correct
> devices_in_package value by non-zero Devices In package.
> so let's probe more with zero Devices In package to support
> more C45 PHYs.
TCP performance over IPv6 was only about 60% of IPv4 performance. This
patch makes up most (but not all) of the difference.
Signed off by: Thomas Petazzoni (thomas.petazz...@free-electrons.com)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 5bdf78
> I am testing the simplest configuration which has 1 TCP flow generated by
> iperf from
> a VM connected to a linux bridge with a vxlan tunnel interface. The 10G nic
> (82599 ES) has
> multiple receive queues, but in this simple test, it is likely immaterial
> (because, the
> tuple on which it has
> On Jun 17, 2015, at 9:44 AM, Bjorn Helgaas wrote:
>
> On Wed, Jun 17, 2015 at 11:29 AM, Rustad, Mark D
> wrote:
>> + Alex
>>
>>> On Jun 5, 2015, at 2:59 PM, Rustad, Mark D wrote:
>>>
On Jun 3, 2015, at 11:46 AM, Mark D Rustad wrote:
Many multi-function devices provide share
When packet encapsulation is in use, the MTU needs to be reduced for
headroom reservation.
The existing code takes the updated MTU value only from the host side.
But vSwitch extensions, such as Open vSwitch, require the flexibility
to change the MTU to different values from within a guest during th
Hi,
I gave it a shot. Can you please take a look?
I don't know how to deal with multiple queues since Zynq 7000 has one
queue per interface.
I get a performance improvement of over 110 Mbps in IP forwarding (680
Mbps vs 570 Mbps) and a massive reduction of interrupts.
Patch below.
From: Nicolae
On 26/06/15 10:38, Florian Fainelli wrote:
> Hi David,
>
> This patch series fixes occasional BCM7xxx PHY driver binding failure due
> to a harware bug where the first read or write does not come out of the PHY
> MDIO management controller.
>
> Since we have two different MDIO controllers using t
The initial MDIO read or write towards the BCM7xxx integrated PHY may
fail, workaround this by inserting a dummy MII_BMSR read to force the
MDIO management controller to see at least one valid transaction and get
out of stuck state out of reset.
Signed-off-by: Florian Fainelli
---
drivers/net/ph
All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
management controller which will make the initial read or write to them
to fail and return 0x. This is a real issue as the typical first
thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
to register a driver fo
All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
management controller which will make the initial read or write to them
to fail and return 0x. This is a real issue as the typical first
thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
to register a driver fo
Hi David,
This patch series fixes occasional BCM7xxx PHY driver binding failure due
to a harware bug where the first read or write does not come out of the PHY
MDIO management controller.
Since we have two different MDIO controllers using this PHY, a similar
need to be replicated in GENET and Uni
All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
management controller which will make the initial read or write to them
to fail and return 0x. This is a real issue as the typical first
thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
to register a driver fo
The RGMII block is currently only powered on when using RGMII or
RGMII_NO_ID, which is not correct when using the GENET interface in MII
or Reverse MII modes. We always need to power on the RGMII interface for
this block to properly work, regardless of the MII mode in which we
operate.
Fixes: aa09
The initial MDIO read or write towards the BCM7xxx integrated PHY may
fail, workaround this by inserting a dummy MII_BMSR read to force the
MDIO management controller to see at least one valid transaction and get
out of stuck state out of reset.
Signed-off-by: Florian Fainelli
---
drivers/net/ph
Hi David,
This patch series fixes occasional BCM7xxx PHY driver binding failure due
to a harware bug where the first read or write does not come out of the PHY
MDIO management controller.
Since we have two different MDIO controllers using this PHY, a similar
need to be replicated in GENET and Uni
On 2015-06-25 19:57, Tom Herbert wrote:
On Thu, Jun 25, 2015 at 6:06 PM, Ramu Ramamurthy
wrote:
On 2015-06-25 17:20, Tom Herbert wrote:
On Thu, Jun 25, 2015 at 5:03 PM, Ramu Ramamurthy
wrote:
Problem:
---
GRO is enabled on the interfaces in the following test,
but GRO does not take ef
On Thu, Jun 25, 2015 at 10:15 PM, Eric Dumazet wrote:
> On Thu, 2015-06-25 at 19:57 -0700, Tom Herbert wrote:
>
>> That may be, but this change would affect all uses of GRO with UDP
>> encapsulation not just for intel 10G NICs. For instance, pushing a lot
>> of checksum calculation into the napi f
On 25/06/15 06:50, gil...@ezchip.com wrote:
> From: Gilad Ben-Yossef
>
> DSA master netdev promiscuity counter was not being properly
> decremented on slave device open error path.
>
> Signed-off-by: Gilad Ben-Yossef
> CC: Gilad Ben-Yossef
> CC: David S. Miller
> CC: Florian Fainelli
> CC: G
On 06/26/2015 05:50 PM, Michal Schmidt wrote:
> With CONFIG_DMA_API_DEBUG=y bnx2x triggers the error "DMA-API: device
> driver frees DMA memory with wrong function".
> On archs where PAGE_SIZE > SGE_PAGE_SIZE it also triggers "DMA-API:
> device driver frees DMA memory with different size".
>
> Fix
With CONFIG_DMA_API_DEBUG=y bnx2x triggers the error "DMA-API: device
driver frees DMA memory with wrong function".
On archs where PAGE_SIZE > SGE_PAGE_SIZE it also triggers "DMA-API:
device driver frees DMA memory with different size".
Fix this by making the mapping and unmapping symmetric:
- Do
With CONFIG_DMA_API_DEBUG=y bnx2x triggers the error "DMA-API: device
driver frees DMA memory with wrong function".
On archs where PAGE_SIZE > SGE_PAGE_SIZE it also triggers "DMA-API:
device driver frees DMA memory with different size".
Fix this by making the mapping and unmapping symmetric:
- Do
Hi Andrew,
On Jun 26, 2015, at 11:23 AM, Andrew Lunn and...@lunn.ch wrote:
>> >> +static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds, u16 vid,
>> >> + struct mv88e6xxx_vtu_entry *entry)
>> >> +{
>> >> +int ret, i;
>> >> +
>> >> +ret = _mv88e6xxx_vtu_wait(ds);
>> >> +
> >> +static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds, u16 vid,
> >> + struct mv88e6xxx_vtu_entry *entry)
> >> +{
> >> +int ret, i;
> >> +
> >> +ret = _mv88e6xxx_vtu_wait(ds);
> >> +if (ret < 0)
> >> +return ret;
> >> +
> >> +ret = _mv88e6xxx_reg_wri
Currently "ALU_END_FROM_BE 32" and "ALU_END_FROM_LE 32" do not test if
the upper bits of the result are zeros (the arm64 JIT had such bugs).
Extend the two tests to catch this.
Cc: Alexei Starovoitov
Signed-off-by: Xi Wang
---
See the arm64 JIT bugs:
https://lkml.org/lkml/2015/6/25/721
---
lib
On Fri, 2015-06-26 at 08:55 +0200, Richard Cochran wrote:
> Chris,
>
> Basically this patch looks okay to me. Could you please add LKML,
> John Stultz and tglx (the time guys) onto CC? I would like to get
> their Acks or at least let them have a chance to review it.
>
> On Thu, Jun 25, 2015 at
On 27/06/15 00:17, Liang Li wrote:
> The function netif_set_real_num_tx_queues() will return -EINVAL if
> the second parameter < 1, so call this function with the second
> parameter set to 0 is meaningless.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "unsubscr
On Thu, Jun 25, 2015 at 04:50:13PM +0300, gil...@ezchip.com wrote:
> From: Gilad Ben-Yossef
>
> DSA master netdev promiscuity counter was not being properly
> decremented on slave device open error path.
>
> Signed-off-by: Gilad Ben-Yossef
> CC: Gilad Ben-Yossef
> CC: David S. Miller
> CC: Fl
Hi Andrew,
On Jun 26, 2015, at 10:04 AM, Andrew Lunn and...@lunn.ch wrote:
> On Tue, Jun 23, 2015 at 05:46:08PM -0400, Vivien Didelot wrote:
>> Implement the Get Next operation for the VLAN Table Unit, and a "vtu"
>> debugfs file to dump the hardware VLANs.
>>
>> A populated VTU can look like thi
Hi Andrew,
On Jun 26, 2015, at 10:10 AM, Andrew Lunn and...@lunn.ch wrote:
> On Tue, Jun 23, 2015 at 05:46:09PM -0400, Vivien Didelot wrote:
>> This commit implements the port_vlan_dump function in the
>> dsa_switch_driver structure for Marvell 88E6xxx compatible switches.
>>
>> This allows to a
On Fri, Jun 26, 2015 at 5:37 AM, Zhu Yanjun wrote:
> The new net namespace can inherit from the original net config, or
> the current net config. As such, a config is needed to decide where
> the new namespace inherit from.
As per the netdev mailing list FAQ, and Dave's post from a day
or two ago
On Fri, Jun 26, 2015 at 1:17 AM, Eric Dumazet wrote:
> On Fri, 2015-06-26 at 00:44 -0400, Dave Jones wrote:
>> I taught Trinity about NETLINK_LISTEN_ALL_NSID and NETLINK_LIST_MEMBERSHIPS
>> yesterday, and this evening, this fell out..
>>
>> general protection fault: [#1] PREEMPT SMP DEBUG_PAG
From: Of Jeff Kirsher
> Sent: 26 June 2015 11:21
> In SPT/i219, there were CRC errors in speed 10/100 full duplex.
> The solution given by the HW team is to increase the IPG from 8 to 0xC
>
> Signed-off-by: Yanir Lubetkin
> Tested-by: Aaron Brown
> Signed-off-by: Jeff Kirsher
> ---
> drivers/n
Hi Andrew,
On Jun 26, 2015, at 10:12 AM, Andrew Lunn and...@lunn.ch wrote:
> On Tue, Jun 23, 2015 at 05:46:10PM -0400, Vivien Didelot wrote:
>> Add support for dumping the VLAN Table Unit entries by pointing to the
>> port_vlan_dump function implemented for mv88e6xxx.
>>
>> Signed-off-by: Vivien
On Tue, Jun 23, 2015 at 05:46:09PM -0400, Vivien Didelot wrote:
> This commit implements the port_vlan_dump function in the
> dsa_switch_driver structure for Marvell 88E6xxx compatible switches.
>
> This allows to access a switch VLAN Table Unit from standard userspace
> commands such as "bridge v
On Fri, Jun 26, 2015 at 06:35:40PM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> Since 0eeb075fad736 ('net: ipv4 sysctl option to ignore routes when nexthop
> link is down') fib_dump_info() and fib_sync_up() are using __in_dev_get_rcu(),
> which requires (missing) RCU read side protection.
Yep, I
On Tue, Jun 23, 2015 at 05:46:10PM -0400, Vivien Didelot wrote:
> Add support for dumping the VLAN Table Unit entries by pointing to the
> port_vlan_dump function implemented for mv88e6xxx.
>
> Signed-off-by: Vivien Didelot
> ---
> drivers/net/dsa/mv88e6352.c | 1 +
> 1 file changed, 1 insertion
On Tue, Jun 23, 2015 at 05:46:08PM -0400, Vivien Didelot wrote:
> Implement the Get Next operation for the VLAN Table Unit, and a "vtu"
> debugfs file to dump the hardware VLANs.
>
> A populated VTU can look like this:
>
> # cat /sys/kernel/debug/dsa0/vtu
> VID FID SID P0 P1 P2 P3 P4 P
On 26 June 2015 at 07:45, Jay Vosburgh wrote:
> echo 'module bonding =p' > /sys/kernel/debug/dynamic_debug/control
Hi,
thanks for the reply.
Linux server (enp0s8)(bond0) (po1)(xe1) switch
Linux server (enp0s9)(bond0) (po2)(xe2) switch
I have tried the steps mentioned in the pr
Hello.
On 6/26/2015 3:08 PM, Geert Uytterhoeven wrote:
If NO_DMA=y:
ERROR: "dma_sync_single_for_cpu" [drivers/net/ethernet/via/via-rhine.ko]
undefined!
ERROR: "dma_set_mask" [drivers/net/ethernet/via/via-rhine.ko] undefined!
ERROR: "dma_mapping_error" [drivers/net/ethernet/vi
On 06/04/2015, 10:54 PM, Michal Kubecek wrote:
> Hello,
>
> please queue mainline commit
>
> ac37e2515c1a ("xfrm: release dst_orig in case of error in xfrm_lookup()")
>
> for stable branches 3.12, 3.14 and 3.18. It fixes a dst_entry reference
> leak introduced by commit
>
> f92ee61982d6 ("x
If NO_DMA=y:
ERROR: "dma_sync_single_for_cpu" [drivers/net/ethernet/via/via-rhine.ko]
undefined!
ERROR: "dma_set_mask" [drivers/net/ethernet/via/via-rhine.ko] undefined!
ERROR: "dma_mapping_error" [drivers/net/ethernet/via/via-rhine.ko]
undefined!
ERROR: "dma_map_single" [drivers
The function netif_set_real_num_tx_queues() will return -EINVAL if
the second parameter < 1, so call this function with the second
parameter set to 0 is meaningless.
Signed-off-by: Liang Li
---
drivers/net/xen-netfront.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/net/xen-n
Hash value passed as argument into rhashtable_lookup_compare could be
computed using different hash table than rhashtable_lookup_compare sees.
This patch passes key into rhashtable_lookup_compare() instead of hash and
compures hash value right in place using the same table as for lookup.
Also it
On 14.05.2015 07:21, Herbert Xu wrote:
On Thu, May 14, 2015 at 12:16:28PM +0800, Herbert Xu wrote:
On Wed, May 13, 2015 at 09:13:38PM -0700, Eric Dumazet wrote:
So it looks like we lost an skb or something
OK that sounds reasonable. So my plan is to disable dynamic
rehashing and then hu
From: Yanir Lubetkin
In i219, there is a hardware bug that prevented ULP entry.
A side effect of the original software fix for this was that EEE in
Sx couldn't be enabled.
This patch implements a modified flow that allows both ULP and EEE in Sx.
Signed-off-by: Yanir Lubetkin
Tested-by: Aaron Br
From: Yanir Lubetkin
Due to clocking changes in the Skylake platform, there was i219
data corruption. To work around this, HW team reported the need
to increase the minimum gap between the PHY FIFO read and write pointers.
Signed-off-by: Yanir Lubetkin
Tested-by: Aaron Brown
Signed-off-by: Jef
From: Yanir Lubetkin
In SPT/i219, there were CRC errors in speed 10/100 full duplex.
The solution given by the HW team is to increase the IPG from 8 to 0xC
Signed-off-by: Yanir Lubetkin
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++
From: Yanir Lubetkin
On power up, the MAC - PHY interface needs to be set to PCIe, even if
cable is disconnected. In ME systems, the ME handles this on exit from
Sx state. In non-ME, the driver handles it. Added a check for non-ME
system to the driver code that handles that.
Signed-off-by: Yani
From: Mitch Williams
The driver will only configure as many queues as there are available
CPUs, up the maximum number of queues. However, it always configures
RSS as though it is using the maximum number of queues. This can cause
the device to drop a lot of RX traffic, as the packets get assigned
From: Yanir Lubetkin
e1000e_disable_aspm called pci_disable_link_state_locked which requires
pci_bus_sem to be held, but is also called from places where this semaphore
was not previously acquired. This patch implements two flavors of
disable_aspm, one that acquires the lock, and the other (_lock
From: Yanir Lubetkin
In SPT hardware does not require this driver workaround.
Removed the conditional that caused K1 workaround execution on SPT.
Signed-off-by: Yanir Lubetkin
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 3 +--
1 file c
From: Mitch Williams
Down was requesting queue disables, but then exited immediately
without waiting for the queues to actually disable. This could
allow any function called after i40evf_down to run immediately,
including i40evf_up, and causes a memory leak.
Removing the whole reinit_locked fun
From: Todd Fujinaka
Bump version of igb to igb-5.2.18
Signed-off-by: Todd Fujinaka
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b
This series contains fixes for igb, e1000e and i40evf.
Todd disables IPv6 extension header processing due to a hardware errata
and bumps the driver version.
Yanir provides six fixes for e1000e. First is a fix for a locking issue
where we were not always taking the pci_bus_sem semaphore all the t
From: Todd Fujinaka
Disable IPv6 extension header processing as per hardware errata.
Also fix copyright date.
Signed-off-by: Todd Fujinaka
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 12
drivers/net/ethernet/intel/igb/
As some C45 10G PHYs(e.g. Cortina CS4315/CS4340 PHY) have
zero Devices In package, current driver can't get correct
devices_in_package value by non-zero Devices In package.
so let's probe more with zero Devices In package to support
more C45 PHYs.
Signed-off-by: Shengzhou Liu
---
v3: restructure
Hi, all
Some expect the new net namespace inherits from the original net config.
Some expect the new net namespace
inherits from the current net config, including the modified net
configurations.
To meet the different reqirements, this patch is made.
I think maybe mainline should need this p
The new net namespace can inherit from the original net config, or
the current net config. As such, a config is needed to decide where
the new namespace inherit from.
Signed-off-by: Zhu Yanjun
---
init/Kconfig | 9 +
net/ipv4/devinet.c | 13 +
2 files changed, 22 inser
suspicious RCU usage. ]
[ 60.605037] 4.1.0-next-20150626-dbg-00020-g54a6d91-dirty #244 Not tainted
[ 60.605038] ---
[ 60.605040] include/linux/inetdevice.h:205 suspicious
rcu_dereference_check() usage!
[ 60.605041]
other info that might help us
"Chenqi (jakio)" writes:
> Hi, All,
>
> I'm from Huawei Technologies Co., Ltd, working in mobile broadband
> devices department.
>
> Huawei's broadband card don't support wwan in linux OS, there are
> several historical reasons:
>
> 1. Huawei produced dozens of broadband card types in past years
On Thu, 2015-06-25 at 17:19 +0200, Enrico Mioso wrote:
> Hi Oliver! And thank you again.
>
> I like / recommend the usage of open messaging standards: my preferred XMPP ID
> (JID) is: mrk...@jit.si.
>
> On Thu, 25 Jun 2015, Oliver Neukum wrote:
>
> > Date: Thu, 25 Jun 2015 15:38:46
> > From: Oli
* Vadim Kochan [15.06.2015 18:36]:
> > root@box:~ ip route list exact '0.0.0.0/8'
> > root@box:~ echo $?
> > 0
> >
> > i expected an RC of != 0 when there is no match.
> > is this by design?
> >
> > root@box:~ ip -V
> > ip utility, iproute2-ss4.0.0-1-openwrt
>
> I think that RC != 0 only in cas
On Thu, 2015-06-25 at 19:59 -0500, Scott Wood wrote:
> On Fri, 2015-06-26 at 01:06 +0200, Paul Bolle wrote:
> > (Evolution 3.16 is basically unbearable for replying to patches.
> > Anyone
> > else running into this?)
You replied with Evolution v3.16, didn't you? Look how it wrapped that
line. No
93 matches
Mail list logo