Subject: linux-source-2.6.16: inconsistent device detetion: eth0<=>eth1
Package: linux-source-2.6.16
Version: 2.6.16-2
Severity: normal
I have two ethernet cards on my box, an onboard SiS 7012 and a pci ne-2k
compatible. When I boot the system, sometimes the SiS is detected as
eth0 and the pci as
its added to printk don't get compiled in
unless CONFIG_NETCONSOLE=y.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
if
>
> OIC, hmmm... yeah, I think doing it on-demand would be better but will
> try to find out which way is better.
Allocating the buffer dynamically is fine, but in that case the code to
do so should ideally be compiled out. Since printk is used by almost
*all* kernels, while netconsol
reasonble floor set we've had it
enabled for the past 6 months.
The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives
administrators the ability to control the floor of MSS probing.
Signed-off-by: Josh Hunt
---
Documentation/networking/ip-sysctl.txt | 6 ++
include/n
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
underestimate the MTU on lossy connections allowing the MSS to get down to
48. We have found that in almost all of these cases on our
On 7/28/19 6:54 AM, Eric Dumazet wrote:
On Sun, Jul 28, 2019 at 1:21 AM Josh Hunt wrote:
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
underestimate the MTU on lossy connections
On 7/28/19 2:14 PM, Josh Hunt wrote:
On 7/28/19 6:54 AM, Eric Dumazet wrote:
On Sun, Jul 28, 2019 at 1:21 AM Josh Hunt wrote:
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
On 7/29/19 6:12 AM, Neal Cardwell wrote:
On Sun, Jul 28, 2019 at 5:14 PM Josh Hunt wrote:
On 7/28/19 6:54 AM, Eric Dumazet wrote:
On Sun, Jul 28, 2019 at 1:21 AM Josh Hunt wrote:
On 7/27/19 12:05 AM, Eric Dumazet wrote:
On Sat, Jul 27, 2019 at 4:23 AM Josh Hunt wrote:
The current
reasonble floor set we've had it
enabled for the past 6 months.
The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives
administrators the ability to control the floor of MSS probing.
Signed-off-by: Josh Hunt
---
Documentation/networking/ip-sysctl.txt | 6 ++
include/n
TCP_BASE_MSS is used as the default initial MSS value when MTU probing is
enabled. Update the comment to reflect this.
Suggested-by: Neal Cardwell
Signed-off-by: Josh Hunt
---
include/net/tcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net
On 8/7/19 11:12 PM, Eric Dumazet wrote:
On 8/8/19 1:52 AM, Josh Hunt wrote:
The current implementation of TCP MTU probing can considerably
underestimate the MTU on lossy connections allowing the MSS to get down to
48. We have found that in almost all of these cases on our networks these
paths
On 8/7/19 11:13 PM, Eric Dumazet wrote:
On 8/8/19 1:52 AM, Josh Hunt wrote:
TCP_BASE_MSS is used as the default initial MSS value when MTU probing is
enabled. Update the comment to reflect this.
Suggested-by: Neal Cardwell
Signed-off-by: Josh Hunt
---
Signed-off-by: Eric Dumazet
Dave
On 8/9/19 11:43 AM, David Miller wrote:
From: Josh Hunt
Date: Fri, 9 Aug 2019 11:38:05 -0700
I forgot to tag these at net-next. Do I need to resubmit a v3 with
net-next in the subject?
No need.
Thanks
ased on the previous discussion this sounds fine to me.
Willem
Are you OK to ACK this? If not, is there something else you'd rather see
here?
Thanks
Josh
ttps://lkml.org/lkml/2021/3/24/1485 ? If that doesn't work I think your
suggestion of reverting nolock makes sense to me. We've moved to using
fq as our default now b/c of this bug.
Josh
help. Do I
> need to apply the whole series or something else?
Can you recreate with this patch, and add "unwind_debug" to the cmdline?
It will spit out a bunch of stack data.
From: Josh Poimboeuf
Subject: [PATCH] Subject: [PATCH] x86/unwind: Add 'unwind_debug' cmdline
op
On Wed, Feb 03, 2021 at 02:41:53PM -0800, Ivan Babrou wrote:
> On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
> >
> > On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > > > Can you pretty please not line-wrap console output? It's unreadable.
&
On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:
> > > > Can you recreate with this patch, and add "unwind_debug" to the cmdline?
> > > > It will spit out a bunch of stack data.
> > >
> > > Here's the three I'm building:
> > >
> > > * https://github.com/bobrik/linux/tree/ivan/static-cal
bmit a fix for decode_stacktrace.sh).
> I cannot reproduce this one, and it took 2 days of uptime for it to
> happen. Is there anything I can do to help diagnose it?
Can you run with the same unwind_debug patch+cmdline when you try to
recreate this one? In the meantime I'll look at the available data.
--
Josh
On Wed, Feb 03, 2021 at 09:44:48PM -0500, Steven Rostedt wrote:
> > > [ 128.441287][C0] RIP: 0010:skcipher_walk_next
> > > (crypto/skcipher.c:322 crypto/skcipher.c:384)
>
> Why do we have an RIP in skcipher_walk_next, if its the unwinder that
> had a bug? Or are they related?
>
> Or did skci
er patch fixed the unwinder failure mode to be the above
(harmless) unwinder warning, instead of a disruptive KASAN failure.
This patch fixes the specific underlying crypto unwinding metadata
issue.
I'll definitely be sending both fixes. The improved failure mode patch
will come first because it's more urgent and lower risk.
--
Josh
Hi Jike
On 8/20/20 12:43 AM, Jike Song wrote:
Hi Josh,
We met possibly the same problem when testing nvidia/mellanox's
GPUDirect RDMA product, we found that changing NET_SCH_DEFAULT to
DEFAULT_FQ_CODEL mitigated the problem, having no idea why. Maybe you
can also have a try?
We als
In preparation for using R12 indexing instructions in BPF JIT code, add
support for generating the x86 SIB byte.
Signed-off-by: Josh Poimboeuf
---
arch/x86/net/bpf_jit_comp.c | 69 +
1 file changed, 54 insertions(+), 15 deletions(-)
diff --git a/arch/x86/net
7fff47b7b ("net: remove support for per driver ndo_busy_poll()")
indirectly fixed this upstream in linux-4.11 by removing the offending
pointer usage. No other users of napi->dev touch its netdev_ops.
Fixes: ce6aea93f751 ("net: network drivers no longer need to implement
ndo_busy_pol
7fff47b7b ("net: remove support for per driver ndo_busy_poll()")
indirectly fixed this upstream in linux-4.11 by removing the offending
pointer usage. No other users of napi->dev touch its netdev_ops.
Fixes: 8b80cda536ea ("net: rename include/net/ll_poll.h to
include/net/busy_pol
On Jul 1, 2019, at 6:51 PM, David Miller wrote:
> I just tried to apply this with "git am" to the current v4.19 -stable
> branch and it failed.
This is only needed for the v4.9 stable kernel, ndo_busy_poll (and this NPE)
went away in kernel 4.11.
Sorry, I probably should have called that out m
someone at Realtek then?
josh
> The related extension to r8169 driver will be submitted in the next days.
> ---
> WHENCE| 3 +++
> rtl_nic/rtl8125a-3.fw | Bin 0 -> 3456 bytes
> 2 files changed, 3 insertions(+)
> create mode 100644 rtl_nic/rtl8125a-3.fw
>
.6 rcv_space:43725 rcv_ssthresh:43690 minrtt:0.007
Signed-off-by: Josh Hunt
---
man/man8/ss.8 | 3 +++
misc/ss.c | 51 +--
2 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 03a3dcc6c9c3..dd5ebc9
On 4/25/19 3:59 PM, Stephen Hemminger wrote:
On Thu, 25 Apr 2019 17:21:48 -0400
Josh Hunt wrote:
Multi-line output in ss makes it difficult to search for things with
grep. This new option will make it easier to find sockets matching
certain criteria with simple grep commands.
Example without
NFIG_RETPOLINE?
[0]: https://lore.kernel.org/patchwork/patch/1044863/
[1]: https://lore.kernel.org/patchwork/patch/1054472/
If nothing else the commit message no longer seems accurate.
Regards,
-- Josh
On 4/30/19 11:30 AM, David Ahern wrote:
On 4/25/19 3:21 PM, Josh Hunt wrote:
@@ -4877,6 +4903,7 @@ static void _usage(FILE *dest)
"\n"
" -K, --kill forcibly close sockets, display what was closed\n"
" -H, --no-header Suppress header li
On 4/30/19 11:31 AM, Josh Hunt wrote:
On 4/30/19 11:30 AM, David Ahern wrote:
On 4/25/19 3:21 PM, Josh Hunt wrote:
@@ -4877,6 +4903,7 @@ static void _usage(FILE *dest)
"\n"
" -K, --kill forcibly close sockets, display what was
closed\n"
" -H,
On 4/30/19 12:41 PM, David Ahern wrote:
On 4/30/19 12:55 PM, Josh Hunt wrote:
Actually, David can you clarify what you meant by "use 'oneline' as the
long option without the '-'."?
for your patch:
1,$s/one-line/oneline/
ip has -oneline which is most likely u
.6 rcv_space:43725 rcv_ssthresh:43690 minrtt:0.007
Signed-off-by: Josh Hunt
---
v1 -> v2
* Update long option to --oneline to match other ip tools as per David.
man/man8/ss.8 | 3 +++
misc/ss.c | 51 +--
2 files changed, 44 insertions(+
ull check")
>>
>> Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM
>> protocol")
>> Signed-off-by: Colin Ian King
>
>
> Acked-by: Oliver Hartkopp
I don't see this one queued up in the net or net-next trees. Did it
fall throu
On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote:
> This series adds SIMPLE_MAX() to be used in places where a stack array
> is actually fixed, but the compiler still warns about VLA usage due to
> confusion caused by the safety checks in the max() macro.
>
> I'm sending these via -mm sin
On Thu, Mar 08, 2018 at 10:02:01AM -0800, Kees Cook wrote:
> On Thu, Mar 8, 2018 at 7:02 AM, Josh Poimboeuf wrote:
> > On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote:
> >> This series adds SIMPLE_MAX() to be used in places where a stack array
> >> is actua
: network drivers no longer need to implement
ndo_busy_poll()") - 4.9.y
Signed-off-by: Josh Elsasser
---
net/core/dev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8898618bf341..d0f67d544587 100644
--- a/net/core/dev.c
+++ b/net/c
commit is likely required for
any stable releases older than linux-4.5.
I hope this is the right way to raise something like this. I couldn't find
a clear answer from the -stable and netdev howtos for bugs against features
that no longer exist in mainline.
Thanks,
Josh
_zipped-8.33.11.0.bin
I had to fixup a small conflict in WHENCE, but no big deal. Applied
and pushed out.
josh
bytes
> 2 files changed, 1 insertion(+)
> create mode 100644 mellanox/mlxsw_spectrum-13.1620.192.mfa2
Applied and pushed out. Thanks.
josh
On Mon, Mar 12, 2018 at 4:17 PM, Cong Wang wrote:
> On Sun, Mar 11, 2018 at 12:22 PM, Josh Elsasser wrote:
>> init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
>> to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
>> wireless adapter
wer from the -stable and netdev on how to handle bugs in features
that no longer exist in mainline.
Thanks,
Josh
quot;net: network drivers no longer need to implement
ndo_busy_poll()") - 4.9.y
Signed-off-by: Josh Elsasser
---
net/core/dev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8898618bf341..1f50c131ed15 100644
--- a/net/core/dev.c
(of course).
>
> I do think the earlier version (without the
> sizeof-hiding-builting_constant_p) provides a template for a
> const_max() that both you and Rasmus would be happy with, though!
I thought we were dropping support for 4.4 (for other reasons). Isn't
it 4.6 we should be looking at?
--
Josh
On Tue, Sep 26, 2017 at 11:51:31PM +0200, Richard Weinberger wrote:
> Alexei,
>
> CC'ing Josh and Ingo.
>
> Am Dienstag, 26. September 2017, 06:09:02 CEST schrieb Alexei Starovoitov:
> > On Mon, Sep 25, 2017 at 11:23:31PM +0200, Richard Weinberger wrote:
> > >
On Wed, Sep 27, 2017 at 08:51:22AM +0200, Richard Weinberger wrote:
> Am Mittwoch, 27. September 2017, 00:42:46 CEST schrieb Josh Poimboeuf:
> > > Here is another variant of the warning, it matches the attached .config:
> > I can take a look at it. Unfortunately, for these
lwifi/rtl8723defw.bin | Bin 0 -> 27726 bytes
> 2 files changed, 9 insertions(+)
> create mode 100644 rtlwifi/rtl8723defw.bin
Applied and pushed out. Thanks.
josh
Jann Horn's paper, it would seem
> > like PTI doesn't really lock it down fully, right?
>
> Here is the latest (v3) bpf fix:
>
> https://patchwork.ozlabs.org/patch/856645/
>
> I currently have v2 on my 'nospec' branch and will move that to v3 for
> the next update, unless it goes upstream before then.
That patch seems specific to CONFIG_BPF_SYSCALL. Is the bpf() syscall
the only attack vector? Or are there other ways to run bpf programs
that we should be worried about?
--
Josh
uldn't the lfence come much later, *after* reading the variable and
comparing it and branching accordingly?
--
Josh
On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote:
> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
> >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
> >> wrote:
> >> &g
, even if it's hypothetical. How can we
review it if the commit log doesn't describe its purpose?
--
Josh
WHENCE | 1 +
> qed/qed_init_values_zipped-8.37.2.0.bin | Bin 0 -> 867472 bytes
> 2 files changed, 1 insertion(+)
> create mode 100755 qed/qed_init_values_zipped-8.37.2.0.bin
Applied and pushed out.
josh
Add support for Netgear Aircard 779S
Signed-off-by: Josh Hill
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 42565dd..0946808 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb
insertion(+), 1 deletion(-)
>
> Hello Maintainers of linux-firmware.git,
>
> Any feedback about this submission? We sent it two weeks ago, but we
> haven't heard anything.
Thanks for the ping. I missed this one and then confused it with an
older pull request with a similar subject line. I've pulled and
pushed out now.
josh
and fix
the WHENCE file because we merged a commit that changes how symlinks
are handled. All applied and pushed out.
josh
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c| 23
19348 19348 14.79 77.07
I was not sure how to proper attribute Alexander on the ixgbe patch so
please adjust this as necessary.
Thanks!
Josh Hunt (3):
igb: Add UDP segmentation offload support
ixgbe: Add UDP segmentation offload support
i40e: Add UDP segmentation offload support
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/ixgbe
On 10/9/19 5:39 PM, Samudrala, Sridhar wrote:
On 10/9/2019 3:06 PM, Josh Hunt wrote:
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet
On 10/9/19 3:06 PM, Josh Hunt wrote:
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
On 10/9/19 3:44 PM, Alexander Duyck wrote:
On Wed, Oct 9, 2019 at 3:08 PM Josh Hunt wrote:
Alexander Duyck posted a series in 2018 proposing adding UDP segmentation
offload support to ixgbe and ixgbevf, but those patches were never
accepted:
https://lore.kernel.org/netdev
On 10/10/19 2:32 PM, Alexander Duyck wrote:
On Thu, Oct 10, 2019 at 2:17 PM Josh Hunt wrote:
On 10/9/19 3:44 PM, Alexander Duyck wrote:
On Wed, Oct 9, 2019 at 3:08 PM Josh Hunt wrote:
Alexander Duyck posted a series in 2018 proposing adding UDP segmentation
offload support to ixgbe and
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c| 23
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Suggested-by: Alexander Duyck
Signed-off-by: Josh Hunt
---
drivers
19350 15.11 75.44
Josh Hunt (3):
igb: Add UDP segmentation offload support
ixgbe: Add UDP segmentation offload support
i40e: Add UDP segmentation offload support
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12 +---
drive
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12
up tar and flag it as a script.
Hi Aaron
It looks like the netdev archive has the file. Can you try grabbing it
from here?
https://lore.kernel.org/netdev/0e0e706c-4ce9-c27a-af55-339b4eb6d...@akamai.com/2-udpgso_bench.sh
If that doesn't work I can try your tar workaround.
Thanks
Josh
On 10/11/19 8:29 AM, Alexander Duyck wrote:
On Thu, 2019-10-10 at 20:25 -0400, Josh Hunt wrote:
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the i40e driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12
Repost from a series by Alexander Duyck to add UDP segmentation offload
support to the igb driver:
https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/
CC: Alexander Duyck
CC: Willem de Bruijn
Suggested-by: Alexander Duyck
Signed-off-by: Josh Hunt
---
drivers
4 66.45
61824 1201598.88 114019350 19350 15.11 75.44
Josh Hunt (3):
igb: Add UDP segmentation offload support
ixgbe: Add UDP segmentation offload support
i40e: Add UDP segmentation offload support
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
drivers/net
Based on a series from Alexander Duyck this change adds UDP segmentation
offload support to the igb driver.
CC: Alexander Duyck
CC: Willem de Bruijn
Signed-off-by: Josh Hunt
---
drivers/net/ethernet/intel/igb/e1000_82575.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c| 23
On Thu, Oct 17, 2019 at 5:33 AM Bowers, AndrewX
wrote:
>
> > -Original Message-
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Josh Hunt
> > Sent: Friday, October 11, 2019 9:54 AM
> > To: netdev@vger.kernel.org;
ive Project
We were investigating a problem in this area a few months back (it
turned out to be something else), but were wondering if retrans_out,
lost_out, and sacked_out should be cleared in tcp_rtx_queue_purge()? I
meant to get back to it, but it got buried and this just thread jogged
my memory...
--
Josh
rtl_nic/rtl8153b-2.fw | Bin 0 -> 1088 bytes
> 5 files changed, 11 insertions(+)
> create mode 100644 rtl_nic/rtl8153a-2.fw
> create mode 100644 rtl_nic/rtl8153a-3.fw
> create mode 100644 rtl_nic/rtl8153a-4.fw
> create mode 100644 rtl_nic/rtl8153b-2.fw
Applied and pushed out.
josh
for X550EM_x SFP+")
Looks like you’re right. Want me to respin with an additional “Fixes” tag?
- Josh
quot;)
Signed-off-by: Josh Elsasser
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 10dbaf4f6e80..9c42f741ed5e 100644
--- a/
can actually be non-NULL and make forward progress when the
hashtable needs to shrink.
Fixes: da20420f83ea ("rhashtable: Add nested tables")
Signed-off-by: Josh Elsasser
---
lib/rhashtable.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rh
oversight the hashtable dodged the
reschedule loop.
- Josh
and RX, it appears to negotiate a new pair every 3 to 3.5
billion packets. It doesn't appear to be ripping down old SAs. What
happens when available SA slots run out?
Joshua Coombs
GWI
office 207-494-2140
www.gwi.net
On Mon, Oct 15, 2018 at 11:45 AM Josh Coombs wrote:
>
> And confi
I see it reusing SAs, so I'm good.
Joshua Coombs
On Wed, Oct 17, 2018 at 9:45 AM Josh Coombs wrote:
>
> I've got wpa_supplicant working with macsec on Fedora, my test bed has
> shuffled 16 billion packets so far without interruption. I am a bit
> concerned that I'
The "send an email to i...@cavium.com" offer may
> (or may not) be sufficient for the letter of the law. But it seems
> both fragile and prone to subjective frustrations and delays for
> users to obtain the sources at some future date.
I agree with John here, but I also believe the patch is better than
the current text in the upstream repo. I've committed it and pushed
it out. If there are improvements to be made on source availability,
we can take those in a different patch.
Thank you for taking this seriously and responding quickly.
josh
On Jan 23, 2019, at 7:40 PM, Josh Elsasser wrote:
> On Jan 23, 2019, at 7:08 PM, Herbert Xu wrote:
>
>> Thanks for catching this!
>>
>> Although I think we should fix this in a different way. The problem
>> here is that the shrink cannot proceed because there wa
us on napi_id
instead of socket")
Signed-off-by: Josh Elsasser
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 82f20022259d..d1043d49979c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8712,7 +8712,9 @@ int init_dummy_net
Jeff Kirsher wrote:
> No need to re-spin the patch, just reply with the additional "Fixes"
> tag and if patchwork does not pick it up, I will add it to the patch I
> have in my tree for validation and review.
Thanks, let’s try that.
Fixes: e23f33367882 ("ixgbe: Fix 1G and 10G link stability for
On Thu, Dec 13, 2018 at 3:45 PM Shalom Toledo wrote:
>
> This new firmware contains: * New packet traps for discarded packets * Secure
> firmware flash bug fix * Fence mechanism bug fix * TCAM RMA bug fix
> Signed-off-by: Shalom Toledo
Applied and pushed out.
josh
ll \
u32 match u8 0 0 \
action mirred egress mirror dev "$eif"
# eif to sif
tc qdisc add dev "$eif" ingress
tc filter add dev "$eif" parent : \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev "$sif"
# Bring up the interfaces:
echo "* Light tunnel NICS"
ip link set "$sif" up
ip link set "$dif" up
ip link set "$eif" up
echo " --=[ MACSec Up ]=--"
---
Josh Coombs
u32 to matchall didn't change the performance. Going
back to the four machine test bed, again removing macsec and just
bridging through radically decreased the throughput to around 8Mbits.
Flip on macsec for the bridge and 1.3Gbits?
On Tue, Oct 9, 2018 at 11:58 AM Josh Coombs wrote:
>
>
trip the issue there.That should determine if it's macsec
itself, or an interaction between macsec and traffic control.
Joshua Coombs
GWI
office 207-494-2140
www.gwi.net
On Wed, Oct 10, 2018 at 12:39 PM Cong Wang wrote:
>
> On Wed, Oct 10, 2018 at 8:54 AM Josh Coombs wrote:
set "$dif" up
ip link set "$eif" up
# Set IP
ifconfig $eif 192.168.211.1/30
echo " --=[ MACSec Up ]=--"
On Thu, Oct 11, 2018 at 10:05 AM Josh Coombs wrote:
>
> I'm actually leaning towards macsec now. I'm at 6TB transferred in a
> double hop, no ma
port 1 sa 0 pn 1 on key 01 "$rxkey"
ip link set "$eif" type macsec encrypt on
# Bring up the interfaces:
echo "* Light tunnel NICS"
ip link set "$dif" up
ip link set "$eif" up
# Set IP
ifconfig $eif 192.168.211.1/30
Once you can ping across th
On Sun, Oct 14, 2018 at 4:24 PM Sabrina Dubroca wrote:
>
> 2018-10-14, 10:59:31 -0400, Josh Coombs wrote:
> > I initially mistook this for a traffic control issue, but after
> > stripping the test beds down to just the MACSec component, I can still
> > replicate the iss
ven't tested Gentoo's ebuilds yet to see if they do.
Josh Coombs
On Sun, Oct 14, 2018 at 4:52 PM Josh Coombs wrote:
>
> On Sun, Oct 14, 2018 at 4:24 PM Sabrina Dubroca wrote:
> >
> > 2018-10-14, 10:59:31 -0400, Josh Coombs wrote:
> > > I initially mistook t
after sending inner IP fragmented traffic.
> - Issues in the following FW flows:
> SD VLAN update, TX packet drop, packet padding flow, vlan add/remove.
>
> Signed-off-by: Sudarsana Reddy Kalluru
> Signed-off-by: Ariel Elior
> Signed-off-by: Rahul Verma
Applied and pushed out.
josh
> liquidio/lio_23xx_nic.bin | Bin 1271456 -> 1287264 bytes
> liquidio/lio_410nv_nic.bin | Bin 1265368 -> 1281464 bytes
> 5 files changed, 4 insertions(+), 4 deletions(-)
Pulled and pushed out. Thanks.
josh
I'm worried about, it's all of them. There
are a lot of possibilities, with all the different configs, and arches.
Flags are usually added for a good reason, so one randomly missing flag
could have unforeseen results.
And I don't have any visibility into how GCC decides which flags to
drop, and when. But the docs aren't comforting.
Even if things seem to work now, that could (silently) change at any
point in time. This time objtool warned about the missing frame
pointer, but that's not necessarily going to happen for other flags.
If we go this route, I would much rather do -fno-gcse on a file-wide
basis.
--
Josh
6f20 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_run()")
Reported-by: Randy Dunlap
Reported-by: Arnd Bergmann
Signed-off-by: Josh Poimboeuf
---
include/linux/compiler-gcc.h | 2 --
include/linux/compiler_types.h | 4
kernel/bpf/core.c | 10 +++---
3
On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote:
> On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrote:
> > Objtool decodes instructions and follows all potential code branches
> > within a function. But it's not an emulator, so it doesn't
1 - 100 of 232 matches
Mail list logo
