* Re: [PATCH] net/9p: correct some comment errors in 9p file system code
From: David Miller @ 2018-05-10 12:22 UTC (permalink / raw)
To: sunlw.fnst; +Cc: viro, rdunlap, netdev
In-Reply-To: <20180508014938.28134-1-sunlw.fnst@cn.fujitsu.com>
From: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
Date: Tue, 8 May 2018 09:49:38 +0800
> There are follow comment errors:
> 1 The function name is wrong in p9_release_pages() comment.
> 2 The function name and variable name is wrong in p9_poll_workfn() comment.
> 3 There is no variable dm_mr and lkey in struct p9_trans_rdma.
> 4 The function name is wrong in rdma_create_trans() comment.
> 5 There is no variable initialized in struct virtio_chan.
> 6 The variable name is wrong in p9_virtio_zc_request() comment.
>
> Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Applied.
^ permalink raw reply
* Re: [PATCH net] tipc: eliminate KMSAN uninit-value in strcmp complaint
From: David Miller @ 2018-05-10 12:25 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, netdev, syzkaller-bugs, tipc-discussion
In-Reply-To: <1525787046-5661-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 8 May 2018 21:44:06 +0800
> When we get link properties through netlink interface with
> tipc_nl_node_get_link(), we don't validate TIPC_NLA_LINK_NAME
> attribute at all, instead we directly use it. As a consequence,
> KMSAN detected the TIPC_NLA_LINK_NAME attribute was an uninitialized
> value, and then posted the following complaint:
...
> To quiet the complaint, TIPC_NLA_LINK_NAME attribute has been
> validated in tipc_nl_node_get_link() before it's used.
>
> Reported-by: syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] alx: add disable_wol paramenter
From: Andrew Lunn @ 2018-05-10 12:34 UTC (permalink / raw)
To: AceLan Kao
Cc: David Miller, James Cliburn, Chris Snook, rakesh, netdev,
Linux-Kernel@Vger. Kernel. Org, Emily Chien
In-Reply-To: <CAFv23QkETCHYqpsp_1JR30A1F=x+xCCQQv2RM9VOg24qhQRMOQ@mail.gmail.com>
On Thu, May 10, 2018 at 01:58:24PM +0800, AceLan Kao wrote:
> Hi Andrew,
>
> We have some machines using Qualcomm Atheros Killer E2400 Gigabit
> Ethernet Controller,
> but none of them has the unintentional wake up issue.
> We're willing to fix it if we encountered the issue, but before we can
> do it, we need this feature is supported by the driver.
>
> Taking the feature has been removed for 5 years into account, I doubt
> if we still can reproduce this issue,
> but again, to verify this issue we need to add back this feature first.
> Set WoL disabled by default won't introduce any regression but give
> users and developers a chance to fix it.
The main problem here is the module parameter. That is not going to be
accepted.
Can you argue the cure is worse than the disease? Is WoL not working
considered by a lot of people as being a bug? Double wake up is also a
bug, but not many people care, it does not cause any data corruption,
etc. So can you argue overall we have a less buggy system, but still
buggy, if WoL is enabled?
If you can write a convincing Change Message arguing the case, a patch
simply re-enabling WoL might be accepted.
But you also need to take on the responsibility to help debug the
failed shutdowns in order to get to the bottom of this problem.
Andrew
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in 'mlxsw_core_bus_device_register()'
From: Dan Carpenter @ 2018-05-10 12:41 UTC (permalink / raw)
To: Christophe JAILLET
Cc: jiri, idosch, davem, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20180510112616.20508-1-christophe.jaillet@wanadoo.fr>
On Thu, May 10, 2018 at 01:26:16PM +0200, Christophe JAILLET wrote:
> Resources are not freed in the reverse order of the allocation.
> Labels are also mixed-up.
>
> Fix it and reorder code and labels in the error handling path of
> 'mlxsw_core_bus_device_register()'
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> Please review carefully. This patch is proposed because it triggers one of
> my coccinelle scripts. I'm not 100% sure if correct.
>
Looks correct.
The err = mlxsw_driver->resources_register(mlxsw_core); pointer is a
pointer to mlxsw_sp_resources_register(). That function doesn't clean
up after itself on failure. Ideally, you'd want a matching
mlxsw_driver->resources_unregister as well pointer instead of hard
coding devlink_resources_unregister().
The error handling would be easier to review if the gotos told you what
the did. Right now they're written in "come from" style so the tell you
what happened on the line before.
if (!foo)
goto allocating_foo_failed;
Hopefully if someone fixes mlxsw_sp_resources_register() they'll choose
better label names.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Tariq Toukan @ 2018-05-10 12:42 UTC (permalink / raw)
To: Christophe JAILLET, davem, tariqt
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180510070604.19635-1-christophe.jaillet@wanadoo.fr>
On 10/05/2018 10:06 AM, Christophe JAILLET wrote:
> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
> It then calls 'mlx4_en_free_resources()' which does the needed resources
> cleanup.
>
> So, doing some explicit kfree in the error handling path would lead to
> some double kfree.
>
> Simplify code to avoid such a case.
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> v1 -> v2 : rewrite the fix as explained by Tariq Toukan
> (this 2nd version may have been posted twice, once without the
> v2 tag. PLease ignore the first one)
> ---
>
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index e0adac4a9a19..9670b33fc9b1 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3324,12 +3324,11 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_ring[t]) {
> err = -ENOMEM;
> - goto err_free_tx;
> + goto out;
> }
> priv->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_cq[t]) {
> - kfree(priv->tx_ring[t]);
> err = -ENOMEM;
> goto out;
> }
> @@ -3582,11 +3581,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>
> return 0;
>
> -err_free_tx:
> - while (t--) {
> - kfree(priv->tx_ring[t]);
> - kfree(priv->tx_cq[t]);
> - }
> out:
> mlx4_en_destroy_netdev(dev);
> return err;
>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Thanks Christophe.
^ permalink raw reply
* [PATCH][next] net: aquantia: fix unsigned numvecs comparison with less than zero
From: Colin King @ 2018-05-10 12:52 UTC (permalink / raw)
To: David S . Miller, Igor Russkikh, Pavel Belous, Wei Yongjun,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The comparison of numvecs < 0 is always false because numvecs is a u32
and hence the error return from a failed call to pci_alloc_irq_vectores
is never detected. Fix this by using the signed int ret to handle the
error return and assign numvecs to err.
Detected by CoverityScan, CID#1468650 ("Unsigned compared against 0")
Fixes: a09bd81b5413 ("net: aquantia: Limit number of vectors to actually allocated irqs")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
index a50e08bb4748..750007513f9d 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
@@ -267,14 +267,13 @@ static int aq_pci_probe(struct pci_dev *pdev,
numvecs = min(numvecs, num_online_cpus());
/*enable interrupts */
#if !AQ_CFG_FORCE_LEGACY_INT
- numvecs = pci_alloc_irq_vectors(self->pdev, 1, numvecs,
- PCI_IRQ_MSIX | PCI_IRQ_MSI |
- PCI_IRQ_LEGACY);
+ err = pci_alloc_irq_vectors(self->pdev, 1, numvecs,
+ PCI_IRQ_MSIX | PCI_IRQ_MSI |
+ PCI_IRQ_LEGACY);
- if (numvecs < 0) {
- err = numvecs;
+ if (err < 0)
goto err_hwinit;
- }
+ numvecs = err;
#endif
self->irqvecs = numvecs;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS
From: Eric Dumazet @ 2018-05-10 13:02 UTC (permalink / raw)
To: gfree.wind, davem, daniel, jakub.kicinski, dsahern, netdev
In-Reply-To: <1525940884-21067-1-git-send-email-gfree.wind@vip.163.com>
On 05/10/2018 01:28 AM, gfree.wind@vip.163.com wrote:
> From: Gao Feng <gfree.wind@vip.163.com>
>
> The skb flow limit is implemented for each CPU independently. In the
> current codes, the function skb_flow_limit gets the softnet_data by
> this_cpu_ptr. But the target cpu of enqueue_to_backlog would be not
> the current cpu when enable RPS. As the result, the skb_flow_limit checks
> the stats of current CPU, while the skb is going to append the queue of
> another CPU. It isn't the expected behavior.
>
> Now pass the softnet_data as a param to softnet_data to make consistent.
>
Please add a correct Fixes: tag
By doing so, you will likely add a CC: tag to make sure the author of the code
will receive your email and give feed back.
Thanks !
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in \'mlxsw_core_bus_device_register()\'
From: Arkadi Sharshevsky @ 2018-05-10 13:08 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180510124138.6yerbsfcl3abqtmq@mwanda>
Hi Dan,
I will fix the error path. Regarding the goto label this is
the convention in the driver.
Thanks,
Arkadi
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in \'mlxsw_core_bus_device_register()\'
From: Dan Carpenter @ 2018-05-10 13:17 UTC (permalink / raw)
To: Arkadi Sharshevsky; +Cc: netdev@vger.kernel.org
In-Reply-To: <2c5caff2-5ece-d07b-4df9-47a9ff24a86f@mellanox.com>
On Thu, May 10, 2018 at 04:08:22PM +0300, Arkadi Sharshevsky wrote:
> Hi Dan,
>
> I will fix the error path. Regarding the goto label this is
> the convention in the driver.
There is no rule against learning from the past.
Or there might be... I don't know all the rules at Mellanox.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next v2] tcp: Add mark for TIMEWAIT sockets
From: Eric Dumazet @ 2018-05-10 13:27 UTC (permalink / raw)
To: Jon Maxwell, davem; +Cc: kuznet, yoshfuji, netdev, linux-kernel, jmaxwell
In-Reply-To: <20180510065351.22535-1-jmaxwell37@gmail.com>
On 05/09/2018 11:53 PM, Jon Maxwell wrote:
> This version has some suggestions by Eric Dumazet:
>
> - Use a local variable for the mark in IPv6 instead of ctl_sk to avoid SMP
> races.
> - Use the more elegant "IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark"
> statement.
> - Factorize code as sk_fullsock() check is not necessary.
>
> Aidan McGurn from Openwave Mobility systems reported the following bug:
>
> "Marked routing is broken on customer deployment. Its effects are large
> increase in Uplink retransmissions caused by the client never receiving
> the final ACK to their FINACK - this ACK misses the mark and routes out
> of the incorrect route."
>
> Currently marks are added to sk_buffs for replies when the "fwmark_reflect"
> sysctl is enabled. But not for TW sockets that had sk->sk_mark set via
> setsockopt(SO_MARK..).
>
> Fix this in IPv4/v6 by adding tw->tw_mark for TIME_WAIT sockets. Copy the the
> original sk->sk_mark in __inet_twsk_hashdance() to the new tw->tw_mark location.
> Then progate this so that the skb gets sent with the correct mark. Do the same
> for resets. Give the "fwmark_reflect" sysctl precedence over sk->sk_mark so that
> netfilter rules are still honored.
>
> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks Jon.
^ permalink raw reply
* [PATCH net-next] tls: Fix tls_device initialization
From: Boris Pismenny @ 2018-05-10 13:27 UTC (permalink / raw)
To: davem; +Cc: netdev, borisp, davejwatson
Add sg table initialization to fix a BUG_ON encountered when enabling
CONFIG_DEBUG_SG.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
---
net/tls/tls_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index ac45d62..a7a8f8e 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -604,6 +604,8 @@ int tls_set_device_offload(struct sock *sk, struct tls_context *ctx)
INIT_LIST_HEAD(&offload_ctx->records_list);
list_add_tail(&start_marker_record->list, &offload_ctx->records_list);
spin_lock_init(&offload_ctx->lock);
+ sg_init_table(offload_ctx->sg_tx_data,
+ ARRAY_SIZE(offload_ctx->sg_tx_data));
clean_acked_data_enable(inet_csk(sk), &tls_icsk_clean_acked);
ctx->push_pending_record = tls_device_push_pending_record;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] rocker: Postpone filtering of !added_by_user FDB
From: Petr Machata @ 2018-05-10 13:29 UTC (permalink / raw)
To: netdev; +Cc: jiri, davem, vivien.didelot
Breaking out of the switch in rocker_switchdev_event() still ends up
scheduling work, except an ill-defined one. This leads to an OOPS cited
below. Fix by postponing the check until rocker_switchdev_event_work().
[ 23.148476] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 23.148810] PGD 0 P4D 0
[ 23.148982] Oops: 0000 [#1] PREEMPT SMP PTI
[ 23.149190] Modules linked in: bridge stp llc iptable_nat nf_nat_ipv4 nf_nat e1000 rocker
[ 23.149768] CPU: 0 PID: 239 Comm: kworker/u2:4 Not tainted 4.17.0-rc3-net_next_queue-custom #6
[ 23.150298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
[ 23.150868] Workqueue: rocker rocker_switchdev_event_work [rocker]
[ 23.151258] RIP: 0010:ofdpa_port_fdb+0x7b/0x230 [rocker]
[ 23.151597] RSP: 0018:ffffc900004b3e18 EFLAGS: 00010246
[ 23.151952] RAX: 00000000fffbc68c RBX: 0000000000000000 RCX: 0000000000000000
[ 23.152363] RDX: 0000000000000010 RSI: ffff88003b4471e0 RDI: 00000000ffffffff
[ 23.152768] RBP: ffff88003b4471c0 R08: ffff88003b4471e0 R09: ffff88003b4471c0
[ 23.153141] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880036caf000
[ 23.153515] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88003bc00000
[ 23.153919] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 23.154444] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 23.154806] CR2: 0000000000000000 CR3: 0000000036eb6000 CR4: 00000000000006f0
[ 23.155194] Call Trace:
[ 23.155472] rocker_switchdev_event_work+0x9b/0xd0 [rocker]
[ 23.155850] ? __schedule+0x231/0x700
[ 23.156175] process_one_work+0x1cf/0x3e0
[ 23.156490] worker_thread+0x26/0x3d0
[ 23.156795] ? trace_event_raw_event_workqueue_execute_start+0x80/0x80
[ 23.157181] kthread+0x10e/0x130
[ 23.157485] ? kthread_create_worker_on_cpu+0x40/0x40
[ 23.157824] ret_from_fork+0x35/0x40
[ 23.158174] Code: 00 00 c1 e8 02 4c 8d 45 20 bf ff ff ff ff 83 e0 01 4c 89 65 20 88 45 14 48 8b 05 21 da 1f e2 4c 89 c6 4c 89 44 24 10 48 89 45 18 <41> 8b 45 00 89 45 28 41 0f b7 45 04 66 89 45 2c 0f b7 44 24 04
[ 23.159346] RIP: ofdpa_port_fdb+0x7b/0x230 [rocker] RSP: ffffc900004b3e18
[ 23.159742] CR2: 0000000000000000
[ 23.160088] ---[ end trace f9b16d4cb6df0629 ]---
Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
Suggested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/ethernet/rocker/rocker_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 152d694..e73e4fe 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2738,6 +2738,8 @@ static void rocker_switchdev_event_work(struct work_struct *work)
switch (switchdev_work->event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE:
fdb_info = &switchdev_work->fdb_info;
+ if (!fdb_info->added_by_user)
+ break;
err = rocker_world_port_fdb_add(rocker_port, fdb_info);
if (err) {
netdev_dbg(rocker_port->dev, "fdb add failed err=%d\n", err);
@@ -2747,6 +2749,8 @@ static void rocker_switchdev_event_work(struct work_struct *work)
break;
case SWITCHDEV_FDB_DEL_TO_DEVICE:
fdb_info = &switchdev_work->fdb_info;
+ if (!fdb_info->added_by_user)
+ break;
err = rocker_world_port_fdb_del(rocker_port, fdb_info);
if (err)
netdev_dbg(rocker_port->dev, "fdb add failed err=%d\n", err);
@@ -2783,8 +2787,6 @@ static int rocker_switchdev_event(struct notifier_block *unused,
switch (event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
case SWITCHDEV_FDB_DEL_TO_DEVICE:
- if (!fdb_info->added_by_user)
- break;
memcpy(&switchdev_work->fdb_info, ptr,
sizeof(switchdev_work->fdb_info));
switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
--
2.4.11
^ permalink raw reply related
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Yuval Shaia @ 2018-05-10 13:38 UTC (permalink / raw)
To: Christophe JAILLET
Cc: davem, tariqt, netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180510070226.19575-1-christophe.jaillet@wanadoo.fr>
On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
> It then calls 'mlx4_en_free_resources()' which does the needed resources
> cleanup.
>
> So, doing some explicit kfree in the error handling path would lead to
> some double kfree.
Patch make sense but what's bothering me is that mlx4_en_free_resources
loops on the entire array, assuming !priv->tx_ring[t] means entry is
allocated but the existing code does not assume that, see [1]. So i looked
to see where tx_ring array is zeroed and didn't find it.
Am i missing something here.
>
> Simplify code to avoid such a case.
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index e0adac4a9a19..9670b33fc9b1 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3324,12 +3324,11 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_ring[t]) {
> err = -ENOMEM;
> - goto err_free_tx;
> + goto out;
> }
> priv->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_cq[t]) {
> - kfree(priv->tx_ring[t]);
> err = -ENOMEM;
> goto out;
> }
> @@ -3582,11 +3581,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>
> return 0;
>
> -err_free_tx:
> - while (t--) {
[1]
> - kfree(priv->tx_ring[t]);
> - kfree(priv->tx_cq[t]);
> - }
> out:
> mlx4_en_destroy_netdev(dev);
> return err;
> --
> 2.17.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv6: remove min MTU check for tunnel destinations
From: Ashwanth Goli @ 2018-05-10 13:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, pabeni, dsahern, netdev-owner
In-Reply-To: <20180501.122223.1661453536072731491.davem@davemloft.net>
On 2018-05-01 21:52, David Miller wrote:
> From: Ashwanth Goli <ashwanth@codeaurora.org>
> Date: Mon, 30 Apr 2018 00:36:47 +0530
>
>> With 749439bfac "fix udpv6 sendmsg crash caused by too small MTU"
>> tunnel dst's that report a MTU less than IPV6_MIN_MTU are broken
>> even for packets that are smaller than IPV6_MIN_MTU.
>>
>> According to rfc2473#section-7.1
>>
>> if the original IPv6 packet is equal or smaller than the
>> IPv6 minimum link MTU, the tunnel entry-point node
>> encapsulates the original packet, and subsequently
>> fragments the resulting IPv6 tunnel packet into IPv6
>> fragments that do not exceed the Path MTU to the tunnel
>> exit-point.
>>
>> This patch drops the MTU check for tunnel destinations.
>>
>> Signed-off-by: Ashwanth Goli <ashwanth@codeaurora.org>
>
> RFC 2473 is generally about ipv6 tunnels....
>
>> - if (mtu < IPV6_MIN_MTU)
>> + if (!(rt->dst.flags & DST_XFRM_TUNNEL) && mtu < IPV6_MIN_MTU)
>> return -EINVAL;
>
> But the check you are adding is specifically checking only IPSEC
> tunnels.
>
> If what you say is true in your commit message, this test must
> more generally trigger for all ipv6 tunnel types, not just IPSEC
> ones.
>
> If IPSEC tunnels are being targetting in this patch intentionally,
> that needs to be explained in the commit message.
My intention is to fix the issue for IPSEC tunnels. Will resend by
changing the commit text.
^ permalink raw reply
* Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
From: Michal Vokáč @ 2018-05-10 13:49 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20180504133014.GB9666@lunn.ch>
On 4.5.2018 15:30, Andrew Lunn wrote:
>> I am out of ideas how to further debug this.
>> Any additional adivce will be much appreciated.
>
> I would suggest looking at the statistics counters. ethtool -S. Try
> it for both the slave interfaces, and the master interface. The master
> interfaces statistics should have both the host counters, and the
> switches counters. Do you see packets being sent but not received? Are
> there errors reported?
Thanks Andrew, now I am getting closer!
I briefly looked at the statistics some time ago but could not interpret
the numbers correctly. Now I went through the relevant source code and it
shed some light to it.
This is what I get from the numbers:
Slaves - switch counters: some packets received, none transmitted. No errors.
Slaves - DSA counters: some packets transmitted, none received. No error cntrs.
Master - switch counters: some packets transmitted, none received. No errors.
Master - host/fec counters: some packets transmitted, none received. No errors,
but IEEE_rx_drop counter shows frames are being dropped!
So this is most probably the issue. From the i.MX6 RM:
"Counter increments if a frame with invalid or missing SFD character is
detected and has been dropped. None of the other counters increments if
this counter increments."
At first I thought that this could be caused by the atheros header.
But the atheros header is inserted in the frame by the switch after the SA.
So it can not be the issue as the frame is discarded even before the DA and SA
is processed.
So both the CPU and the switch are trying to talk to each other but their
frames are not delivered. This still looks like RGMII configuration problem.
As it works with my old PHY driver I suspect the problem is at the switches
side somewhere in qca8k_set_pad_ctrl or qca8k_setup in the qca8k driver.
Any other ideas?
BR, Michal
^ permalink raw reply
* [PATCH] qed: fix spelling mistake: "taskelt" -> "tasklet"
From: Colin King @ 2018-05-10 14:03 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in DP_VERBOSE message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 70bc5634675c..9feed3b79cd4 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -680,7 +680,7 @@ static int qed_nic_stop(struct qed_dev *cdev)
tasklet_disable(p_hwfn->sp_dpc);
p_hwfn->b_sp_dpc_enabled = false;
DP_VERBOSE(cdev, NETIF_MSG_IFDOWN,
- "Disabled sp taskelt [hwfn %d] at %p\n",
+ "Disabled sp tasklet [hwfn %d] at %p\n",
i, p_hwfn->sp_dpc);
}
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Dan Carpenter @ 2018-05-10 14:18 UTC (permalink / raw)
To: Yuval Shaia
Cc: Christophe JAILLET, davem, tariqt, netdev, linux-rdma,
linux-kernel, kernel-janitors
In-Reply-To: <20180510133808.GA10943@lap1>
On Thu, May 10, 2018 at 04:38:08PM +0300, Yuval Shaia wrote:
> On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
> > If an error occurs, 'mlx4_en_destroy_netdev()' is called.
> > It then calls 'mlx4_en_free_resources()' which does the needed resources
> > cleanup.
> >
> > So, doing some explicit kfree in the error handling path would lead to
> > some double kfree.
>
> Patch make sense but what's bothering me is that mlx4_en_free_resources
> loops on the entire array, assuming !priv->tx_ring[t] means entry is
> allocated but the existing code does not assume that, see [1]. So i looked
> to see where tx_ring array is zeroed and didn't find it.
>
> Am i missing something here.
>
It's zeroed twice. alloc_etherdev_mqs() allocates zeroed memory and
then we do a memset(priv, 0, sizeof(struct mlx4_en_priv));
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: David Ahern @ 2018-05-10 14:20 UTC (permalink / raw)
To: Steve Wise, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <e94d0444-fcda-3a62-3b12-3b9e6ff23119@opengridcomputing.com>
On 5/10/18 8:19 AM, Steve Wise wrote:
>
> On 5/9/2018 11:08 PM, David Ahern wrote:
>> On 5/7/18 9:53 AM, Steve Wise wrote:
>>> @@ -152,7 +153,10 @@ int main(int argc, char **argv)
>>> pretty_output = true;
>>> break;
>>> case 'd':
>>> - show_details = true;
>>> + if (show_details)
>>> + show_driver_details = true;
>>> + else
>>> + show_details = true;
>>> break;
>>> case 'j':
>>> json_output = true;
>> The above change should be reflected in the man page.
>
> I did mention it in the man page:
>
> -d, --details
> Output detailed information. Adding a second -d includes
> driver-specific details.
>
> But I wasn't sure how to show it in the syntax. Maybe this?
>
> OPTIONS := { -V[ersion] | -d[etails] [-d[etails]] } -j[son] } -p[retty] }
I should have read the second patch before commenting. Didn't it have
first -d = details, a second -d = driver details? That should be fine.
>
>
>> Also, the set needs to be respun after I merged master where Stephen
>> brought in updates to the uapi files.
>
> Will do. Thanks for reviewing.
>
> Steve.
>
^ permalink raw reply
* Re: [PATCH net-next] rocker: Postpone filtering of !added_by_user FDB
From: Vivien Didelot @ 2018-05-10 14:21 UTC (permalink / raw)
To: Petr Machata, netdev; +Cc: jiri, davem
In-Reply-To: <6fbb39711485d7abbe7cdaa8042a222b9588a6b6.1525957759.git.petrm@mellanox.com>
Petr Machata <petrm@mellanox.com> writes:
> Breaking out of the switch in rocker_switchdev_event() still ends up
> scheduling work, except an ill-defined one. This leads to an OOPS cited
> below. Fix by postponing the check until rocker_switchdev_event_work().
>
> [ 23.148476] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> [ 23.148810] PGD 0 P4D 0
> [ 23.148982] Oops: 0000 [#1] PREEMPT SMP PTI
> [ 23.149190] Modules linked in: bridge stp llc iptable_nat nf_nat_ipv4 nf_nat e1000 rocker
> [ 23.149768] CPU: 0 PID: 239 Comm: kworker/u2:4 Not tainted 4.17.0-rc3-net_next_queue-custom #6
> [ 23.150298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
> [ 23.150868] Workqueue: rocker rocker_switchdev_event_work [rocker]
> [ 23.151258] RIP: 0010:ofdpa_port_fdb+0x7b/0x230 [rocker]
> [ 23.151597] RSP: 0018:ffffc900004b3e18 EFLAGS: 00010246
> [ 23.151952] RAX: 00000000fffbc68c RBX: 0000000000000000 RCX: 0000000000000000
> [ 23.152363] RDX: 0000000000000010 RSI: ffff88003b4471e0 RDI: 00000000ffffffff
> [ 23.152768] RBP: ffff88003b4471c0 R08: ffff88003b4471e0 R09: ffff88003b4471c0
> [ 23.153141] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880036caf000
> [ 23.153515] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88003bc00000
> [ 23.153919] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 23.154444] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 23.154806] CR2: 0000000000000000 CR3: 0000000036eb6000 CR4: 00000000000006f0
> [ 23.155194] Call Trace:
> [ 23.155472] rocker_switchdev_event_work+0x9b/0xd0 [rocker]
> [ 23.155850] ? __schedule+0x231/0x700
> [ 23.156175] process_one_work+0x1cf/0x3e0
> [ 23.156490] worker_thread+0x26/0x3d0
> [ 23.156795] ? trace_event_raw_event_workqueue_execute_start+0x80/0x80
> [ 23.157181] kthread+0x10e/0x130
> [ 23.157485] ? kthread_create_worker_on_cpu+0x40/0x40
> [ 23.157824] ret_from_fork+0x35/0x40
> [ 23.158174] Code: 00 00 c1 e8 02 4c 8d 45 20 bf ff ff ff ff 83 e0 01 4c 89 65 20 88 45 14 48 8b 05 21 da 1f e2 4c 89 c6 4c 89 44 24 10 48 89 45 18 <41> 8b 45 00 89 45 28 41 0f b7 45 04 66 89 45 2c 0f b7 44 24 04
> [ 23.159346] RIP: ofdpa_port_fdb+0x7b/0x230 [rocker] RSP: ffffc900004b3e18
> [ 23.159742] CR2: 0000000000000000
> [ 23.160088] ---[ end trace f9b16d4cb6df0629 ]---
>
> Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
> Suggested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [PATCHv2 1/1] net/mlx4_core: avoid resetting HCA when accessing an offline device
From: Tariq Toukan @ 2018-05-10 14:24 UTC (permalink / raw)
To: Zhu Yanjun, tariqt, netdev, linux-rdma
In-Reply-To: <1524058303-379-1-git-send-email-yanjun.zhu@oracle.com>
On 18/04/2018 4:31 PM, Zhu Yanjun wrote:
> While a faulty cable is used or HCA firmware error, HCA device will
> be offline. When the driver is accessing this offline device, the
> following call trace will pop out.
>
> "
> ...
> [<ffffffff816e4842>] dump_stack+0x63/0x81
> [<ffffffff816e459e>] panic+0xcc/0x21b
> [<ffffffffa03e5f8a>] mlx4_enter_error_state+0xba/0xf0 [mlx4_core]
> [<ffffffffa03e7298>] mlx4_cmd_reset_flow+0x38/0x60 [mlx4_core]
> [<ffffffffa03e7381>] mlx4_cmd_poll+0xc1/0x2e0 [mlx4_core]
> [<ffffffffa03e9f00>] __mlx4_cmd+0xb0/0x160 [mlx4_core]
> [<ffffffffa0406934>] mlx4_SENSE_PORT+0x54/0xd0 [mlx4_core]
> [<ffffffffa03f5f54>] mlx4_dev_cap+0x4a4/0xb50 [mlx4_core]
> ...
> "
> In the above call trace, the function mlx4_cmd_poll calls the function
> mlx4_cmd_post to access the HCA while HCA is offline. Then mlx4_cmd_post
> returns an error -EIO. Per -EIO, the function mlx4_cmd_poll calls
> mlx4_cmd_reset_flow to reset HCA. And the above call trace pops out.
>
> This is not reasonable. Since HCA device is offline when it is being
> accessed, it should not be reset again.
>
> In this patch, since HCA is offline, the function mlx4_cmd_post returns
> an error -EINVAL. Per -EINVAL, the function mlx4_cmd_poll directly returns
> instead of resetting HCA.
>
> CC: Srinivas Eeda <srinivas.eeda@oracle.com>
> CC: Junxiao Bi <junxiao.bi@oracle.com>
> Suggested-by: Håkon Bugge <haakon.bugge@oracle.com>
> Suggested-by: Tariq Toukan <tariqt@mellanox.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
> V1->V2: Follow Tariq's advice, avoid the disturbance from other returned errors.
> Since the returned values from the function mlx4_cmd_post are -EIO and -EINVAL,
> to -EIO, the HCA device should be reset. To -EINVAL, that means that the function
> mlx4_cmd_post is accessing an offline device. It is not necessary to reset HCA.
> Go to label out directly.
> ---
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Thanks Zhu.
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: Steve Wise @ 2018-05-10 14:19 UTC (permalink / raw)
To: David Ahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <06375fd7-f241-74ad-70ce-a670100bf060@gmail.com>
On 5/9/2018 11:08 PM, David Ahern wrote:
> On 5/7/18 9:53 AM, Steve Wise wrote:
>> @@ -152,7 +153,10 @@ int main(int argc, char **argv)
>> pretty_output = true;
>> break;
>> case 'd':
>> - show_details = true;
>> + if (show_details)
>> + show_driver_details = true;
>> + else
>> + show_details = true;
>> break;
>> case 'j':
>> json_output = true;
> The above change should be reflected in the man page.
I did mention it in the man page:
-d, --details
Output detailed information. Adding a second -d includes
driver-specific details.
But I wasn't sure how to show it in the syntax. Maybe this?
OPTIONS := { -V[ersion] | -d[etails] [-d[etails]] } -j[son] } -p[retty] }
> Also, the set needs to be respun after I merged master where Stephen
> brought in updates to the uapi files.
Will do. Thanks for reviewing.
Steve.
^ permalink raw reply
* Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
From: Andrew Lunn @ 2018-05-10 14:29 UTC (permalink / raw)
To: Michal Vokáč; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <5e8ecfed-c772-5668-4bac-1549143f599a@gmail.com>
> So both the CPU and the switch are trying to talk to each other but their
> frames are not delivered. This still looks like RGMII configuration problem.
Yes, i would say it is.
> As it works with my old PHY driver I suspect the problem is at the switches
> side somewhere in qca8k_set_pad_ctrl or qca8k_setup in the qca8k driver.
>
> Any other ideas?
I would probably add code to dump all the qca8k registers. Compare the
values for your working setup and your non-working setup. Hopefully
they are not too different, and you can quickly get to the bits which
matter.
Andrew
^ permalink raw reply
* Re: STMMAC driver with TSO enabled issue
From: Jose Abreu @ 2018-05-10 14:29 UTC (permalink / raw)
To: Bhadram Varka, Jose Abreu, netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <77c98a42-195f-b597-711d-8c2e8b55f266@synopsys.com>
Hi Bhadram,
On 10-05-2018 09:55, Jose Abreu wrote:
> ++net-dev
>
> Hi Bhadram,
>
> On 09-05-2018 12:03, Bhadram Varka wrote:
>> Hi,
>>
>> Thanks for responding.
>>
>> Tried below suggested way. Still observing the issue -
> It seems stmmac has a bug in the RX side when using TSO which is
> causing all the RX descriptors to be consumed. The stmmac_rx()
> function will need to be refactored. I will send a fix ASAP.
Are you using this patch [1] ? Because there is a problem with
the patch. By adding the previously removed call to
stmmac_init_rx_desc() TSO works okay in my setup.
[1] https://patchwork.ozlabs.org/patch/910224/
>
> Thanks and Best Regards,
> Jose Miguel Abreu
>
>> [root@alarm ~]# iperf3 -c 10.19.65.141
>> Connecting to host 10.19.65.141, port 5201
>> [ 5] local 10.19.65.210 port 57630 connected to 10.19.65.141
>> port 5201
>> [ 65.408268] stmmac_tso_xmit(): line = 2842
>> [ 65.412362] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66,
>> pay_len 0, mss 1448
>> [ 65.419224] skb->len 8754, skb->data_len 8688
>> [ 65.423672] stmmac_tso_xmit: curr=20 dirty=17 f=18, e=20,
>> f_p=00000000178e52e1, nfrags 1
>> [ 65.431747] TX descriptor ring:
>> [ 65.434881] 000 [0x82005000]: 0x0 0x0 0x0 0x0
>> [ 65.439230] 001 [0x82005010]: 0x0 0x0 0x0 0x0
>> [ 65.443578] 002 [0x82005020]: 0x0 0x0 0x0 0x0
>> [ 65.447927] 003 [0x82005030]: 0x0 0x0 0x0 0x0
>> [ 65.452275] 004 [0x82005040]: 0x0 0x0 0x0 0x0
>> [ 65.456622] 005 [0x82005050]: 0x0 0x0 0x0 0x0
>> [ 65.460970] 006 [0x82005060]: 0x0 0x0 0x0 0x0
>> [ 65.465316] 007 [0x82005070]: 0x0 0x0 0x0 0x0
>> [ 65.469664] 008 [0x82005080]: 0x0 0x0 0x0 0x0
>> [ 65.474010] 009 [0x82005090]: 0x0 0x0 0x0 0x0
>> [ 65.478357] 010 [0x820050a0]: 0x0 0x0 0x0 0x0
>> [ 65.482706] 011 [0x820050b0]: 0x0 0x0 0x0 0x0
>> [ 65.487053] 012 [0x820050c0]: 0x0 0x0 0x0 0x0
>> [ 65.491400] 013 [0x820050d0]: 0x0 0x0 0x0 0x0
>> [ 65.495746] 014 [0x820050e0]: 0x0 0x0 0x0 0x0
>> [ 65.500092] 015 [0x820050f0]: 0x0 0x0 0x0 0x0
>> [ 65.504438] 016 [0x82005100]: 0x0 0x0 0x0 0x0
>> [ 65.508784] 017 [0x82005110]: 0x0 0x0 0x5a8 0xc4000000
>> [ 65.513910] 018 [0x82005120]: 0xfb297000 0x0 0x42 0xa04421f0
>> [ 65.519557] 019 [0x82005130]: 0xfb298000 0x0 0x21f0 0x90000000
>> [ 65.525376] 020 [0x82005140]: 0x0 0x0 0x0 0x0
>> [ 65.529722] 021 [0x82005150]: 0x0 0x0 0x0 0x0
>> [ 65.534069] 022 [0x82005160]: 0x0 0x0 0x0 0x0
>> [ 65.538414] 023 [0x82005170]: 0x0 0x0 0x0 0x0
>> [ 65.542761] 024 [0x82005180]: 0x0 0x0 0x0 0x0
>> [ 65.547107] 025 [0x82005190]: 0x0 0x0 0x0 0x0
>> [ 65.551454] 026 [0x820051a0]: 0x0 0x0 0x0 0x0
>> [ 65.555802] 027 [0x820051b0]: 0x0 0x0 0x0 0x0
>> [ 65.560147] 028 [0x820051c0]: 0x0 0x0 0x0 0x0
>> [ 65.564493] 029 [0x820051d0]: 0x0 0x0 0x0 0x0
>> [ 65.568840] 030 [0x820051e0]: 0x0 0x0 0x0 0x0
>> [ 65.573187] 031 [0x820051f0]: 0x0 0x0 0x0 0x0
>> [ 65.577533] 032 [0x82005200]: 0x0 0x0 0x0 0x0
>> [ 65.581879] 033 [0x82005210]: 0x0 0x0 0x0 0x0
>> [ 65.586225] 034 [0x82005220]: 0x0 0x0 0x0 0x0
>> [ 65.590571] 035 [0x82005230]: 0x0 0x0 0x0 0x0
>> [ 65.594917] 036 [0x82005240]: 0x0 0x0 0x0 0x0
>> [ 65.599262] 037 [0x82005250]: 0x0 0x0 0x0 0x0
>> [ 65.603607] 038 [0x82005260]: 0x0 0x0 0x0 0x0
>> [ 65.607952] 039 [0x82005270]: 0x0 0x0 0x0 0x0
>> [ 65.612297] 040 [0x82005280]: 0x0 0x0 0x0 0x0
>> [ 65.616643] 041 [0x82005290]: 0x0 0x0 0x0 0x0
>> [ 65.620989] 042 [0x820052a0]: 0x0 0x0 0x0 0x0
>> [ 65.625336] 043 [0x820052b0]: 0x0 0x0 0x0 0x0
>> [ 65.629681] 044 [0x820052c0]: 0x0 0x0 0x0 0x0
>> [ 65.634027] 045 [0x820052d0]: 0x0 0x0 0x0 0x0
>> [ 65.638372] 046 [0x820052e0]: 0x0 0x0 0x0 0x0
>> [ 65.642718] 047 [0x820052f0]: 0x0 0x0 0x0 0x0
>> [ 65.647063] 048 [0x82005300]: 0x0 0x0 0x0 0x0
>> [ 65.651408] 049 [0x82005310]: 0x0 0x0 0x0 0x0
>> [ 65.655754] 050 [0x82005320]: 0x0 0x0 0x0 0x0
>> [ 65.660099] 051 [0x82005330]: 0x0 0x0 0x0 0x0
>> [ 65.664444] 052 [0x82005340]: 0x0 0x0 0x0 0x0
>> [ 65.668790] 053 [0x82005350]: 0x0 0x0 0x0 0x0
>> [ 65.673134] 054 [0x82005360]: 0x0 0x0 0x0 0x0
>> [ 65.677480] 055 [0x82005370]: 0x0 0x0 0x0 0x0
>> [ 65.681825] 056 [0x82005380]: 0x0 0x0 0x0 0x0
>> [ 65.686170] 057 [0x82005390]: 0x0 0x0 0x0 0x0
>> [ 65.690515] 058 [0x820053a0]: 0x0 0x0 0x0 0x0
>> [ 65.694861] 059 [0x820053b0]: 0x0 0x0 0x0 0x0
>> [ 65.699206] 060 [0x820053c0]: 0x0 0x0 0x0 0x0
>> [ 65.703552] 061 [0x820053d0]: 0x0 0x0 0x0 0x0
>> [ 65.707898] 062 [0x820053e0]: 0x0 0x0 0x0 0x0
>> [ 65.712243] 063 [0x820053f0]: 0x0 0x0 0x0 0x0
>> [ 65.716706] stmmac_tso_xmit(): line = 2842
>> [ 65.720802] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66,
>> pay_len 0, mss 1448
>> [ 65.727669] skb->len 4410, skb->data_len 4344
>> [ 65.732114] stmmac_tso_xmit: curr=22 dirty=19 f=20, e=22,
>> f_p=00000000b1247b41, nfrags 1
>> [ 65.740190] TX descriptor ring:
>> [ 65.743327] 000 [0x82005000]: 0x0 0x0 0x0 0x0
>> [ 65.747678] 001 [0x82005010]: 0x0 0x0 0x0 0x0
>> [ 65.752029] 002 [0x82005020]: 0x0 0x0 0x0 0x0
>> [ 65.756378] 003 [0x82005030]: 0x0 0x0 0x0 0x0
>> [ 65.760727] 004 [0x82005040]: 0x0 0x0 0x0 0x0
>> [ 65.765077] 005 [0x82005050]: 0x0 0x0 0x0 0x0
>> [ 65.769427] 006 [0x82005060]: 0x0 0x0 0x0 0x0
>> [ 65.773776] 007 [0x82005070]: 0x0 0x0 0x0 0x0
>> [ 65.778126] 008 [0x82005080]: 0x0 0x0 0x0 0x0
>> [ 65.782476] 009 [0x82005090]: 0x0 0x0 0x0 0x0
>> [ 65.786826] 010 [0x820050a0]: 0x0 0x0 0x0 0x0
>> [ 65.791176] 011 [0x820050b0]: 0x0 0x0 0x0 0x0
>> [ 65.795526] 012 [0x820050c0]: 0x0 0x0 0x0 0x0
>> [ 65.799875] 013 [0x820050d0]: 0x0 0x0 0x0 0x0
>> [ 65.804225] 014 [0x820050e0]: 0x0 0x0 0x0 0x0
>> [ 65.808575] 015 [0x820050f0]: 0x0 0x0 0x0 0x0
>> [ 65.812925] 016 [0x82005100]: 0x0 0x0 0x0 0x0
>> [ 65.817274] 017 [0x82005110]: 0x0 0x0 0x0 0x0
>> [ 65.821625] 018 [0x82005120]: 0x0 0x0 0x0 0x0
>> [ 65.825976] 019 [0x82005130]: 0xfb298000 0x0 0x21f0 0x90000000
>> [ 65.831800] 020 [0x82005140]: 0xfb2a1000 0x0 0x42 0xa04410f8
>> [ 65.837450] 021 [0x82005150]: 0xfb2a2000 0x0 0x10f8 0x90000000
>> [ 65.843273] 022 [0x82005160]: 0x0 0x0 0x0 0x0
>> [ 65.847622] 023 [0x82005170]: 0x0 0x0 0x0 0x0
>> [ 65.851971] 024 [0x82005180]: 0x0 0x0 0x0 0x0
>> [ 65.856319] 025 [0x82005190]: 0x0 0x0 0x0 0x0
>> [ 65.860670] 026 [0x820051a0]: 0x0 0x0 0x0 0x0
>> [ 65.865020] 027 [0x820051b0]: 0x0 0x0 0x0 0x0
>> [ 65.869369] 028 [0x820051c0]: 0x0 0x0 0x0 0x0
>> [ 65.873719] 029 [0x820051d0]: 0x0 0x0 0x0 0x0
>> [ 65.878068] 030 [0x820051e0]: 0x0 0x0 0x0 0x0
>> [ 65.882418] 031 [0x820051f0]: 0x0 0x0 0x0 0x0
>> [ 65.886767] 032 [0x82005200]: 0x0 0x0 0x0 0x0
>> [ 65.891118] 033 [0x82005210]: 0x0 0x0 0x0 0x0
>> [ 65.895467] 034 [0x82005220]: 0x0 0x0 0x0 0x0
>> [ 65.899816] 035 [0x82005230]: 0x0 0x0 0x0 0x0
>> [ 65.904165] 036 [0x82005240]: 0x0 0x0 0x0 0x0
>> [ 65.908515] 037 [0x82005250]: 0x0 0x0 0x0 0x0
>> [ 65.912865] 038 [0x82005260]: 0x0 0x0 0x0 0x0
>> [ 65.917215] 039 [0x82005270]: 0x0 0x0 0x0 0x0
>> [ 65.921564] 040 [0x82005280]: 0x0 0x0 0x0 0x0
>> [ 65.925915] 041 [0x82005290]: 0x0 0x0 0x0 0x0
>> [ 65.930264] 042 [0x820052a0]: 0x0 0x0 0x0 0x0
>> [ 65.934615] 043 [0x820052b0]: 0x0 0x0 0x0 0x0
>> [ 65.938964] 044 [0x820052c0]: 0x0 0x0 0x0 0x0
>> [ 65.943313] 045 [0x820052d0]: 0x0 0x0 0x0 0x0
>> [ 65.947664] 046 [0x820052e0]: 0x0 0x0 0x0 0x0
>> [ 65.952012] 047 [0x820052f0]: 0x0 0x0 0x0 0x0
>> [ 65.956363] 048 [0x82005300]: 0x0 0x0 0x0 0x0
>> [ 65.960712] 049 [0x82005310]: 0x0 0x0 0x0 0x0
>> [ 65.965061] 050 [0x82005320]: 0x0 0x0 0x0 0x0
>> [ 65.969410] 051 [0x82005330]: 0x0 0x0 0x0 0x0
>> [ 65.973760] 052 [0x82005340]: 0x0 0x0 0x0 0x0
>> [ 65.978110] 053 [0x82005350]: 0x0 0x0 0x0 0x0
>> [ 65.982460] 054 [0x82005360]: 0x0 0x0 0x0 0x0
>> [ 65.986812] 055 [0x82005370]: 0x0 0x0 0x0 0x0
>> [ 65.991161] 056 [0x82005380]: 0x0 0x0 0x0 0x0
>> [ 65.995510] 057 [0x82005390]: 0x0 0x0 0x0 0x0
>> [ 65.999860] 058 [0x820053a0]: 0x0 0x0 0x0 0x0
>> [ 66.004210] 059 [0x820053b0]: 0x0 0x0 0x0 0x0
>> [ 66.008559] 060 [0x820053c0]: 0x0 0x0 0x0 0x0
>> [ 66.012908] 061 [0x820053d0]: 0x0 0x0 0x0 0x0
>> [ 66.017257] 062 [0x820053e0]: 0x0 0x0 0x0 0x0
>> [ 66.021607] 063 [0x820053f0]: 0x0 0x0 0x0 0x0
>> [ ID] Interval Transfer Bitrate Retr Cwnd
>> [ 5] 0.00-1.00 sec 184 KBytes 1.50 Mbits/sec 0
>> 1.41 KBytes
>> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>>
>>
>> On 5/9/2018 3:35 PM, Jose Abreu wrote:
>>> Hi Bhadram,
>>>
>>> On 09-05-2018 08:18, Bhadram Varka wrote:
>>>> + queue0 {
>>>> + snps,weight = <0x10>;
>>>> + queue1 {
>>>> + snps,weight = <0x10>;
>>>>
>>>> + queue2 {
>>>> + snps,weight = <0x10>;
>>>>
>>>> + queue3 {
>>>> + snps,weight = <0x10>;
>>>>
>>> This is wrong. You can't use the same weight for all queues.
>>> Please try with different weights (for example: 0x10, 0x11, 0x12,
>>> 0x13).
>>>
>>> Thanks and Best Regards,
>>> Jose Miguel Abreu
>>>
>>>
^ permalink raw reply
* [PATCH] rsi: fix spelling mistake: "thead" -> "thread"
From: Colin King @ 2018-05-10 14:32 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, Amitkumar Karwar,
Prameela Rani Garnepudi, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in rsi_dbg debug message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rsi/rsi_91x_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c b/drivers/net/wireless/rsi/rsi_91x_core.c
index 1f1b97220d43..3644d7d99463 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -485,7 +485,7 @@ void rsi_core_xmit(struct rsi_common *common, struct sk_buff *skb)
}
rsi_core_queue_pkt(common, skb);
- rsi_dbg(DATA_TX_ZONE, "%s: ===> Scheduling TX thead <===\n", __func__);
+ rsi_dbg(DATA_TX_ZONE, "%s: ===> Scheduling TX thread <===\n", __func__);
rsi_set_event(&common->tx_thread.event);
return;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next 08/10] net: stmmac: Do not initialize the RX Descriptor twice
From: Jose Abreu @ 2018-05-10 14:33 UTC (permalink / raw)
To: Jose Abreu, netdev
Cc: David S. Miller, Joao Pinto, Vitor Soares, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <8dc038066ee0fbb30f1a82bce5e2e9118b13ce01.1525683833.git.joabreu@synopsys.com>
On 08-05-2018 15:45, Jose Abreu wrote:
> The RX Descriptor is already initialized in at setup phase so there is
> no need to set the values again, we just need to set the owner. This
> allow us to remove another if condition.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: Vitor Soares <soares@synopsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c5769b4..80439be 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3255,10 +3255,7 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
> }
> dma_wmb();
>
> - if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00))
> - stmmac_init_rx_desc(priv, p, priv->use_riwt, 0, 0);
This cant be removed. Please don't merge it.
Thanks and Best Regards,
Jose Miguel Abreu
> - else
> - stmmac_set_rx_owner(priv, p);
> + stmmac_set_rx_owner(priv, p);
>
> dma_wmb();
>
^ 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