On Thu, Aug 16, 2018 at 4:14 PM, Petar Penkov wrote:
> On Thu, Aug 16, 2018 at 3:40 PM, Song Liu wrote:
>>
>> On Thu, Aug 16, 2018 at 9:44 AM, Petar Penkov
>> wrote:
>> > From: Petar Penkov
>> >
>> > Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
>> > attach type BPF_FLOW_DI
On Sun, Aug 19, 2018 at 5:54 PM, Prashant Bhole
wrote:
> s/ENOTSUPP/EOPNOTSUPP/ in function umem_assign_dev().
> This function's return value is directly returned by xsk_bind().
> EOPNOTSUPP is bind()'s possible return value.
>
> Fixes: f734607e819b ("xsk: refactor xdp_umem_assign_dev()")
> Signed
2018-08-20 4:34 GMT+08:00 Heiner Kallweit :
> The three of you reported an MSI-X-related error when the system
> resumes from suspend. This has been fixed for now by disabling MSI-X
> on certain chip versions. However more versions may be affected.
>
> I checked with Realtek and they confirmed that
s/ENOTSUPP/EOPNOTSUPP/ in function umem_assign_dev().
This function's return value is directly returned by xsk_bind().
EOPNOTSUPP is bind()'s possible return value.
Fixes: f734607e819b ("xsk: refactor xdp_umem_assign_dev()")
Signed-off-by: Prashant Bhole
---
net/xdp/xdp_umem.c | 4 ++--
1 file c
Hi Michael,
>>> The main issue is the TX timeout.
>>> .
>>>
[ 2682.911693] bnxt_en :3b:00.0 eth4: TX timeout detected, starting
reset task!
[ 2683.782496] bnxt_en :3b:00.0 eth4: Resp cmpl intr err msg: 0x51
[ 2683.783061] bnxt_en :3b:00.0 eth4: hwrm_ring_free t
The MFW might be reset and re-update its shared memory.
Upon the detection of such a reset the driver rereads this memory, but it
has to wait till the data is valid.
This patch adds the missing wait for a data ready indication.
Signed-off-by: Tomer Tayar
Signed-off-by: Ariel Elior
---
drivers/
Keep sending mailbox commands to the MFW when it is not responsive ends up
with a redundant amount of timeout expiries.
This patch prints the MCP status on the first command which is not
responded, and blocks the following commands.
Since the (un)load request commands might be not responded due to
The MFW manages an internal lock to prevent concurrent hardware
(de)initialization of different PFs.
This, together with the busy-waiting for the MFW's responses for commands,
might lead to a deadlock during concurrent load or unload of PFs.
This patch adds the option to sleep within the busy-waiti
This patch series fixes several issues in the driver's interface with the
management FW (MFW).
v1->v2:
- Fix loop counter decrement to be pre instead of post.
Tomer Tayar (4):
qed: Wait for ready indication before rereading the shmem
qed: Wait for MCP halt and resume commands to take place
Successive iterations of halting and resuming the management chip (MCP)
might fail, since currently the driver doesn't wait for these operations to
actually take place.
This patch prevents the driver from moving forward before the operations
are reflected in the state register.
Signed-off-by: Tome
The three of you reported an MSI-X-related error when the system
resumes from suspend. This has been fixed for now by disabling MSI-X
on certain chip versions. However more versions may be affected.
I checked with Realtek and they confirmed that on certain chip
versions a MSIX-related value in PCI
All ops->delete() wants is getting the tn->idrinfo, but we already
have tc_action before calling ops->delete(), and tc_action has
a pointer ->idrinfo.
More importantly, each type of action does the same thing, that is,
just calling tcf_idr_delete_index().
So it can be just removed.
Fixes: b40907
Cc: Jamal Hadi Salim
Signed-off-by: Cong Wang
---
include/net/act_api.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/net/act_api.h b/include/net/act_api.h
index f9c4b871af88..970303448c90 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -28,7 +28,6 @@ struct tc_a
This reverts commit 42c625a486f3 ("net: sched: act_ife: disable bh
when taking ife_mod_lock"), because what ife_mod_lock protects
is absolutely not touched in rate est timer BH context, they have
no race.
A better fix is following up.
Cc: Vlad Buslov
Cc: Jamal Hadi Salim
Signed-off-by: Cong Wan
tcf_idr_check() is replaced by tcf_idr_check_alloc(),
and __tcf_idr_check() now can be folded into tcf_idr_search().
Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
Cc: Jiri Pirko
Cc: Vlad Buslov
Signed-off-by: Cong Wang
---
include/net/act_api.h | 2 --
net/sched/act_api
The only time we need to take tcfa_lock is when adding
a new metainfo to an existing ife->metalist. We don't need
to take tcfa_lock so early and so broadly in tcf_ife_init().
This means we can always take ife_mod_lock first, avoid the
reverse locking ordering warning as reported by Vlad.
Reported
Fixes: 16af6067392c ("net: sched: implement reference counted action release")
Cc: Jiri Pirko
Cc: Vlad Buslov
Signed-off-by: Cong Wang
---
net/sched/act_api.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 00bf7d2b0bdd..b
use_all_metadata() acquires read_lock(&ife_mod_lock), then calls
add_metainfo() which calls find_ife_oplist() which acquires the same
lock again. Deadlock!
Introduce __add_metainfo() which accepts struct tcf_meta_ops *ops
as an additional parameter and let its callers to decide how
to find it. For
tcf_action_put_many() is mostly called to clean up actions on
failure path, but tcf_action_put_many(&actions[acts_deleted]) is
used in the ugliest way: it passes a slice of the array and
uses an additional NULL at the end to avoid out-of-bound
access.
acts_deleted is completely unnecessary since w
This patchset aims to clean up and fixes some bugs in current
merge window, this is why it is targeting -net.
Patch 1-5 are clean up Vlad's patches merged in current merge
window, patch 6 is just a trivial cleanup.
Patch 7 reverts a lockdep warning fix and patch 8 provides a better
fix for it.
P
After commit 90b73b77d08e, list_head is no longer needed.
Now we just need to convert the list iteration to array
iteration for drivers.
Fixes: 90b73b77d08e ("net: sched: change action API to use array of pointers to
actions")
Cc: Jiri Pirko
Cc: Vlad Buslov
Signed-off-by: Cong Wang
---
driver
From: Li RongQing
Date: Sun, 19 Aug 2018 11:36:08 +0800
> vxlan_find_mac() unconditionally set f->used for every packet,
> this cause a cache miss for every packet, since remote, hlist
> and used of vxlan_fdb share the same cacheline.
>
> With this change f->used is set only if not equal to jiff
From: Tomer Tayar
Date: Sun, 19 Aug 2018 20:58:04 +0300
> + while (!p_info->mfw_mb_length && cnt--) {
> + msleep(msec);
> + p_info->mfw_mb_length =
> + (u16)qed_rd(p_hwfn, p_ptt,
> + p_info->mfw_mb_addr +
> +
From: Wang Jian
Date: Fri, 17 Aug 2018 08:22:53 +
> The tap_queue and the 'tap_dev' are loosely coupled, not 'macvlan_dev'.
There is another reference to macvlan_dev in that comment, which is therefore
also similarly inaccurate. You should add an appropriate Fixes: line for
where this inacc
Successive iterations of halting and resuming the management chip (MCP)
might fail, since currently the driver doesn't wait for these operations to
actually take place.
This patch prevents the driver from moving forward before the operations
are reflected in the state register.
Signed-off-by: Tome
The MFW might be reset and re-update its shared memory.
Upon the detection of such a reset the driver rereads this memory, but it
has to wait till the data is valid.
This patch adds the missing wait for a data ready indication.
Signed-off-by: Tomer Tayar
Signed-off-by: Ariel Elior
---
drivers/
From: Arnd Bergmann
Date: Wed, 15 Aug 2018 19:49:49 +0200
> timekeeping_clocktai64() has been renamed to ktime_get_clocktai_ts64()
> for consistency with the other ktime_get_* access functions.
>
> Rename the new caller that has come up as well.
>
> Question: this is the only ptp driver that se
This patch series fixes several issues in the driver's interface with the
management FW (MFW).
Tomer Tayar (4):
qed: Wait for ready indication before rereading the shmem
qed: Wait for MCP halt and resume commands to take place
qed: Prevent a possible deadlock during driver load and unload
The MFW manages an internal lock to prevent concurrent hardware
(de)initialization of different PFs.
This, together with the busy-waiting for the MFW's responses for commands,
might lead to a deadlock during concurrent load or unload of PFs.
This patch adds the option to sleep within the busy-waiti
Keep sending mailbox commands to the MFW when it is not responsive ends up
with a redundant amount of timeout expiries.
This patch prints the MCP status on the first command which is not
responded, and blocks the following commands.
Since the (un)load request commands might be not responded due to
From: Vlad Buslov
Date: Tue, 14 Aug 2018 21:46:16 +0300
> Recently, ops->init() and ops->dump() of all actions were modified to
> always obtain tcf_lock when accessing private action state. Actions that
> don't depend on tcf_lock for synchronization with their data path use
> non-bh locking API.
"Robert P. J. Day" writes:
> (i'm sure this has been explained many times before, so a link
> covering this will almost certainly do just fine.)
>
> i want to loop one physical ethernet port into another, and just
> ping the daylights from one to the other for stress testing. my fedora
> lapt
> I run inside Virtualbox with the Realtek PCIe GBE Family Controller.
>
> Assuming I'm reading /sys/class/net/enp0s3/driver correctly, it's using the
> e1000 driver.
Hi Craig
Ah. And how do you connect to the network? Please run some tcpdumps
and collect packets at various points. Make sure you
Jak się dzisiaj czujesz, mam nadzieję, że wszystko jest w porządku, cieszę się,
że mogę się z tobą spotkać. W każdym razie jestem Wesley ze Stanów
Zjednoczonych Ameryki, przebywa obecnie w Syrii na misję pokojową. Chcę cię
lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka, a
On Sat, 18 Aug 2018, Willy Tarreau wrote:
> On Sat, Aug 18, 2018 at 09:10:25PM +0200, Andrew Lunn wrote:
> > On Sat, Aug 18, 2018 at 01:39:50PM -0400, Robert P. J. Day wrote:
> > >
> > > (i'm sure this has been explained many times before, so a link
> > > covering this will almost certainly do j
35 matches
Mail list logo
