On 22 August 2018 at 05:24, David Miller wrote:
> From: Jian-Hong Pan
>> [ 56.462464] r8169 :02:00.0: MSI-X entry: context resume:
>>
> ...
>> uh! The MSI-X entry seems missed after resume on this laptop!
>
> Yeah, having all of the MSI-X entry values
On Tue, Aug 21, 2018 at 4:38 PM David Miller wrote:
>
> From: Pravin Shelar
> Date: Tue, 21 Aug 2018 15:38:28 -0700
>
> > On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote:
> >>
> >> Function queue_userspace_packet() defined in net/openvswitch/datapath.c
> >> calls nla_nest_start() to allocate
On 22.08.2018 06:24, David Miller wrote:
> From: Jian-Hong Pan
> Date: Wed, 22 Aug 2018 11:01:02 +0800
>
> ...
>> [ 56.462464] r8169 :02:00.0: MSI-X entry: context resume:
>>
> ...
>> uh! The MSI-X entry seems missed after resume on this laptop!
>
> Y
From: Jian-Hong Pan
Date: Wed, 22 Aug 2018 11:01:02 +0800
...
> [ 56.462464] r8169 :02:00.0: MSI-X entry: context resume:
>
...
> uh! The MSI-X entry seems missed after resume on this laptop!
Yeah, having all of the MSI-X entry values be all-1's is no
2018-08-22 5:19 GMT+08:00 Heiner Kallweit :
> On 20.08.2018 05:47, Jian-Hong Pan wrote:
>> 2018-08-20 4:34 GMT+08:00 Heiner Kallweit :
>>> The three of you reported an MSI-X-related error when the system
>>> resumes from suspend. This has been fixed for now by disabling MSI-X
>>> on certain chip ve
On Tue, Aug 21, 2018 at 04:59:52PM -0700, Jason A. Donenfeld wrote:
> On Tue, Aug 21, 2018 at 4:54 PM David Miller wrote:
> >
> > From: "Jason A. Donenfeld"
> > Date: Tue, 21 Aug 2018 16:41:50 -0700
> >
> > > Is 100 in fact acceptable for new code? 120? 180? What's the
> > > generally accepted l
On Mon, Aug 20, 2018 at 1:52 PM, Alexei Starovoitov
wrote:
> On Thu, Aug 16, 2018 at 09:44:20AM -0700, Petar Penkov wrote:
>> From: Petar Penkov
>>
>> This patch series hardens the RX stack by allowing flow dissection in BPF,
>> as previously discussed [1]. Because of the rigorous checks of the B
On Tue, Aug 21, 2018 at 3:02 PM, Daniel Borkmann wrote:
> Currently, it is possible to create a sock hash map with key size
> of 0 and have the kernel return a fd back to user space. This is
> invalid for hash maps (and kernel also hasn't been tested for zero
> key size support in general at this
On Tue, Aug 21, 2018 at 4:54 PM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Tue, 21 Aug 2018 16:41:50 -0700
>
> > Is 100 in fact acceptable for new code? 120? 180? What's the
> > generally accepted limit these days?
>
> Please keep it as close to 80 columns as possible.
>
> Line b
From: "Jason A. Donenfeld"
Date: Tue, 21 Aug 2018 16:41:50 -0700
> Is 100 in fact acceptable for new code? 120? 180? What's the
> generally accepted limit these days?
Please keep it as close to 80 columns as possible.
Line breaks are not ugly, please embrace them :)
On Tue, Jul 31, 2018 at 1:22 PM Stephen Hemminger
wrote:
>
> On Tue, 31 Jul 2018 21:11:02 +0200
> "Jason A. Donenfeld" wrote:
>
> > +static int walk_by_peer(struct allowedips_node __rcu *top, u8 bits, struct
> > allowedips_cursor *cursor, struct wireguard_peer *peer, int (*func)(void
> > *ctx,
From: Pravin Shelar
Date: Tue, 21 Aug 2018 15:38:28 -0700
> On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote:
>>
>> Function queue_userspace_packet() defined in net/openvswitch/datapath.c
>> calls nla_nest_start() to allocate memory for struct nlattr which is
>> dereferenced immediately. As n
From: Heiner Kallweit
Date: Tue, 21 Aug 2018 23:19:04 +0200
> That's what I get on my system (RTL8168E-VL). In your case you'll come
> only till the first suspend.
>
> [3.743404] r8169 :03:00.0: MSI-X entry: context probe: fee01004 0
> 40ef 1
On probe, MSI-X is masked (ie. disabled) an
On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote:
>
> Function queue_userspace_packet() defined in net/openvswitch/datapath.c calls
> nla_nest_start() to allocate memory for struct nlattr which is dereferenced
> immediately. As nla_nest_start() may return NULL on failure, this code piece
> may
Currently, it is possible to create a sock hash map with key size
of 0 and have the kernel return a fd back to user space. This is
invalid for hash maps (and kernel also hasn't been tested for zero
key size support in general at this point). Thus, reject such
configuration.
Fixes: 81110384441a ("b
On 21 August 2018 at 22:19, Heiner Kallweit wrote:
> Below is a patch printing the MSI-X table entry in different contexts,
> it's not supposed to fix anything. Could you please let me know
> what the output is on your system?
> I want to get an idea whether the issue clears the complete entry or
On 20.08.2018 05:47, Jian-Hong Pan wrote:
> 2018-08-20 4:34 GMT+08:00 Heiner Kallweit :
>> The three of you reported an MSI-X-related error when the system
>> resumes from suspend. This has been fixed for now by disabling MSI-X
>> on certain chip versions. However more versions may be affected.
>>
On 08/20/2018 10:31 AM, Björn Töpel wrote:
> Den mån 20 aug. 2018 kl 02:58 skrev Prashant Bhole
> :
>>
>> s/ENOTSUPP/EOPNOTSUPP/ in function umem_assign_dev().
>> This function's return value is directly returned by xsk_bind().
>> EOPNOTSUPP is bind()'s possible return value.
>>
>> Fixes: f734607e8
From: Cong Wang
Date: Sun, 19 Aug 2018 12:22:04 -0700
> This patchset aims to clean up and fixes some bugs in current
> merge window, this is why it is targeting -net.
>
> Patch 1-5 are clean up Vlad's patches merged in current merge
> window, patch 6 is just a trivial cleanup.
>
> Patch 7 reve
From: Cong Wang
Date: Mon, 20 Aug 2018 16:57:46 -0700
> Passing 'exists' as 'atomic' is prior to my change. With my change,
> they are separated as two parameters:
I mis-read the patch, thanks for explaining :)
From: Stephen Hemminger
Date: Tue, 21 Aug 2018 10:40:38 -0700
> Registering another device with same MAC address (such as TAP, VPN or
> DPDK KNI) will confuse the VF autobinding logic. Restrict the search
> to only run if the device is known to be a PCI attached VF.
>
> Fixes: e8ff40d4bff1 ("hv
From: Mahesh Bandewar
These are primarily fixes for "string is not string literal" warnings
/ errors (with -Werror -Wformat-nonliteral). This should be a no-op
change. I had to replace couple of print helper functions with the
code they call as it was becoming harder to eliminate these warnings,
On Tue, Aug 21, 2018 at 11:19 AM, Stephen Hemminger
wrote:
> On Tue, 21 Aug 2018 10:48:54 -0700
> Mahesh Bandewar wrote:
>
>> From: Mahesh Bandewar
>>
>> Signed-off-by: Mahesh Bandewar
>
> I already did this yesterday. Patch was on mailing list.
Hmm, I thought I did mention that I would take ca
Begin forwarded message:
Date: Tue, 21 Aug 2018 18:37:01 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 200879] New: Poor network performance using CX-5 Mellanox card
https://bugzilla.kernel.org/show_bug.cgi?id=200879
Bug ID: 200879
On Tue, 21 Aug 2018 10:48:54 -0700
Mahesh Bandewar wrote:
> From: Mahesh Bandewar
>
> Signed-off-by: Mahesh Bandewar
I already did this yesterday. Patch was on mailing list.
On Tue, Aug 21, 2018 at 9:59 AM Nikita V. Shirokov wrote:
>
> On Tue, Aug 21, 2018 at 08:58:15AM -0700, Alexander Duyck wrote:
> > On Mon, Aug 20, 2018 at 12:32 PM Nikita V. Shirokov
> > wrote:
> > >
> > > we are getting such errors:
> > >
> > > [ 408.737313] ixgbe :03:00.0 eth0: Detected T
On 20 August 2018 at 04:47, Jian-Hong Pan wrote:
> There is no "MSIX address lost, re-configuring" in dmesg.
> The ethernet interface is still down after resume.
Sorry, only just seen this thread. I can confirm Jian-Jong's report --
this patch doesn't help (applied to 4.18.3); no message is outp
From: Mahesh Bandewar
The primary theme is to make clang compile the iproute2 package without
warnings. Along with this there are two other misc patches in the series.
First patch uses the preferred_family when operating with maddr feature.
Prior to this patch, it would always open an AF_INET so
From: Mahesh Bandewar
Signed-off-by: Mahesh Bandewar
---
tc/m_ematch.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tc/m_ematch.h b/tc/m_ematch.h
index f634f19164fa..80b02cfad6cc 100644
--- a/tc/m_ematch.h
+++ b/tc/m_ematch.h
@@ -20,7 +20,7 @@ struct bstr
From: Mahesh Bandewar
When creating socket() AF_INET is used irrespective of the family
that is given at the command-line (with -4, -6, or -0). This change
will open the socket with the preferred family.
Signed-off-by: Mahesh Bandewar
---
ip/ipmaddr.c | 13 -
1 file changed, 12 ins
Registering another device with same MAC address (such as TAP, VPN or
DPDK KNI) will confuse the VF autobinding logic. Restrict the search
to only run if the device is known to be a PCI attached VF.
Fixes: e8ff40d4bff1 ("hv_netvsc: improve VF device matching")
Signed-off-by: Stephen Hemminger
--
On Tue, Aug 21, 2018 at 08:58:15AM -0700, Alexander Duyck wrote:
> On Mon, Aug 20, 2018 at 12:32 PM Nikita V. Shirokov
> wrote:
> >
> > we are getting such errors:
> >
> > [ 408.737313] ixgbe :03:00.0 eth0: Detected Tx Unit Hang (XDP)
> > Tx Queue <46>
> >
On 8/21/2018 7:05 AM, Yue Haibing wrote:
Remove duplicated include.
Signed-off-by: Yue Haibing
---
Looks fine.
Acked-by : Santosh Shilimkar
On Mon, Aug 20, 2018 at 5:52 PM, Stephen Hemminger
wrote:
> On Mon, 20 Aug 2018 16:44:28 -0700
> Mahesh Bandewar (महेश बंडेवार) wrote:
>
>> On Mon, Aug 20, 2018 at 4:38 PM, Mahesh Bandewar (महेश बंडेवार)
>> wrote:
>> > On Mon, Aug 20, 2018 at 3:52 PM, Stephen Hemminger
>> > wrote:
>> >> On Mon,
On Mon, Aug 20, 2018 at 12:32 PM Nikita V. Shirokov wrote:
>
> we are getting such errors:
>
> [ 408.737313] ixgbe :03:00.0 eth0: Detected Tx Unit Hang (XDP)
> Tx Queue <46>
> TDH, TDT <0>, <2>
> next_to_use <
commit 739de9a1563a ("net: macb: Reorganize macb_mii bringup") broke
initializing macb on the EVB-KSZ9477 eval board.
There, of_mdiobus_register was called even for the fixed-link representing
the RGMII-link to the switch with the result that the driver attempts to
enumerate PHYs on a non-existent
commit 739de9a1563a ("net: macb: Reorganize macb_mii bringup") broke
initializing macb on the EVB-KSZ9477 eval board.
The board's SoC has a macb MAC connected to the KSZ9477 over RGMII, this
is represented as a fixed-link as follows in the (non-mainline) device tree:
macb0: ethernet@f0028
On 08/21/2018 03:34 PM, Andrew Lunn wrote:
> I don't see where this is happening. It is looking for a gpio called
> 'link-gpios'.
First while registering the MDIO bus in __mdiobus_register:
gpiod = devm_gpiod_get_optional(&bus->dev, "reset", GPIOD_OUT_LOW);
and then again when registerin
On (08/21/18 14:05), Yue Haibing wrote:
> Remove duplicated include.
>
> Signed-off-by: Yue Haibing
Acked-by: Sowmini Varadhan
Remove duplicated include.
Signed-off-by: Yue Haibing
---
net/rds/tcp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 2c7b7c3..b9bbcf3 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
Remove including that don't need it.
Signed-off-by: Yue Haibing
---
net/sched/sch_cake.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index 35fc725..4d26b08 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -64,7 +64,6 @@
#include
On 17.08.2018 21:09, Samudrala, Sridhar wrote:
> On 8/17/2018 2:56 AM, Harald Hoyer wrote:
>> On 17.08.2018 11:51, Harald Hoyer wrote:
>>> On 16.08.2018 00:17, Siwei Liu wrote:
On Wed, Aug 15, 2018 at 12:05 PM, Samudrala, Sridhar
wrote:
> On 8/14/2018 5:03 PM, Siwei Liu wrote:
>>
From: Larry Finger
> Sent: 20 August 2018 18:51
> When strncpy() is called with source and destination strings the same
> length, gcc 8 warns that there may be an unterminated string. Using
> strlcpy() rather than strncpy() forces a null at the end and quiets the
> warning.
>
> Signed-off-by: Larr
> I've traced it some more: While mdiobus_register fails to find a PHY,
> creation of the "MDIO" bus is still successful and it returns successfully,
> having claimed the reset GPIO.
>
> of_phy_fixed_link_register tries to claim the same GPIO and fails.
I don't see where this is happening. It is
On Thu, 9 Aug 2018 20:08:32 +0800
Jisheng Zhang wrote:
> On Thu, 9 Aug 2018 19:27:55 +0800 Jisheng Zhang wrote:
>
> > Hi,
> >
> > On Thu, 9 Aug 2018 12:40:41 +0800 Jisheng Zhang wrote:
> >
> > > + more people
> > >
> > > On Wed, 8 Aug 2018 17:27:05 +0200 Marek Behún wrote:
> > >
> > >
On 08/20/2018 09:06 PM, Andrew Lunn wrote:
> I would actually say, this is your real issue here. The warnings are
> annoying, but i don't think they are fatal. This -EBUSY is what is
> stopping the driver from loading, causing the real regression.
My real issue is that a specific commit broke the
46 matches
Mail list logo
