2nd batch:
0001-r8169-decouple-the-counters-data-and-the-device-priv.patch
0002-r8169-use-a-single-condition-to-check-the-completion.patch
0003-r8169-increase-the-lifespan-of-the-hardware-counters.patch
- the noise is still present
--
To unsubscribe from this list: send the line "unsubscribe netde
On 9/5/15, 2:53 AM, Ben Hutchings wrote:
On Thu, 2015-06-25 at 03:28 +0200, Robert Urban wrote:
Hello,
there doesn't seem to be any flag to request ethtool to present its output in a
script-friendly form. Things like:
Link partner advertised link modes: 10baseT/Half 10baseT/Full
On 9/6/15, 1:46 PM, Roopa Prabhu wrote:
From: Roopa Prabhu
Problem:
The ecmp route replace support for ipv6 in the kernel, deletes the
existing ecmp route too early, ie when it installs the first nexthop.
If there is an error in installing the subsequent nexthops, its too late
to recover the al
On 9/7/15, 5:37 AM, Nicolas Dichtel wrote:
Le 06/09/2015 22:46, Roopa Prabhu a écrit :
From: Roopa Prabhu
I've sent you some comments about the v2, so please keep me in CC for
the next
versions.
Problem:
The ecmp route replace support for ipv6 in the kernel, deletes the
existing ecmp route
Francois Romieu :
[...]
> Updated patch is on the way.
Fixed memcpy in patch 0001, moved counters allocation from open()
to probe(), returned open() to its original state but something is
still wrong: the link does not come up.
Patches attached.
I'll try again tomorrow.
--
Ueimor
>From 8f1b8
On 9/7/15, 5:03 AM, Nicolas Dichtel wrote:
The bug you're trying to fix has been introduced by the commit
51ebd3181572
("ipv6: add support of equal cost multipath (ECMP)").
Commit 27596472473a ("ipv6: fix ECMP route replacement") didn't try to
fix this
problem.
The reason I say "27596472473a (
From: Corinna Vinschen
Date: Mon, 7 Sep 2015 11:29:49 +0200
> Still wondering though. Given that the driver never failed before if
> the counter values couldn't be updated, and given that these counter
> values only have statistical relevance, why should this suddenly result
> in a fatal failure
Corinna Vinschen :
[...]
> I have a bit of a problem with this patch. It crashes when loading the
> driver manually w/ modprobe. For some reason dev_get_stats is called
> during rtl_init_one and at that time the counters pointer is NULL, so
> the kernel gets a SEGV.
>
> After I worked around th
Hi Sergei,
On Tue, 2015-09-08 at 00:24 +0300, Sergei Shtylyov wrote:
> On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
>
> > Current implementation via IS_ERR(phydev) may make no sense because
> > of_phy_attach() returns NULL on failure instead of error value.
>
> Not of_phy_connect()?
I alre
On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
Current implementation via IS_ERR(phydev) may make no sense because
of_phy_attach() returns NULL on failure instead of error value.
Not of_phy_connect()?
Still for checking result of phy_connect() IS_ERR() is useful.
To address both situation
On 09/07/2015 01:16 AM, Jesper Dangaard Brouer wrote:
On Fri, 4 Sep 2015 11:09:21 -0700
Alexander Duyck wrote:
This is an interesting start. However I feel like it might work better
if you were to create a per-cpu pool for skbs that could be freed and
allocated in NAPI context. So for exampl
On Mon, 7 Sep 2015 13:22:13 -0700
Linus Torvalds wrote:
> On Mon, Sep 7, 2015 at 2:30 AM, Jesper Dangaard Brouer
> wrote:
> >
> > The slub allocator have a faster "fastpath", if your workload is
> > fast-reusing within the same per-cpu page-slab, but once the workload
> > increases you hit the s
Hi Sergei,
On Mon, 2015-09-07 at 23:53 +0300, Sergei Shtylyov wrote:
> On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
>
> > Current implementation via IS_ERR(phydev) may make no sense because
> > of_phy_attach() returns NULL on failure instead of error value.
> >
> > Still for checking result of
On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
Current implementation via IS_ERR(phydev) may make no sense because
of_phy_attach() returns NULL on failure instead of error value.
Still for checking result of phy_connect() IS_ERR() is useful.
To address both situations we use combined IS_ERR_OR_
Current implementation via IS_ERR(phydev) may make no sense because
of_phy_attach() returns NULL on failure instead of error value.
Still for checking result of phy_connect() IS_ERR() is useful.
To address both situations we use combined IS_ERR_OR_NULL() check.
Cc: Giuseppe Cavallaro
Cc: linux-
On Mon, Sep 7, 2015 at 2:30 AM, Jesper Dangaard Brouer
wrote:
>
> The slub allocator have a faster "fastpath", if your workload is
> fast-reusing within the same per-cpu page-slab, but once the workload
> increases you hit the slowpath, and then slab catches up. Slub looks
> great in micro-benchma
On Mon, 7 Sep 2015 09:25:49 -0700 Tom Herbert wrote:
> >> What not pass a list of skbs (e.g. using skb->next)?
> >
> > Because the next layer, the slab API needs an array:
> > kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p)
> >
>
> I suppose we could ask the same question of
Excerpts from Stephen Hemminger's message of 2015-09-07 11:09:32 -0700:
> Agreed with Jiri. I prefer the new shorter brief format, not longer format.
As long as it requires extra typing, few are going to use it.
It's about the default.
Did you try the brief format with a few v6 addresses on an
in
Hello.
On 09/07/2015 09:15 PM, Alexey Brodkin wrote:
Current implementation via IS_ERR(phydev) may make no sense because
of_phy_attach() returns NULL on failure instead of error value.
Still for checking result of phy_connect() IS_ERR() is useful.
So adding explicit check for NULL.
Cc:
Current implementation via IS_ERR(phydev) may make no sense because
of_phy_attach() returns NULL on failure instead of error value.
Still for checking result of phy_connect() IS_ERR() is useful.
So adding explicit check for NULL.
Cc: Giuseppe Cavallaro
Cc: arc-linux-...@synopsys.com
Cc: linux-k
On Sat, 5 Sep 2015 10:40:50 +0300
Denis Kirjanov wrote:
> Before:
> kda@vfirst ~/devel/iproute2 $ ./ip/ip route flush cache
> Cannot open "/proc/sys/net/ipv4/route/flush"
>
> After:
> kda@vfirst ~/devel/iproute2/ip $ ./ip route flush cache
> Cannot open "/proc/sys/net/ipv4/route/flush": Permiss
On Mon, 7 Sep 2015 17:54:11 +0200
Jiri Benc wrote:
> On Mon, 07 Sep 2015 17:38:48 +0200, Felix Kaiser wrote:
> > My opinion is that if someone parses that, they deserve the opportunity
> > to fix their code. At the very least they could have used -oneline!
>
> No doubt. I also don't like scripts
Begin forwarded message:
Date: Mon, 7 Sep 2015 13:31:54 +
From: "bugzilla-dae...@bugzilla.kernel.org"
To: "shemmin...@linux-foundation.org"
Subject: [Bug 104161] New: DLNA services disappear on bridge device shortly
after starting the dlna service
https://bugzilla.kernel.org/show_bug.c
You might need to rebase you patch. A patch to netback went it recently.
On Mon, Sep 07, 2015 at 04:33:56PM +0100, Julien Grall wrote:
> The PV network protocol is using 4KB page granularity. The goal of this
> patch is to allow a Linux using 64KB page granularity working as a
> network backend on
>> What not pass a list of skbs (e.g. using skb->next)?
>
> Because the next layer, the slab API needs an array:
> kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p)
>
I suppose we could ask the same question of that function. IMO
encouraging drivers to define arrays of pointers o
On Mon, 07 Sep 2015 17:38:48 +0200, Felix Kaiser wrote:
> My opinion is that if someone parses that, they deserve the opportunity
> to fix their code. At the very least they could have used -oneline!
No doubt. I also don't like scripts that parse the default "ip a"
output.
I just pointed out that
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the gran
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on
Excerpts from Jiri Benc's message of 2015-09-07 14:46:09 +0200:
> Or makes the readability worse by requiring more scrolling, depending
> on number of interfaces you have and your taste.
Of course it's slightly subjective, but I think it improves readability
quite a bit *especially* on servers wit
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
Acked-by: Wei Liu
---
Cc: Ian Campbell
Cc: netdev@vger.kernel.org
Changes in v4:
- Add Wei's acked
Changes in v2:
- Pat
req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing
Signed-off-by: Dominique Martinet
---
net/9p/trans_fd.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
Feel free to adapt error code/message if you can think of something better.
diff --git a/net/
On 08/17/2015 11:02 PM, David Miller wrote:
...
I would seriously rather see us do an expensive full copy of the SKB
than to have traffic which is unexpectedly invisible to taps.
I've been looking into this issue a bit further, so the copy for the
tap seems doable, but while further going throu
On Sep 6 12:37, Corinna Vinschen wrote:
> On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> > From: Francois Romieu
> >
> > net/core/net-sysfs.c::netstat_show retrieves stats with spinlock held.
> >
> > This change avoids sleepable allocation and performs some housekeeping:
> > - receive ring, tra
On 07.09.2015 10:50, Corinna Vinschen wrote:
> On Sep 7 09:13, poma wrote:
>> On 06.09.2015 12:19, Corinna Vinschen wrote:
>>> On Sep 4 22:59, Francois Romieu wrote:
Applies against davem's net as of
f1ccbfce2fc787981d1182d09c1f6b67766783a8.
drivers/net/ethernet/realtek/r81
I thought the nature of trans_fd would have prevented any sort of true
zero copy, but I suppose one less is always welcome :)
-eric
On Sun, Sep 6, 2015 at 1:55 AM, Dominique Martinet
wrote:
> Eric Van Hensbergen wrote on Sat, Sep 05, 2015:
>> On Thu, Sep 3, 2015 at 4:38 AM, Dominique Ma
From: Colin Ian King
The check for send_pkt being NULL is redundant before the call
to htc_reclaim_txctrl_buf, therefore it should be removed. This was
detected by static analysis by cppcheck.
Signed-off-by: Colin Ian King
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 +---
1 file changed
On Wednesday 02 September 2015 13:16:19 H. Peter Anvin wrote:
> On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote:
> >
> > Should all other architectures follow suit?
> > Or should we follow the s390 approach:
> >
>
> It is up to the maintainer(s), largely dependent on how likely you are
> going
On Sun, 6 Sep 2015 13:01:09 +0200, Felix Kaiser wrote:
> This improves the readability of the output.
Or makes the readability worse by requiring more scrolling, depending
on number of interfaces you have and your taste. Many users prefer the
current format.
Also, as sad as it is, there are scri
Le 06/09/2015 22:46, Roopa Prabhu a écrit :
From: Roopa Prabhu
I've sent you some comments about the v2, so please keep me in CC for the next
versions.
Problem:
The ecmp route replace support for ipv6 in the kernel, deletes the
existing ecmp route too early, ie when it installs the first nex
Incorporate fw_ldst_cmd structure change for new firmware and also
update version string for the same
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 33 +--
drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h | 12 -
2 files cha
+ Michal Kubecek
Le 06/09/2015 22:46, roopa a écrit :
On 9/4/15, 1:12 AM, Nicolas Dichtel wrote:
Le 03/09/2015 01:44, Roopa Prabhu a écrit :
[snip]
Fixes: 4a287eba2de3 ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL
flags support, warn about missing CREATE flag")
ECMP was added one ye
From: Rustad, Mark D
...
> >> static int smp_ah(struct crypto_blkcipher *tfm, const u8 irk[16],
> >> const u8 r[3], u8 res[3])
> >
> > Expect that it looks like you are passing arrays by value,
> > but instead you are passing by reference.
> >
> > Explicitly pass by reference and s
On Fri, Sep 04, 2015 at 01:21:06PM +0800, Herbert Xu wrote:
> On Mon, Aug 31, 2015 at 03:35:26PM +0800, Herbert Xu wrote:
> >
> > I see where the bug came from. Indeed IPv6 does do fragmentation
> > but only for tunnel mode. While your patch added a check that also
> > affected transport mode.
In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So
On Thu, 3 Sep 2015 20:51:09 -0700 Linus Torvalds
wrote:
> On Thu, Sep 3, 2015 at 8:26 PM, Dave Chinner wrote:
> >
> > The double standard is the problem here. No notification, proof,
> > discussion or review was needed to turn on slab merging for
> > everyone, but you're setting a very high ba
On Sep 6 22:21, Francois Romieu wrote:
> Corinna Vinschen :
> > On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> [...]
> > > - rtl_reset_counters_cond induced failures in open() are also considered
> > > fatal: it takes acceptable work to unwind comfortably.
> >
> > Why?
>
>
> Crap, my descrip
If an attempt to wake up users of broadcast link is made when there is
no enough place in send queue than it may hang up inside the
tipc_sk_rcv() function since the loop breaks only after the wake up
queue becomes empty. This can lead to complete CPU stall with the
following message generated by RC
On Sep 7 09:13, poma wrote:
> On 06.09.2015 12:19, Corinna Vinschen wrote:
> > On Sep 4 22:59, Francois Romieu wrote:
> >> Applies against davem's net as of
> >> f1ccbfce2fc787981d1182d09c1f6b67766783a8.
> >>
> >> drivers/net/ethernet/realtek/r8169.c | 2 +-
> >> 1 file changed, 1 insertion(+)
On Fri, 4 Sep 2015 11:47:17 -0700 Tom Herbert wrote:
> On Fri, Sep 4, 2015 at 10:00 AM, Jesper Dangaard Brouer
> wrote:
> > Introduce the first user of SLAB bulk free API kmem_cache_free_bulk(),
> > in the network stack in form of function kfree_skb_bulk() which bulk
> > free SKBs (not skb clon
On Fri, 4 Sep 2015 11:09:21 -0700
Alexander Duyck wrote:
> This is an interesting start. However I feel like it might work better
> if you were to create a per-cpu pool for skbs that could be freed and
> allocated in NAPI context. So for example we already have
> napi_alloc_skb, why not just
On 06.09.2015 12:19, Corinna Vinschen wrote:
> On Sep 4 22:59, Francois Romieu wrote:
>> net/core/net-sysfs.c::netstat_show fetches statistics under dev_base_lock.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104031
>> Fixes: 6e85d5ad36a2 ("r8169: Add values missing in @get_stats64
From: Francois Romieu
Date: Sun, 6 Sep 2015 22:21:53 +0200
> Corinna Vinschen :
>> On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> [...]
>> > - rtl_reset_counters_cond induced failures in open() are also considered
>> > fatal: it takes acceptable work to unwind comfortably.
>>
>> Why?
>
>
>
52 matches
Mail list logo
