* Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-05 3:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori
In-Reply-To: <20161004131032.GL11677@lunn.ch>
On Tuesday 04 October 2016 06:40 PM, Andrew Lunn wrote:
>> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
>> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
>> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
>
> Did you really test this? Or did you make the same typos in your device
> tree file?
>
I have tested this and attached the log in cover letter. Since there is
a typo error on both dts and driver it worked as expected. Will send a
v3 ASAP.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support,Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: Doug Ledford @ 2016-10-05 3:09 UTC (permalink / raw)
To: David Miller
Cc: Yuval.Mintz, netdev, linux-rdma, Ram.Amrani, Michal.Kalderon,
Ariel.Elior
In-Reply-To: <20161004.195945.1239283105752882824.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]
On 10/4/2016 7:59 PM, David Miller wrote:
> From: Doug Ledford <dledford@redhat.com>
> Date: Tue, 4 Oct 2016 08:04:20 -0400
>
>> Are you going to merge this in 4.9 or is this going into net-next?
>
> 4.9, it will go into the pull request I send to Linus later today.
>
Got it, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: A bug in team driver
From: Eric Dumazet @ 2016-10-05 3:08 UTC (permalink / raw)
To: Alex Sidorenko; +Cc: netdev
In-Reply-To: <3444639.ILgt5kU9OR@zbook>
On Tue, 2016-10-04 at 18:30 -0400, Alex Sidorenko wrote:
> The problem was found on RHEL7.2 but is still present in the latest
> upstream kernel (according to visual sources inspection).
>
> While using roundrobin runner we have noticed that after sending on
> team0 about 2.1 billion packets we started seeing 50% packet drop on
> team0
> (according to 'netstat -i'). This number suggested 'signed int'
> overflow and indeed, inspecting the sources I have noticed the
> following in
>
> drivers/net/team/team_mode_roundrobin.c
> ---------------------------------------
> struct rr_priv {
> unsigned int sent_packets; <--------- unsigned
> int
> };
>
> static struct rr_priv *rr_priv(struct team *team)
> {
> return (struct rr_priv *) &team->mode_priv;
> }
>
> static bool rr_transmit(struct team *team, struct sk_buff *skb)
> {
> struct team_port *port;
> int port_index;
>
> port_index = team_num_to_port_index(team,
> rr_priv(team)->sent_packets++);
> ---
>
>
> we have 'unsigned int sent_packets' but we call team_num_to_port_index
> where 'num' is 'int'
>
> include/linux/if_team.h
> -----------------------
> static inline int team_num_to_port_index(struct team *team, int num)
> <-- signed int
> {
> int en_port_count = ACCESS_ONCE(team->en_port_count);
>
> if (unlikely(!en_port_count))
> return 0;
> return num % en_port_count;
> }
>
>
> As soon as sent_packets becomes larger than MAXINT (=2**31-1),
> team_num_to_port_index() can return negative number as num becomes
> negative and remainder
> (num % en_port_count) is either 0 or negative. This leads to looking
> up incorrect hash-bucket and dropping packets.
>
> We have easily duplicated this in roundrobin mode with two ports.
> After reaching 2**31 packets sent on team0 every second packet was
> dropped.
>
> Rebuilding the kernel after changing
>
> team_num_to_port_index(struct team *team, int num) ->
> team_num_to_port_index(struct team *team, unsigned int num)
>
> and running the test again does not show packet drop anymore.
>
> The same subroutine is used in
> team_mode_loadbalance.c:lb_hash_select_tx_port but we pass 'unsigned
> char hash' to team_num_to_port_index(), so there should be no
> overflow. I did not test that mode in my tests.
Good catch ! Can you send an official patch to fix this ?
Thanks.
>
^ permalink raw reply
* Re: [1/3] bpf powerpc: introduce accessors for using the tmp local stack space
From: Michael Ellerman @ 2016-10-05 2:36 UTC (permalink / raw)
To: Naveen N. Rao, linux-kernel, linuxppc-dev, netdev
Cc: Ananth N Mavinakayanahalli, David S. Miller, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <40b65ab2bb3a48837ab047a70887de3ccd70c56b.1474661927.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, 2016-23-09 at 20:35:00 UTC, "Naveen N. Rao" wrote:
> While at it, ensure that the location of the local save area is
> consistent whether or not we setup our own stackframe. This property is
> utilised in the next patch that adds support for tail calls.
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7b847f523fe07b4ad73a01cec49a4d
cheers
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers
From: Pravin Shelar @ 2016-10-05 2:03 UTC (permalink / raw)
To: Jiri Benc; +Cc: Linux Kernel Network Developers, David Ahern
In-Reply-To: <20161004185920.229e62de@griffin>
On Tue, Oct 4, 2016 at 9:59 AM, Jiri Benc <jbenc@redhat.com> wrote:
> On Tue, 4 Oct 2016 09:53:25 -0700, Pravin Shelar wrote:
>> This code can be executed on encapsulated geneve or vxlan packets.
>
> How? The encapsulation header is in the form of metadata_dst at this
> point and not present in the packet itself. Am I missing something?
>
We could have encapsulated packet defragmented in physical bridge.
that mean the packet is entering OVS after egressing tunnel device.
That use case would break due to this patch.
> If this patch is wrong, then the current push_mpls is wrong, too, it
> does the same assumption.
>
I am not sure what you mean, can you explain?
^ permalink raw reply
* Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel?
From: Liping Zhang @ 2016-10-05 0:58 UTC (permalink / raw)
To: Justin Piszcz; +Cc: linux-kernel, Linux Kernel Network Developers
In-Reply-To: <CAO9zADwLwLLvxmqiLzxK9A5+--ZnvewMzmUvQ4xdm8HHeFNOsA@mail.gmail.com>
Hi Justin,
2016-10-05 6:02 GMT+08:00 Justin Piszcz <jpiszcz@lucidpixels.com>:
> Hello,
>
> kernel 4.8 with ulogd-2.0.5- IPs are no longer logged:
>
> Oct 4 17:51:30 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
> TTL=0 ID=0 PROTO=0 MARK=0
> Oct 4 17:51:31 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
> TTL=0 ID=0 PROTO=0 MARK=0
> Oct 4 17:51:32 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
> TTL=0 ID=0 PROTO=0 MARK=0
>
> (reboot back to kernel 4.7, works fine)
>
> kernel 4.7 with ulogd-2.0.5:
> Oct 4 17:56:44 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
> DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58093 PROTO=TCP
> SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
> URGP=0 MARK=0
> Oct 4 17:56:45 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
> DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58725 PROTO=TCP
> SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
> URGP=0 MARK=0
>
> Looks like there were some changes in the 4.8 kernel regarding ulogd,
> has anyone else run into this problem?
>
> } ulog;
> + if ((li->u.ulog.flags & NF_LOG_F_COPY_LEN) &&
> + (li->u.ulog.copy_len < data_len))
> + data_len = li->u.ulog.copy_len;
> li->u.ulog.group = ntohs(nla_get_be16(tb[NFTA_LOG_GROUP]));
> + li->u.ulog.flags |= NF_LOG_F_COPY_LEN;
> li->u.ulog.copy_len =
> if (nla_put_be16(skb, NFTA_LOG_GROUP, htons(li->u.ulog.group)))
> - if (li->u.ulog.copy_len) {
> + if (li->u.ulog.flags & NF_LOG_F_COPY_LEN) {
> htonl(li->u.ulog.copy_len)))
> li.u.ulog.group = info->group;
> li.u.ulog.qthreshold = info->threshold;
> + li.u.ulog.flags |= NF_LOG_F_COPY_LEN;
>
> Thanks,
>
> Justin.
Which one are you using? iptables or nftables?
Could you please paste the related iptables/nftables rules here?
^ permalink raw reply
* Re: [PATCH] netdevice: add netdev_pub helper function
From: Jason A. Donenfeld @ 2016-10-05 0:52 UTC (permalink / raw)
To: David S. Miller, Netdev, LKML
In-Reply-To: <1434115829-22804-1-git-send-email-Jason@zx2c4.com>
Hey David,
The use of this function is going from the private member to the
public netdev struct. The usage is desired from the following coding
pattern.
You're implementing a netdevice. You've got ndo_init, ndo_uninit,
ndo_open, ndo_stop, ndo_start_xmit, and maybe even ndo_do_ioctl. All
of these functions basically follow the flow: get some information out
of struct netdev, then call netdev_priv(), and pass that specific
pointer onto the rest of the driver. The rest of the driver, 99% of
the time, only deals with your private member. Very very occasionally
it might want to check into how some piece of public data is doing.
For example, is the interface up? In this case, it's very convenient
to have the netdev_pub function, as in this patch.
if (netdev_pub(priv)->flags & IFF_UP) {
...
}
Then, after shortly using the public members, the driver gets on its
way dealing again exclusively with the private part.
I posted this patch a year ago, and let it languish after your initial
comment, because I wasn't confident that this was necessarily
something everybody could benefit from. 18 months later, after reading
quite a few netdevice-based drivers, it seems like this is indeed a
very useful code pattern, that makes things a bit more clear, a bit
less verbose, and helps maintain type safety throughout a driver.
So, I resubmit this to you for inclusion.
Regards,
Jason
On Fri, Jun 12, 2015 at 3:30 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Being able to utilize this makes much code a lot simpler and cleaner.
> It's a nice convenience function.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> include/linux/netdevice.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 05b9a69..f85be18 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1871,6 +1871,17 @@ static inline void *netdev_priv(const struct net_device *dev)
> return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN);
> }
>
> +/**
> + * netdev_pub - access network device from private pointer
> + * @priv: private data pointer of network device
> + *
> + * Get network device from a network device private data pointer
> + */
> +static inline struct net_device *netdev_pub(void *priv)
> +{
> + return (struct net_device *)((char *)priv - ALIGN(sizeof(struct net_device), NETDEV_ALIGN));
> +}
> +
> /* Set the sysfs physical device reference for the network logical device
> * if set prior to registration will cause a symlink during initialization.
> */
> --
> 2.4.2
>
^ permalink raw reply
* Re: Assertion faileda at samples/bpf/test_maps
From: William Tu @ 2016-10-05 0:48 UTC (permalink / raw)
To: Louie Lu; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAEQ0BR4j65Upa_ZLo6yC1khOprvXx1_iVxCKuSxbn+Df1mo_OQ@mail.gmail.com>
Hi Louie,
Can you check whether your num_possible_cpu == num_online_cpu?
by doing:
cat /sys/devices/system/cpu/possible
and see how many cpu[0-9]
ls /sys/devices/system/cpu/cpu*
There is a related discussion here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg121258.html
Regards,
William
On Sun, Oct 2, 2016 at 3:55 PM, Louie Lu <louie.lu@hopebaytech.com> wrote:
> Hi everyone,
>
> I'm now playing net-next samples/bpf things, and I found that
> test_maps will give an assertion
>
> ```
> test_maps: /home/grd/linux/net-next/samples/bpf/test_maps.c:146:
> test_percpu_hashmap_sanity: Assertion `bpf_lookup_elem(map_fd, &key,
> value) == -1 && errno == ENOENT' failed.
> [1] 20706 abort (core dumped) ./test_maps
> ```
>
> I've done the check at [[iovisor-dev] Assertion fails at
> samples/bpf/test_maps](http://lists.iovisor.org/pipermail/iovisor-dev/2016-June/000281.html)
> which tells me to set ulimit to unlimited or patching by setrlimit().
>
> The problem is bpf_lookup_elem return -1, and errno return 0.
>
> I'm using Intel(R) Core(TM) i7-2640M and net-next commit:
> 803783849fed11, 4.8.0-rc7-ARCH-02283-g8037838.
>
> And, a strange this is when I done this at QEMU, test_maps perform
> will and pass the test.
>
> Is that my hardware problem or something else?
>
>
> Thanks.
>
> Louie Lu.
^ permalink raw reply
* Re: [patch net 0/2] mlxsw: Couple of fixes
From: David Miller @ 2016-10-05 0:29 UTC (permalink / raw)
To: jiri; +Cc: netdev, yotamg, idosch, eladr, nogahf, ogerlitz
In-Reply-To: <1475567165-3362-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 4 Oct 2016 09:46:03 +0200
> Couple of fixes from Yotam.
Series applied, thanks.
Note that needed_headroom is a request, rather than a guarantee, so you
may in some rare cases need to realloc your headroom if the kernel was
not able to meet your request.
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-10-04
From: David Miller @ 2016-10-05 0:25 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475567338-28291-1-git-send-email-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 4 Oct 2016 09:31:28 +0200
> Here's a version with the conflicts resolved - had to jigger some
> code around, but it's all described in the merge commit message.
>
> Let me know if there's any problem.
Pulled, thanks for resolving this.
^ permalink raw reply
* Re: [PATCH net-next 0/7] rxrpc: More fixes and adjustments
From: David Miller @ 2016-10-05 0:10 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <10083.1475596890@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Tue, 04 Oct 2016 17:01:30 +0100
> What's the procedure for sending more fixes at this point? Do I send them
> against net-next, since net doesn't contain the things to be fixed yet, or do
> I wait for net to catch up?
I'm sending Linus a pull request later today for the stuff in net-next,
and once he takes that all the trees will be synced up and you can start
sending fixes.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] openvswitch: remove nonreachable code in vlan parsing
From: Eric Garver @ 2016-10-05 0:06 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, pravin shelar
In-Reply-To: <cfc3e476bc30c1e15506e80955bf43563de3c16c.1475583870.git.jbenc@redhat.com>
Hi Jiri,
On Tue, Oct 04, 2016 at 02:30:01PM +0200, Jiri Benc wrote:
> It can never happen that there's a vlan tag in the packet but not in
> skb->vlan_tci. This is ensured in __netif_receive_skb_core and honored by
> skb_vlan_push and skb_vlan_pop. The code dealing with such case is a dead
> code.
>
This code is also called for packets passed back down from userspace
(after the flow key miss and upcall). So it does happen that we have a
skb without skb->vlan_tci set.
See the chain:
ovs_packet_cmd_execute()
ovs_flow_key_extract_userspace()
key_extract()
parse_vlan()
> Moreover, the likely() statement around skb_vlan_tag_present is bogus. This
> code is called whenever flow key is being extracted from the packet. The
> packet may be as likely vlan tagged as not.
>
I guess the unlikely scenario is the one I mention above.
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support,Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: David Miller @ 2016-10-04 23:59 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: Yuval.Mintz-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Ram.Amrani-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
Michal.Kalderon-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
Ariel.Elior-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8
In-Reply-To: <ad89ec53-2355-e466-0ceb-92da51cc2a62-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Tue, 4 Oct 2016 08:04:20 -0400
> Are you going to merge this in 4.9 or is this going into net-next?
4.9, it will go into the pull request I send to Linus later today.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* A bug in team driver
From: Alex Sidorenko @ 2016-10-04 22:30 UTC (permalink / raw)
To: netdev
The problem was found on RHEL7.2 but is still present in the latest upstream kernel (according to visual sources inspection).
While using roundrobin runner we have noticed that after sending on team0 about 2.1 billion packets we started seeing 50% packet drop on team0
(according to 'netstat -i'). This number suggested 'signed int' overflow and indeed, inspecting the sources I have noticed the following in
drivers/net/team/team_mode_roundrobin.c
---------------------------------------
struct rr_priv {
unsigned int sent_packets; <--------- unsigned int
};
static struct rr_priv *rr_priv(struct team *team)
{
return (struct rr_priv *) &team->mode_priv;
}
static bool rr_transmit(struct team *team, struct sk_buff *skb)
{
struct team_port *port;
int port_index;
port_index = team_num_to_port_index(team,
rr_priv(team)->sent_packets++);
---
we have 'unsigned int sent_packets' but we call team_num_to_port_index where 'num' is 'int'
include/linux/if_team.h
-----------------------
static inline int team_num_to_port_index(struct team *team, int num) <-- signed int
{
int en_port_count = ACCESS_ONCE(team->en_port_count);
if (unlikely(!en_port_count))
return 0;
return num % en_port_count;
}
As soon as sent_packets becomes larger than MAXINT (=2**31-1), team_num_to_port_index() can return negative number as num becomes negative and remainder
(num % en_port_count) is either 0 or negative. This leads to looking up incorrect hash-bucket and dropping packets.
We have easily duplicated this in roundrobin mode with two ports. After reaching 2**31 packets sent on team0 every second packet was dropped.
Rebuilding the kernel after changing
team_num_to_port_index(struct team *team, int num) -> team_num_to_port_index(struct team *team, unsigned int num)
and running the test again does not show packet drop anymore.
The same subroutine is used in team_mode_loadbalance.c:lb_hash_select_tx_port but we pass 'unsigned char hash' to team_num_to_port_index(), so there should be no overflow. I did not test that mode in my tests.
Regards,
Alex
--
------------------------------------------------------------------
Alex Sidorenko email: asid@hpe.com
ERT Linux Hewlett-Packard Enterprise (Canada)
------------------------------------------------------------------
^ permalink raw reply
* kernel v4.8: iptables logs are truncated with the 4.8 kernel?
From: Justin Piszcz @ 2016-10-04 22:02 UTC (permalink / raw)
To: linux-kernel, netdev
Hello,
kernel 4.8 with ulogd-2.0.5- IPs are no longer logged:
Oct 4 17:51:30 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0
Oct 4 17:51:31 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0
Oct 4 17:51:32 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0
(reboot back to kernel 4.7, works fine)
kernel 4.7 with ulogd-2.0.5:
Oct 4 17:56:44 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58093 PROTO=TCP
SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
URGP=0 MARK=0
Oct 4 17:56:45 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58725 PROTO=TCP
SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
URGP=0 MARK=0
Looks like there were some changes in the 4.8 kernel regarding ulogd,
has anyone else run into this problem?
} ulog;
+ if ((li->u.ulog.flags & NF_LOG_F_COPY_LEN) &&
+ (li->u.ulog.copy_len < data_len))
+ data_len = li->u.ulog.copy_len;
li->u.ulog.group = ntohs(nla_get_be16(tb[NFTA_LOG_GROUP]));
+ li->u.ulog.flags |= NF_LOG_F_COPY_LEN;
li->u.ulog.copy_len =
if (nla_put_be16(skb, NFTA_LOG_GROUP, htons(li->u.ulog.group)))
- if (li->u.ulog.copy_len) {
+ if (li->u.ulog.flags & NF_LOG_F_COPY_LEN) {
htonl(li->u.ulog.copy_len)))
li.u.ulog.group = info->group;
li.u.ulog.qthreshold = info->threshold;
+ li.u.ulog.flags |= NF_LOG_F_COPY_LEN;
Thanks,
Justin.
^ permalink raw reply
* [PATCH v3] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-10-04 20:37 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <87vax8p9is.fsf@kamboji.qca.qualcomm.com>
Register the WLAN device as a wakeup source since it can
wake the system via wake-on-wireless-lan. In an actual wowlan
event, notify the PM core that we are the current wakeup source.
This allows the PM core to update the wakeup attributes in /sys.
This was causing wakeup issues on chromeos as the system was
apparently confused about the wakeup source.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
---
v3: Fix the commit log
v2: Fix the commit log
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [ISSUE: mv88e6xxx]: Down/Up link and not forwarding
From: Andrew Lunn @ 2016-10-04 20:28 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Jose Antonio Delgado Alfonso, netdev, Vivien Didelot
In-Reply-To: <19A0FE92-E4DB-49EB-AF4C-30A73DFED7E9@gmail.com>
> >The main difference is GLOBAL2 5th register. When the unit is just
> >initialized, the driver sets this register to 00ff, however, when
> >the issue happens, its value is c12f.
You might want to hack the MDIO driver and get it to trap writes to
this register and give you a call stack.
Andrew
^ permalink raw reply
* RE: [PATCH] igb: Realign bad indentation
From: Brown, Aaron F @ 2016-10-04 19:32 UTC (permalink / raw)
To: Joe Perches, Kirsher, Jeffrey T
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ef9cc22163546101c34fbade622455422549f43c.1474947967.git.joe@perches.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Joe Perches
> Sent: Monday, September 26, 2016 8:46 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH] igb: Realign bad indentation
>
> Statements should start on tabstops.
>
> Use a single statement and test instead of multiple tests.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/ethernet/intel/igb/e1000_mac.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: [ISSUE: mv88e6xxx]: Down/Up link and not forwarding
From: Florian Fainelli @ 2016-10-04 18:58 UTC (permalink / raw)
To: Jose Antonio Delgado Alfonso, netdev, Andrew Lunn, Vivien Didelot
In-Reply-To: <40e73820-6e67-5cde-b492-bfbcba64caeb@aoifes.com>
On October 4, 2016 8:37:13 AM PDT, Jose Antonio Delgado Alfonso <jose.delgado@aoifes.com> wrote:
>We are working in an ARMv7 embedded system running kernel 4.1 but
>including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
>(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
>should not return a boolean."
>
>This is the schema of the system.
>
> +-------------------+ eth0
> | +--+
> | | |
> | Embedded system +--+
> | |
> | ARMv7 |
> | | Marvell 88E8057(sky2) +-------------+
>| +--+ +--+ +--+ eth1
>| | +---------------------+ | |
>+------+
> | +--+ CPU port +--+ mv88e6176 +--+
> +------+--+---------+ | |
>emulated| | | |
>GPIO +--+ +--+ +--+
>eth2
>MDIO +-----------------------------------+ | |
>+------+
> MDIO +--+ +--+
> +-------------+
>
>There is a bridge (br-lan) which includes eth0/eth1/eth2
Can you detail what eth0 and eth1 actually correspond to? The bridge layer denies adding DSA master network interfaces as bridge members as soon as they have tags enabled.
>
>>From time to time, We are seeing a link down and up of about 1s.
>Following the message that kernel sends.
>
>[ 312.769399] dsa dsa@0 eth2: Link is Down
>[ 312.773372] br-lan: port 3(eth2) entered disabled state
>[ 312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
>control disabled
>[ 312.963807] br-lan: port 3(eth2) entered forwarding state
>[ 312.969276] br-lan: port 3(eth2) entered forwarding state
>[ 313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
>rx/tx
>[ 314.966277] br-lan: port 3(eth2) entered forwarding state
>
>Moreover, under a reboot loop test which consists in booting the
>system,
>ping the unit and, if it responds, reboot again, we found that the
>bridge does not forward packages after many reboots.
>Looking into 88e6176 registers we saw the following
>
> GLOBAL GLOBAL2 0 1 2 3 4 5 6
> 0: c820 0 de0f 5d0f 500f 500f 500f 4e07 4007
> 1: 3 0 3e 3 3 3 3 3 3
> 2: 0 ffff 0 0 0 0 0 0 0
> 3: 0 ffff 1761 1761 1761 1761 1761 1761 1761
> 4: 6000 258 373f 433 430 433 433 433 433
> 5: 1000 c12f 0 0 0 0 0 0 0
> 6: c000 1f0f 101e 3005 3003 4001 5001 6001 7001
> 7: 0 707f 0 0 0 0 0 0 0
> 8: 0 7800 2480 2480 2480 2480 2480 2480 2480
> 9: 0 1600 1 1 1 1 1 1 1
> a: 148 0 0 0 0 0 0 0 0
> b: 6000 1000 1 2 4 8 10 20 40
> c: 0 22 0 0 0 0 0 0 0
> d: ffff 507 0 0 0 0 0 0 0
> e: ffff 36 0 0 0 0 0 0 0
> f: ffff f00 dada dada dada dada dada dada dada
>10: 0 0 0 0 0 0 0 0 0
>11: 0 0 0 0 0 0 0 0 0
>12: 5555 0 0 0 0 0 0 0 0
>13: 5555 0 34d 8b18 54d 0 0 0 0
>14: aaaa 400 0 0 0 0 0 0 0
>15: aaaa 0 0 0 0 0 0 0 0
>16: ffff 0 33 33 33 33 33 33 0
>17: ffff 0 0 0 0 0 0 0 0
>18: fa41 1884 3210 3210 3210 3210 3210 3210 3210
>19: 0 5e1 7654 7654 7654 7654 7654 7654 7654
>1a: 0 0 0 0 0 0 0 0 0
>1b: 1fc f869 8000 8000 8000 8000 8000 8000 8000
>1c: 0 4c00 0 0 0 0 0 0 0
>1d: 5ce0 0 0 0 0 0 0 0 0
>1e: 0 0 0 0 0 0 0 0 0
>1f: 0 0 0 0 0 0 0 0 0
>
>The main difference is GLOBAL2 5th register. When the unit is just
>initialized, the driver sets this register to 00ff, however, when the
>issue happens, its value is c12f.
>We got a patch which allows us to set registers values. If we change
>c12f to 00ff the ping works, otherwise, ping does not work. We do not
>know who is changing the register value. Apparently, driver does not.
>
>Weirderif possible, sometimes even global2 5th register is set to 00ff
>and bridge does not forward packages either. We have not sorted out
>which other register is affecting.
>
>Finally, The weirdest behaviour we are seeing is that the unit does not
>detect a link change, register 0 of ports 1 and 2 do not update their
>status.
>
>Have you experienced a similar issue in your side?
>
>Is it possible that those micro-outage could be the reason of bad
>settings in Global2 5th register?
>
>Have you fixed this issues in a newer Linux kernel version?
Can you try reproducing this with the latest net-next tree?
--
Florian
^ permalink raw reply
* ethtool 4.8 released
From: John W. Linville @ 2016-10-04 18:43 UTC (permalink / raw)
To: netdev
ethtool version 4.8 has been released.
Home page: https://www.kernel.org/pub/software/network/ethtool/
Download link:
https://www.kernel.org/pub/software/network/ethtool/ethtool-4.8.tar.xz
Release notes:
* Feature: QSFP Plus/QSFP28 Diagnostics Information Support
* Feature: Enhancing link mode bits to support 25G/50G/100G
* Feature: add support for 1000BaseX and missing 10G link mode
* Fixes: address Coverity issues 1363118 - 1363125
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers
From: Jiri Benc @ 2016-10-04 16:59 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Linux Kernel Network Developers, David Ahern
In-Reply-To: <CAOrHB_C55GM=AfYj43VJ-hPRZfwFxm_+8Ls2+7mck2Js1fy9-w@mail.gmail.com>
On Tue, 4 Oct 2016 09:53:25 -0700, Pravin Shelar wrote:
> This code can be executed on encapsulated geneve or vxlan packets.
How? The encapsulation header is in the form of metadata_dst at this
point and not present in the packet itself. Am I missing something?
If this patch is wrong, then the current push_mpls is wrong, too, it
does the same assumption.
Jiri
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers
From: Pravin Shelar @ 2016-10-04 16:53 UTC (permalink / raw)
To: Jiri Benc; +Cc: Linux Kernel Network Developers, David Ahern
In-Reply-To: <20161004112804.04f25140@griffin>
On Tue, Oct 4, 2016 at 2:28 AM, Jiri Benc <jbenc@redhat.com> wrote:
> On Tue, 4 Oct 2016 10:24:58 +0200, Jiri Benc wrote:
>> On Mon, 3 Oct 2016 11:04:46 -0700, Pravin Shelar wrote:
>> > This is not correct way to detect MPLS packet. inner_protocol can be
>> > set by any tunnel device for using tunnel offloads. So this would
>> > break the fragmentation for encapsulated packets.
>>
>> You're right, stupid me.
>
> Actually, too little caffeine in the morning. I actually did consider
> this and I believe my patch is correct. It doesn't matter what the
> encapsulation is, we want to fragment the *inner* packet. And this is
> exactly what this patch does.
>
> Besides, the only case is MPLS anyway. I'm not aware of any code path
> that could lead us to here, set inner protocol and not be MPLS. But
> even if it is, it should work, provided the encapsulation header is
> identical for all fragments and smaller than MAX_L2_LEN.
>
This code can be executed on encapsulated geneve or vxlan packets. So
in that case encapsulation header would not be same for all fragments.
^ permalink raw reply
* [PATCH][RESEND] dt-bindings: net: renesas-ravb: Add support for R8A7796 RAVB
From: Laurent Pinchart @ 2016-10-04 16:45 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc
Add a new compatible string for the R8A7796 (M3-W) RAVB.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
The patch has been posted to the linux-renesas-soc mailing list only, adding
the netdev mailing list to get it upstreamed.
diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index c8ac222eac67..b519503be51a 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -10,6 +10,7 @@ Required properties:
"renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC.
"renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
"renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
+ "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC.
"renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible interface.
"renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible interface.
@@ -33,7 +34,7 @@ Optional properties:
- interrupt-parent: the phandle for the interrupt controller that services
interrupts for this device.
- interrupt-names: A list of interrupt names.
- For the R8A7795 SoC this property is mandatory;
+ For the R8A779[56] SoCs this property is mandatory;
it should include one entry per channel, named "ch%u",
where %u is the channel number ranging from 0 to 24.
For other SoCs this property is optional; if present
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH net-next 0/7] rxrpc: More fixes and adjustments
From: David Howells @ 2016-10-04 16:01 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, netdev, linux-afs, linux-kernel
In-Reply-To: <20161003.020236.1905952240188445872.davem@davemloft.net>
Hi Dave,
What's the procedure for sending more fixes at this point? Do I send them
against net-next, since net doesn't contain the things to be fixed yet, or do
I wait for net to catch up?
David
^ permalink raw reply
* [ISSUE: mv88e6xxx]: Down/Up link and not forwarding
From: Jose Antonio Delgado Alfonso @ 2016-10-04 15:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <8e5e36d7-7618-2a4e-6aba-e65e41662d47@aoifes.com>
We are working in an ARMv7 embedded system running kernel 4.1 but
including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
should not return a boolean."
This is the schema of the system.
+-------------------+ eth0
| +--+
| | |
| Embedded system +--+
| |
| ARMv7 |
| | Marvell 88E8057(sky2) +-------------+
| +--+ +--+ +--+ eth1
| | +---------------------+ | | +------+
| +--+ CPU port +--+ mv88e6176 +--+
+------+--+---------+ | |
emulated| | | |
GPIO +--+ +--+ +--+ eth2
MDIO +-----------------------------------+ | | +------+
MDIO +--+ +--+
+-------------+
There is a bridge (br-lan) which includes eth0/eth1/eth2
>From time to time, We are seeing a link down and up of about 1s.
Following the message that kernel sends.
[ 312.769399] dsa dsa@0 eth2: Link is Down
[ 312.773372] br-lan: port 3(eth2) entered disabled state
[ 312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
control disabled
[ 312.963807] br-lan: port 3(eth2) entered forwarding state
[ 312.969276] br-lan: port 3(eth2) entered forwarding state
[ 313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
rx/tx
[ 314.966277] br-lan: port 3(eth2) entered forwarding state
Moreover, under a reboot loop test which consists in booting the system,
ping the unit and, if it responds, reboot again, we found that the
bridge does not forward packages after many reboots.
Looking into 88e6176 registers we saw the following
GLOBAL GLOBAL2 0 1 2 3 4 5 6
0: c820 0 de0f 5d0f 500f 500f 500f 4e07 4007
1: 3 0 3e 3 3 3 3 3 3
2: 0 ffff 0 0 0 0 0 0 0
3: 0 ffff 1761 1761 1761 1761 1761 1761 1761
4: 6000 258 373f 433 430 433 433 433 433
5: 1000 c12f 0 0 0 0 0 0 0
6: c000 1f0f 101e 3005 3003 4001 5001 6001 7001
7: 0 707f 0 0 0 0 0 0 0
8: 0 7800 2480 2480 2480 2480 2480 2480 2480
9: 0 1600 1 1 1 1 1 1 1
a: 148 0 0 0 0 0 0 0 0
b: 6000 1000 1 2 4 8 10 20 40
c: 0 22 0 0 0 0 0 0 0
d: ffff 507 0 0 0 0 0 0 0
e: ffff 36 0 0 0 0 0 0 0
f: ffff f00 dada dada dada dada dada dada dada
10: 0 0 0 0 0 0 0 0 0
11: 0 0 0 0 0 0 0 0 0
12: 5555 0 0 0 0 0 0 0 0
13: 5555 0 34d 8b18 54d 0 0 0 0
14: aaaa 400 0 0 0 0 0 0 0
15: aaaa 0 0 0 0 0 0 0 0
16: ffff 0 33 33 33 33 33 33 0
17: ffff 0 0 0 0 0 0 0 0
18: fa41 1884 3210 3210 3210 3210 3210 3210 3210
19: 0 5e1 7654 7654 7654 7654 7654 7654 7654
1a: 0 0 0 0 0 0 0 0 0
1b: 1fc f869 8000 8000 8000 8000 8000 8000 8000
1c: 0 4c00 0 0 0 0 0 0 0
1d: 5ce0 0 0 0 0 0 0 0 0
1e: 0 0 0 0 0 0 0 0 0
1f: 0 0 0 0 0 0 0 0 0
The main difference is GLOBAL2 5th register. When the unit is just
initialized, the driver sets this register to 00ff, however, when the
issue happens, its value is c12f.
We got a patch which allows us to set registers values. If we change
c12f to 00ff the ping works, otherwise, ping does not work. We do not
know who is changing the register value. Apparently, driver does not.
Weirderif possible, sometimes even global2 5th register is set to 00ff
and bridge does not forward packages either. We have not sorted out
which other register is affecting.
Finally, The weirdest behaviour we are seeing is that the unit does not
detect a link change, register 0 of ports 1 and 2 do not update their
status.
Have you experienced a similar issue in your side?
Is it possible that those micro-outage could be the reason of bad
settings in Global2 5th register?
Have you fixed this issues in a newer Linux kernel version?
Thanks in advance.
^ 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