On 3/22/21 6:20 PM, Brian Norris wrote:
On Mon, Mar 22, 2021 at 4:58 PM Ben Greear wrote:
On 7/22/20 6:00 AM, Felix Fietkau wrote:
On 2020-07-22 14:55, Johannes Berg wrote:
On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
I'm considering testing a different approach (with
s? I realized I'm running Felix's patch since his mt76
driver needs it. Any chance it will go upstream?
Thanks,
Ben
- Felix
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 1/22/21 8:02 AM, David Ahern wrote:
On 1/22/21 8:45 AM, Ben Greear wrote:
Hello,
I have a system with a management interface that is not in any VRF, and
then I have
a port that *is* in a VRF. I'd like to be able to set up ssh port
forwarding so that
when I log into the system o
tso: add UDP segmentation support")
Signed-off-by: Eric Dumazet
Reported-by: Ben Greear
Bisected-by: Ben Greear
I appreciate the credit, but the bisect and some other initial bug hunting was
done by people on this thread:
https://bugzilla.kernel.org/show_bug.cgi?id=209913
Thanks,
Ben
T
h the VRF interface.
Is there a way to do such a thing?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 1/7/21 10:16 PM, Florian Westphal wrote:
Ben Greear wrote:
I noticed my system has a hung process trying to 'rmmod nf_conntrack'.
I've generally been doing the script that calls rmmod forever,
but only extensively tested on 5.4 kernel and earlier.
If anyone has any ideas
21514 Jan 07 16:12:05 TR-398 kernel: ? do_syscall_64+0x2d/0x70
21515 Jan 07 16:12:05 TR-398 kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 12/21/20 12:01 PM, Rainer Suhm wrote:
Am 21.12.20 um 20:14 schrieb Eric Dumazet:
On Mon, Dec 21, 2020 at 8:04 PM Eric Dumazet wrote:
On Mon, Dec 21, 2020 at 7:46 PM Eric Dumazet wrote:
On Sat, Dec 19, 2020 at 5:55 PM Ben Greear wrote:
On 12/19/20 7:18 AM, Johannes Berg wrote:
On
On 12/19/20 7:18 AM, Johannes Berg wrote:
On Fri, 2020-12-18 at 12:16 -0800, Jakub Kicinski wrote:
On Thu, 17 Dec 2020 12:40:26 -0800 Ben Greear wrote:
On 12/17/20 10:20 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 7:13 PM Ben Greear wrote:
It is the iwlwifi/mvm logic that supports ax200
On 12/17/20 2:24 PM, Brian Norris wrote:
On Tue, Dec 15, 2020 at 10:23:33AM -0800, Ben Greear wrote:
On 12/15/20 9:21 AM, Youghandhar Chintala wrote:
From: Rakesh Pillai
Currently in case of target hardware restart ,we just reconfig and
re-enable the security keys and enable the network
On 12/17/20 10:20 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 7:13 PM Ben Greear wrote:
It is the iwlwifi/mvm logic that supports ax200.
Let me ask again :
I see two different potential call points :
drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1529:
tso_build_hdr(skb, hdr_page
On 12/17/2020 10:07 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 6:56 PM Ben Greear wrote:
On 12/17/20 2:11 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 12:59 AM Ben Greear wrote:
On 12/16/20 3:09 PM, Ben Greear wrote:
Hello Eric,
The patch below evidently causes TCP throughput to
On 12/17/20 2:11 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 12:59 AM Ben Greear wrote:
On 12/16/20 3:09 PM, Ben Greear wrote:
Hello Eric,
The patch below evidently causes TCP throughput to be about 50Mbps instead of
700Mbps
when using ax200 to upload tcp traffic.
When I disable TSO
On 12/16/20 3:09 PM, Ben Greear wrote:
Hello Eric,
The patch below evidently causes TCP throughput to be about 50Mbps instead of
700Mbps
when using ax200 to upload tcp traffic.
When I disable TSO, performance goes back up to around 700Mbps.
As a followup, when I revert the patch, upload
description:
net: tso: add UDP segmentation support
Note that like TCP, we do not support additional encapsulations,
and that checksums must be offloaded to the NIC.
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http
/drivers that *can* support seamless
restarts?
If not, then just could always enable this feature in mac80211?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ecord)) { ... }
All in all, I think I'd want to compile this out (while leaving other debug
compiled
in) since it seems this stuff would be rarely used and it adds method calls to
hot
paths.
That is a decision for Kalle though, so see what he says...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
tie this into a watch-dog program to allow automatic
reboot
of the system soon after this event is seen, for instance.
Could you post your devlink RFC patches somewhere public?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
hat said, at least in my experience with ath10k-ct, the OS normally recovers
fine
from firmware crashes. ath10k already reports full crash reports on udev, so
easy for user-space to notice and report bug reports upstream if it cares to.
Probably
other NICs do the same, and if not, they certainly coul
On 05/18/2020 10:09 AM, Luis Chamberlain wrote:
On Mon, May 18, 2020 at 09:58:53AM -0700, Ben Greear wrote:
On 05/18/2020 09:51 AM, Luis Chamberlain wrote:
On Sat, May 16, 2020 at 03:24:01PM +0200, Johannes Berg wrote:
On Fri, 2020-05-15 at 21:28 +, Luis Chamberlain wrote
ware has crashed.
You can listen for udev events (I think that is the right term),
and find crashes that way. You get the actual crash info as well.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
rmware should behave similarly.
Seems like upstream ath10k could really benefit from having some test beds
so you can actually test code on different chips and have confidence
in your changes!
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 9/30/19 11:45 AM, Ben Greear wrote:
On 9/22/19 12:23 PM, David Ahern wrote:
On 9/20/19 9:57 AM, Ben Greear wrote:
On 9/10/19 6:08 PM, Ben Greear wrote:
On 9/10/19 3:17 PM, Ben Greear wrote:
Today we were testing creating 200 virtual station vdevs on ath9k,
and using
VRF for the routing
On 10/11/19 1:35 PM, David Ahern wrote:
On 10/11/19 7:57 AM, Ben Greear wrote:
The down-up cycling is done on purpose - to clear out neigh entries and
routes associated with the device under the old VRF. All entries must be
created with the device in the new VRF.
I believe I found another
On 8/16/19 2:48 PM, David Ahern wrote:
On 8/16/19 3:28 PM, Ben Greear wrote:
On 8/16/19 12:15 PM, David Ahern wrote:
On 8/16/19 1:13 PM, Ben Greear wrote:
I have a problem with a VETH port when setting up a somewhat complicated
VRF setup. I am loosing the global IPv6 addr, and also the route
On 9/22/19 12:23 PM, David Ahern wrote:
On 9/20/19 9:57 AM, Ben Greear wrote:
On 9/10/19 6:08 PM, Ben Greear wrote:
On 9/10/19 3:17 PM, Ben Greear wrote:
Today we were testing creating 200 virtual station vdevs on ath9k,
and using
VRF for the routing.
Looks like the same issue happens w/out
On 9/10/19 6:08 PM, Ben Greear wrote:
On 9/10/19 3:17 PM, Ben Greear wrote:
Today we were testing creating 200 virtual station vdevs on ath9k, and using
VRF for the routing.
Looks like the same issue happens w/out VRF, but there I have oodles of routing
rules, so it is an area ripe for
On 9/10/19 3:17 PM, Ben Greear wrote:
Today we were testing creating 200 virtual station vdevs on ath9k, and using
VRF for the routing.
Looks like the same issue happens w/out VRF, but there I have oodles of routing
rules, so it is an area ripe for failure.
Will upgrade to 5.2.14+ and retest
routing table, then suddenly
things start working again.
I am curious if anyone has seen anything similar or has suggestions for more
ways to debug this. It seems reproducible, but it is a pain to
debug.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 08/20/2019 08:02 PM, David Ahern wrote:
On 8/20/19 2:27 PM, Ben Greear wrote:
I recently spend a few days debugging what in the end was user error on
my part.
Here are my notes in hope they help someone else.
First, 'ip -6 route show vrf vrfX' will not show some of the
routes (
7;t actually be accepted up the stack
(I think that is the symptom at least)
Not sure exactly what anycast does, but I'm guessing it is required for
something useful.
You must manually re-add those to the table unless you for certain know that
you do not need them for whatever reason.
Thanks,
On 8/16/19 12:15 PM, David Ahern wrote:
On 8/16/19 1:13 PM, Ben Greear wrote:
I have a problem with a VETH port when setting up a somewhat complicated
VRF setup. I am loosing the global IPv6 addr, and also the route,
apparently
when I add the veth device to a vrf. From my script's o
rddVR0 metric 1024 pref medium
As far as I can tell, the same actions for a wifi AP interface do not hit this
problem,
but not sure if that is luck or not at this point.
Any ideas what might be going on here?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
14 RSI: 7ffe57e53f80 RDI: 0003
[67044.732085] RBP: 7ffe57e53fd0 R08: 7ffe57e53f24 R09: 000c
[67044.732086] R10: R11: 0246 R12: 7ffe57e53f24
[67044.732087] R13: 7ffe57e54160 R14: R15: 0003
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
tually off-channel, and CAC has already
completed successfully.
Any opinions on where to fix this?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 2/6/19 5:50 PM, David Ahern wrote:
On 2/6/19 3:20 PM, Ben Greear wrote:
Hello,
I just saw this warning on a system running a hacked 4.20.2+ kernel.
Any known bugs
of this nature in this (upstream) kernel? The command that is blocked is:
'rmmod bridge llc'
[17
079.306438] unregister_netdevice: waiting for _vrf13 to become free. Usage
count = 1
[17089.314656] unregister_netdevice: waiting for _vrf13 to become free. Usage
count = 1
[17099.322870] unregister_netdevice: waiting for _vrf13 to become free. Usage
count = 1
Thanks,
Ben
--
Ben Greear
Candela Te
make it work with
VRF.
Has anyone already worked on VRF support for NFS?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
t?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ed a patch to disable mac-80211 tx when FW crashes,
I think...I have not tried to backport that.
https://patchwork.kernel.org/patch/10411967/
Thanks,
Ben
Michał
On 8 June 2018 at 23:40, Arend van Spriel wrote:
On 6/8/2018 5:17 PM, Ben Greear wrote:
I recalled an email from Michał leavin
On 06/07/2018 05:13 PM, Cong Wang wrote:
On Thu, Jun 7, 2018 at 4:48 PM, wrote:
From: Ben Greear
While testing an ath10k firmware that often crashed under load,
I was seeing kernel crashes as well. One of them appeared to
be a dereference of a NULL flow object in fq_tin_dequeue.
I have
. list_first_entry_or_null()
returns NULL only when the list is empty, but we already check
list_empty() right before this code, and it is protected by fq->lock.
Nevermind then.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/07/2018 02:52 PM, Cong Wang wrote:
On Thu, Jun 7, 2018 at 2:41 PM, Ben Greear wrote:
On 06/07/2018 02:29 PM, Cong Wang wrote:
On Thu, Jun 7, 2018 at 9:06 AM, wrote:
--- a/include/net/fq_impl.h
+++ b/include/net/fq_impl.h
@@ -80,6 +80,9 @@ static struct sk_buff *fq_tin_dequeue
in or fq was passed in as NULL?
Anyway, if the patch seems worthless just ignore it. I'll leave it in my tree
since it should be harmless and will let you know if I ever hit it.
If someone else hits a similar crash, hopefully they can report it.
Thanks,
Ben
--
Ben Greear
Candela Techno
On 06/07/2018 09:17 AM, Eric Dumazet wrote:
On 06/07/2018 09:06 AM, gree...@candelatech.com wrote:
From: Ben Greear
While testing an ath10k firmware that often crashed under load,
I was seeing kernel crashes as well. One of them appeared to
be a dereference of a NULL flow object in
16:03:39 localhost.localdomain kernel: []
cpu_startup_entry+0x2ba/0x380
May 17 16:03:39 localhost.localdomain kernel: []
start_secondary+0x149/0x170
May 17 16:03:39 localhost.localdomain kernel: ---[ end trace f62c6dd947785e8f
]---
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 05/09/2018 12:02 PM, Ben Greear wrote:
On 05/09/2018 11:48 AM, Eric Dumazet wrote:
On 05/09/2018 11:43 AM, Ben Greear wrote:
On 05/08/2018 10:10 AM, Eric Dumazet wrote:
On 05/08/2018 09:44 AM, Ben Greear wrote:
Hello,
I am trying to track down a performance regression that appears to
On 05/09/2018 11:48 AM, Eric Dumazet wrote:
On 05/09/2018 11:43 AM, Ben Greear wrote:
On 05/08/2018 10:10 AM, Eric Dumazet wrote:
On 05/08/2018 09:44 AM, Ben Greear wrote:
Hello,
I am trying to track down a performance regression that appears to be between
4.13
and 4.14.
I first saw
On 05/08/2018 10:10 AM, Eric Dumazet wrote:
On 05/08/2018 09:44 AM, Ben Greear wrote:
Hello,
I am trying to track down a performance regression that appears to be between
4.13
and 4.14.
I first saw the problem with a hacked version of pktgen on some ixgbe NICs.
4.13 can do
right at 10G
based on the incoming
interface
for the ICMP redirect response?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
perf top, it would appear that some lock is probably to blame.
Any ideas what might have been introduced during this interval that
would cause this?
Anyone else seen similar?
I'm going to attempt some more manual steps to try to find the commit that
introduces this...
Thanks,
Ben
--
Ben G
b2d_send ip1 ip2 23777" where ip1 and ip2 are ip addresses of interfaces eth0
and eth1 of PC-2.
3. Result:
- b2d_recv prints out data from eth0 and eth1 on linux kernels from 4.14 up to
4.16.
- b2d_recv prints out data from only eth0 on linux kernels below 4.14.
**
Thanks,
On 05/04/2018 10:47 AM, David Ahern wrote:
On 4/19/18 12:01 PM, gree...@candelatech.com wrote:
From: Ben Greear
This keeps us from crashing in certain test cases where we
bring up many (1000, for instance) mac-vlans with IPv6
enabled in the kernel. This bug has been around for a
very long
n your
application throughput after this change, using TCP_NODELAY might
help bring performance back however that might increase latency.
I guess you mean _disabling_ TCP_NODELAY instead of _using_ TCP_NODELAY?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 04/22/2018 02:15 PM, Roopa Prabhu wrote:
On Sun, Apr 22, 2018 at 11:54 AM, David Miller wrote:
From: Johannes Berg
Date: Thu, 19 Apr 2018 17:26:57 +0200
On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
Maybe this could be in followup patches? It's going to touch a lot of
On 04/22/2018 11:54 AM, David Miller wrote:
From: Johannes Berg
Date: Thu, 19 Apr 2018 17:26:57 +0200
On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
Maybe this could be in followup patches? It's going to touch a lot of files,
and might be hell to get merged all at once, and
On 04/18/2018 11:38 PM, Johannes Berg wrote:
On Wed, 2018-04-18 at 14:51 -0700, Ben Greear wrote:
It'd be pretty hard to know which flags are firmware stats?
Yes, it is, but ethtool stats are difficult to understand in a generic
manner anyway, so someone using them is already likely
them individually to different lists I figure I'd be hearing about how
the netdev patch is useless because it has no driver support, etc.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 01/24/2018 03:59 PM, Ben Greear wrote:
On 06/20/2017 08:03 PM, David Ahern wrote:
On 6/20/17 5:41 PM, Ben Greear wrote:
On 06/20/2017 11:05 AM, Michal Kubecek wrote:
On Tue, Jun 20, 2017 at 07:12:27AM -0700, Ben Greear wrote:
On 06/14/2017 03:25 PM, David Ahern wrote:
On 6/14/17 4:23 PM
On 03/20/2018 11:24 AM, Michal Kubecek wrote:
On Tue, Mar 20, 2018 at 08:39:33AM -0700, Ben Greear wrote:
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
IMHO it would be more practical to set "0 means same as GSTATS" as a
rule and make ethtool_get_stats() a wrapper for ethtool_get_s
vior, then that might be something to consider.
Right now I don't see the point of handling packets that don't cross
network namespace boundaries specially, other than to preserve backwards
compatibility.
Well, backwards compat is a big deal all by itself!
Thanks,
Ben
Eric
--
Be
On 03/20/2018 09:11 AM, Steve deRosier wrote:
On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear wrote:
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
On Wed, Mar 07, 2018 at 11:51:29AM -0800, gree...@candelatech.com wrote:
From: Ben Greear
This is similar to ETHTOOL_GSTATS, but it allows you to
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
On Wed, Mar 07, 2018 at 11:51:29AM -0800, gree...@candelatech.com wrote:
From: Ben Greear
This is similar to ETHTOOL_GSTATS, but it allows you to specify
a 'level'. This level can be used by the driver to decrease the
amount of stats
e times w/out deadlocking.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ry. I have not looked at VRF at all to date...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/20/2017 08:03 PM, David Ahern wrote:
On 6/20/17 5:41 PM, Ben Greear wrote:
On 06/20/2017 11:05 AM, Michal Kubecek wrote:
On Tue, Jun 20, 2017 at 07:12:27AM -0700, Ben Greear wrote:
On 06/14/2017 03:25 PM, David Ahern wrote:
On 6/14/17 4:23 PM, Ben Greear wrote:
On 06/13/2017 07:27 PM
On 01/24/2018 10:38 AM, Denys Fedoryshchenko wrote:
On 2018-01-24 20:31, Ben Greear wrote:
On 01/24/2018 08:34 AM, Neftin, Sasha wrote:
On 1/24/2018 18:11, Alexander Duyck wrote:
On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear wrote:
Hello,
Anyone have any more suggestions for making e1000e
On 01/24/2018 08:34 AM, Neftin, Sasha wrote:
On 1/24/2018 18:11, Alexander Duyck wrote:
On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear wrote:
Hello,
Anyone have any more suggestions for making e1000e work better? This is
from a 4.9.65+ kernel,
with these additional e1000e patches applied
On 01/23/2018 03:27 PM, Ben Greear wrote:
On 01/23/2018 03:21 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 15:10 -0800, Ben Greear wrote:
On 01/23/2018 02:29 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 14:09 -0800, Ben Greear wrote:
On 01/23/2018 02:07 PM, Eric Dumazet wrote:
On Tue
Full Duplex, Flow Control: Rx/Tx
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 01/23/2018 03:21 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 15:10 -0800, Ben Greear wrote:
On 01/23/2018 02:29 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 14:09 -0800, Ben Greear wrote:
On 01/23/2018 02:07 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 13:49 -0800, Ben Greear wrote
On 01/23/2018 02:29 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 14:09 -0800, Ben Greear wrote:
On 01/23/2018 02:07 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 13:49 -0800, Ben Greear wrote:
On 01/22/2018 10:16 AM, Eric Dumazet wrote:
On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote
On 01/23/2018 02:07 PM, Eric Dumazet wrote:
On Tue, 2018-01-23 at 13:49 -0800, Ben Greear wrote:
On 01/22/2018 10:16 AM, Eric Dumazet wrote:
On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
My test case is to have 6 processes each create 5000 TCP IPv4 connections to
each other
on a
On 01/22/2018 10:46 AM, Josh Hunt wrote:
On Mon, Jan 22, 2018 at 10:30 AM, Ben Greear wrote:
On 01/22/2018 10:16 AM, Eric Dumazet wrote:
On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
My test case is to have 6 processes each create 5000 TCP IPv4 connections
to each other
on a system
On 01/22/2018 10:16 AM, Eric Dumazet wrote:
On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
My test case is to have 6 processes each create 5000 TCP IPv4 connections to
each other
on a system with 16GB RAM and send slow-speed data. This works fine on a 4.7
kernel, but
will not work at
On 01/22/2018 10:30 AM, Ben Greear wrote:
On 01/22/2018 10:16 AM, Eric Dumazet wrote:
On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
My test case is to have 6 processes each create 5000 TCP IPv4 connections to
each other
on a system with 16GB RAM and send slow-speed data. This works
On 01/22/2018 10:16 AM, Eric Dumazet wrote:
On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
My test case is to have 6 processes each create 5000 TCP IPv4 connections to
each other
on a system with 16GB RAM and send slow-speed data. This works fine on a 4.7
kernel, but
will not work at
meantime...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ou have any suggestions.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 10/12/2017 03:00 PM, Roopa Prabhu wrote:
On Thu, Oct 12, 2017 at 2:45 PM, Ben Greear wrote:
On 10/11/2017 01:49 PM, David Miller wrote:
From: "John W. Linville"
Date: Wed, 11 Oct 2017 16:44:07 -0400
On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote:
I noticed
On 10/11/2017 01:49 PM, David Miller wrote:
From: "John W. Linville"
Date: Wed, 11 Oct 2017 16:44:07 -0400
On Wed, Oct 11, 2017 at 09:51:56AM -0700, Ben Greear wrote:
I noticed today that setting some ethtool settings to the same value
returns an error code. I would think t
channel parameters changed, aborting
current values: tx 0 rx 0 other 1 combined 1
[root@lf0313-6477 lanforge]# echo $?
1
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 09/12/2017 01:26 PM, Michal Kubecek wrote:
On Tue, Sep 12, 2017 at 11:54:43AM -0700, Ben Greear wrote:
It does not appear to work on Fedora-26, and I'm curious if someone
knows what needs doing to get this support working?
It's rather complicated. The "vlan" and &q
On 09/12/2017 11:54 AM, Ben Greear wrote:
It does not appear to work on Fedora-26, and I'm curious if someone knows what
needs
doing to get this support working?
Thanks,
Ben
Gah, I spoke too soon. system-test guy says it works on cmd-line, but
not when we try to make it work in an
It does not appear to work on Fedora-26, and I'm curious if someone knows what
needs
doing to get this support working?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
e wrong to add this to the actual kernel header I think.
Do you have another suggestion for fixing iproute2 compile?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 09/02/2017 12:55 AM, Michal Kubecek wrote:
On Fri, Sep 01, 2017 at 04:52:20PM -0700, Ben Greear wrote:
In the patch below, usage of __kernel_ulong_t and __kernel_long_t is
introduced, but that is not available on older system (fedora-14, at least).
It is not a #define, so I am having
*/
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 08/16/2017 08:18 PM, Dan Williams wrote:
On Wed, 2017-08-16 at 19:36 -0700, Ben Greear wrote:
On 08/16/2017 07:11 PM, Dan Williams wrote:
On Wed, 2017-08-16 at 14:31 -0700, David Miller wrote:
From: Dan Williams
Date: Wed, 16 Aug 2017 16:22:41 -0500
My biggest suggestion is that perhaps
frames or 10 seconds, then the caller can do longer term
averaging
as it sees fit. Probably no need for lots of averaging complexity in the
kernel.
rate-ctrl for wifi basically doesn't happen until you transmit or receive a
fairly steady stream, so it will fluctuate a lot.
Thanks,
Ben
Dan
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/20/2017 11:05 AM, Michal Kubecek wrote:
On Tue, Jun 20, 2017 at 07:12:27AM -0700, Ben Greear wrote:
On 06/14/2017 03:25 PM, David Ahern wrote:
On 6/14/17 4:23 PM, Ben Greear wrote:
On 06/13/2017 07:27 PM, David Ahern wrote:
Let's try a targeted debug patch. See attached
I h
On 06/14/2017 03:25 PM, David Ahern wrote:
On 6/14/17 4:23 PM, Ben Greear wrote:
On 06/13/2017 07:27 PM, David Ahern wrote:
Let's try a targeted debug patch. See attached
I had to change it to pr_err so it would go to our serial console
since the system locked hard on crash,
and
oblem.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/13/2017 01:28 PM, David Ahern wrote:
On 6/13/17 2:16 PM, Ben Greear wrote:
On 06/09/2017 02:25 PM, Eric Dumazet wrote:
On Fri, 2017-06-09 at 07:27 -0600, David Ahern wrote:
On 6/8/17 11:55 PM, Cong Wang wrote:
On Thu, Jun 8, 2017 at 2:27 PM, Ben Greear
wrote:
As far as I can tell
On 06/09/2017 02:25 PM, Eric Dumazet wrote:
On Fri, 2017-06-09 at 07:27 -0600, David Ahern wrote:
On 6/8/17 11:55 PM, Cong Wang wrote:
On Thu, Jun 8, 2017 at 2:27 PM, Ben Greear wrote:
As far as I can tell, the patch did not help, or at least we still reproduce
the
crash easily.
netlink
k_buff *skb,
} else
w->skip = 0;
- read_lock_bh(&table->tb6_lock);
res = fib6_walk_continue(w);
read_unlock_bh(&table->tb6_lock);
if (res <= 0) {
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/06/2017 05:27 PM, Eric Dumazet wrote:
On Tue, 2017-06-06 at 18:00 -0600, David Ahern wrote:
On 6/6/17 3:06 PM, Ben Greear wrote:
This bug has been around forever, and we recently got an intern and
stuck him with
trying to reproduce it on the latest kernel. It is still here. I'
Fatal exception in interrupt
Kernel Offset: disabled
Rebooting in 10 seconds..
ACPI MEMORY or I/O RESET_REG.
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
box.
I have not seen the problem again, so it is not easy for me to reproduce.
If you reproduce it, maybe check 'strace' on the 'iw' process to see if it is
hung on writing output to the pipe or reading input? In my case, it appeared
to be hung reading input from netlink, input tha
On 05/17/2017 06:30 AM, Johannes Berg wrote:
On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
* Ben Greear [17.05.2017 11:51]:
I have been keeping an 'iw events' program running with a perl
script gathering its
output and post-processing it. This has been working for sev
1 - 100 of 558 matches
Mail list logo
