From: René van Dorst
Modify mtk_gmac0_rgmii_adjust() so it can always be called.
mtk_gmac0_rgmii_adjust() sets-up the TRGMII clocks.
Signed-off-by: René van Dorst
Signed-off-By: David Woodhouse
Tested-by: Frank Wunderlich
---
On Mon, 2020-04-06 at 15:25 +0200, Frank Wunderlich wrote:
> h
On Tue, 2019-06-04 at 02:15 +, Bshara, Nafea wrote:
> Andrew,
>
> Sent from my iPhone
>
> On Jun 3, 2019, at 6:52 PM, Andrew Lunn wrote:
>
> > > Any "SmartNIC" vendor has temptation of uAPI-level hand off to the
> > > firmware (including my employer), we all run pretty beefy processors
> >
On Fri, 2019-04-12 at 12:26 +0800, Jason Wang wrote:
> Yes, you can refer:
>
> 1) Qemu hw/virtio/vhost.c or hw/net/vhost_net.c
>
> 2) dpdk drivers/net/virtio/virtio_user/vhost_kernel_tap.c
>
> DPDK code seems more compact.
>
> Basically, the setup of TUN/TAP should be the same, then userspace n
On Thu, 2019-04-11 at 15:22 +0800, Jason Wang wrote:
> If you care about userspace performance, you may want to try vhost + TAP
> instead. I admit the API is not user friendly which needs to be improved
> but then there will be no syscall overhead on packet transmission and
> receiving, and even
On Thu, 2019-04-11 at 17:04 +0800, Jason Wang wrote:
> Btw, forget to mention, I modify your patch to use
> netif_stop/wake_subqueue() instead.
Hm...
--- /usr/src/debug/kernel-5.0.fc29/linux-5.0.5-
200.fc29.x86_64/drivers/net/tun.c2019-03-03 23:21:29.0 +
+++ /home/fedora/tun/tun.c
On Thu, 2019-04-11 at 15:17 +0800, Jason Wang wrote:
> > > Ideally we want to react when the queue starts building rather than when
> > > it starts getting full; by pushing back on upper layers (or, if
> > > forwarding, dropping packets to signal congestion).
> >
> > This is precisely what my firs
On Wed, 2019-04-10 at 17:01 +0200, Toke Høiland-Jørgensen wrote:
> David Woodhouse writes:
>
> > On Wed, 2019-04-10 at 15:42 +0200, Toke Høiland-Jørgensen wrote:
> > > > > That doesn't seem to make much difference at all; it's still dropping
> &g
On Wed, 2019-04-10 at 15:42 +0200, Toke Høiland-Jørgensen wrote:
> > > That doesn't seem to make much difference at all; it's still dropping a
> > > lot of packets because ptr_ring_produce() is returning non-zero.
> >
> >
> > I think you need try to stop the queue just in this case? Ideally we ma
On Wed, 2019-04-10 at 15:01 +0300, David Woodhouse wrote:
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1125,7 +1128,9 @@ static netdev_tx_t tun_net_xmit(struct sk_buff
> *skb, struct net_device *dev)
> if (tfile->flags & TUN_FASYNC)
> k
I've been working on OpenConnect VPN performance. After fixing some
local stupidities I am basically crypto-bound as I suck packets out of
the tun device and feed them out over the public network as fast as the
crypto library can encrypt them.
However, the tun device is dropping packets.
I'm test
On Fri, 2018-12-07 at 21:46 +0100, Paolo Abeni wrote:
> > I wonder if we can declare the common case functions as 'weak' so that
> > the link failures don't happen when they're absent.
>
> I experimented a previous version with alias. I avoided weak alias
> usage, because I [mis?]understood not al
On Wed, 2018-12-05 at 19:13 +0100, Paolo Abeni wrote:
> +/*
> + * We can use INDIRECT_CALL_$NR for ipv6 related functions only if ipv6 is
> + * builtin, this macro simplify dealing with indirect calls with only
> ipv4/ipv6
> + * alternatives
> + */
> +#if IS_BUILTIN(CONFIG_IPV6)
> +#define INDIREC
On Thu, 2018-08-09 at 14:47 +0200, Greg KH wrote:
> On Thu, Aug 09, 2018 at 08:37:13PM +0800, maowenan wrote:
> > There are two patches in stable branch linux-4.4, but I have tested with
> > below patches, and found that the cpu usage was very high.
> > dc6ae4d tcp: detect malicious patterns in tc
this tracking for skbs in receive queue,
since they are not dropped, unless socket is disconnected.
Signed-off-by: Eric Dumazet
Acked-by: Soheil Hassas Yeganeh
Acked-by: Yuchung Cheng
Signed-off-by: David S. Miller
Signed-off-by: David Woodhouse
---
net/ipv4/tcp_input.c | 23
On Sat, 2018-08-04 at 09:05 +0200, Greg KH wrote:
>
> Ok, then it's my fault :)
>
> Odds are it did not apply and so I didn't backport it. If you think it
> should be there, please provide a working backport.
It has whitespace issues but that's about it. Will send a version which
applies cleanl
On Mon, 2018-07-23 at 12:03 -0700, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 23 Jul 2018 09:28:16 -0700
>
> > Juha-Matti Tilli reported that malicious peers could inject tiny
> > packets in out_of_order_queue, forcing very expensive calls
> > to tcp_collapse_ofo_queue() and tcp_prune_
On Sat, 2018-06-16 at 16:27 -0700, David Miller wrote:
> From: "David Woodhouse"
> Date: Sat, 16 Jun 2018 20:52:33 -
>
> >> This Fixes tag shoots the messenger really.
> >>
> >> I suggest to instead use :
> >>
> >> Fix
> This Fixes tag shoots the messenger really.
>
> I suggest to instead use :
>
> Fixes: 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()")
Oh, I hadn't realised how recent that was. Sure, let's blame you instead :)
--
dwmw2
>> Commit 14afee4b609 ("net: convert sock.sk_wmem_alloc from atomic_t to
>> refcount_t") did exactly what it was intended to do, and turned this
>> mostly-theoretical problem into a real one, causing PPPoATM to fail
>> immediately as sk_wmem_alloc underflows and atm_may_send() *immediately*
>> st
On Sat, 2018-06-16 at 03:44 +, Kevin Darbyshire-Bryant wrote:
>
> I can confirm that PPPoA with both vc & llc encapsulations work.
> BR2684 with PPPoE and both vc & llc encapsulations also work. No
> nasty messages noted in dmesg.
Thanks.
> I’m actually gobsmacked at how tolerant TalkTal
to the VCC, in a new member of the
ATM_SKB(skb) structure. Then in atm_pop_raw() subtract precisely that
value instead of the then-current value of skb->truesize.
Fixes: 14afee4b ("net: convert sock.sk_wmem_alloc from atomic_t to refcount_t")
Signed-off-by: David Woodhouse
Tested-by
On Fri, 2018-06-15 at 20:49 +, Kevin Darbyshire-Bryant wrote:
>
> > That does end up being quite hairy. I don't think it's worth doing.
> >
> > This should probably suffice to fix it...
> >
> > Kevin this is going to conflict with the ifx_atm_alloc_skb() hack in
> > the tree you're working
On Fri, 2018-06-15 at 14:44 +0100, David Woodhouse wrote:
>
> > Or simply use a new field in ATM_SKB(skb) to remember a stable
> > truesize used in both sides (add/sub)
>
> Right, that was my second suggestion ("copy the accounted value...").
>
> It's
On Fri, 2018-06-15 at 06:39 -0700, Eric Dumazet wrote:
>
> On 06/15/2018 06:27 AM, Eric Dumazet wrote:
> >
> >
> >
> > On 06/15/2018 05:29 AM, David Woodhouse wrote:
> > >
> > > On Fri, 2017-06-30 at 13:08 +0300, Elena Reshetova wrote:
> &
On Fri, 2017-06-30 at 13:08 +0300, Elena Reshetova wrote:
> diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
> index c1da539..4d97a89 100644
> --- a/include/linux/atmdev.h
> +++ b/include/linux/atmdev.h
> @@ -254,7 +254,7 @@ static inline void atm_return(struct atm_vcc *vcc,int
> trues
On Fri, 2018-04-13 at 19:26 +0200, Christoph Hellwig wrote:
> On Fri, Apr 13, 2018 at 10:12:41AM -0700, Tushar Dave wrote:
> > I guess there is nothing we need to do!
> >
> > On x86, in case of no intel iommu or iommu is disabled, you end up in
> > swiotlb for DMA API calls when system has 4G mem
On Tue, 2018-03-13 at 07:51 -0700, Alexander Duyck wrote:
> Actually the suggestion I had from Don Dutile was that we should be
> looking at creating a pci-stub like driver specifically for those type
> of devices, but without the ability to arbitrarily assign devices.
> Basically we have to white
On Tue, 2018-03-13 at 09:54 +0100, Christoph Hellwig wrote:
> On Tue, Mar 13, 2018 at 08:45:19AM +0000, David Woodhouse wrote:
> Because binding to pci-stub means that you'd now enable the simple
> SR-IOV for any device bound to PCI stub. Which often might be the wrong
> thing
On Tue, 2018-03-13 at 09:16 +0100, Christoph Hellwig wrote:
> On Tue, Mar 13, 2018 at 08:12:52AM +0000, David Woodhouse wrote:
> >
> > I'd also *really* like to see a way to enable this for PFs which don't
> > have (and don't need) a driver. We seem to have
On Mon, 2018-03-12 at 10:23 -0700, Alexander Duyck wrote:
>
> - .sriov_configure = ena_sriov_configure,
> +#ifdef CONFIG_PCI_IOV
> + .sriov_configure = pci_sriov_configure_simple,
> +#endif
> };
I'd like to see that ifdef go away, as discussed. I agree that just
#define pci_sriov_con
On Fri, 2018-03-09 at 10:57 -0500, David Miller wrote:
> From: David Woodhouse
> Date: Fri, 09 Mar 2018 15:31:15 +
>
> > Eschewing a 15% speedup on the basis that "well, even though we've had
> > three of these already for a decade, we're worried tha
On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote:
>
> > > I did performance measurements in the following way:
> > >
> > > Removed those pieces of the packet pipeline that I don't necessarily
> > > need one-by-one. Then measured their effect on small packet
> > > performance.
> > >
>
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
> >
> > The BPF interpreter has been used as part of the spectre 2 attack
> > CVE-2017-5715.
> >
> > A quote from goolge project zero blog:
> > "At this point, it would normally be neces
On Fri, 2017-09-08 at 10:16 -0700, David Miller wrote:
> From: Eduardo Valentin
> Date: Fri, 8 Sep 2017 10:04:09 -0700
>
> >
> > However, this is a clear, the system call, from the net subsystem,
> > has changed in behavior across kernel versions. From application /
> > userspace perspective, ch
On Fri, 2017-07-28 at 08:59 -0700, Stephen Hemminger wrote:
> This includes a bunch of fixups for issues reported by
> lockdep.
> * ethtool routines can assume RTNL
> * send is done with RCU lock (and BH disable)
> * avoid refetching internal device struct (netvsc)
> instead pass it a
On Fri, 2017-04-21 at 15:14 +0200, Hauke Mehrtens wrote:
>
> On 04/20/2017 10:36 PM, David Miller wrote:
> >
> > From: David Woodhouse
> > Date: Thu, 20 Apr 2017 21:14:37 +0100
> >
> > >
> > > I agree, except I don't think you'r
On Thu, 2017-04-20 at 16:07 -0400, David Miller wrote:
>
> I think I have to put the brakes on this patch series, after much
> consideration.
>
> It does not scale if we continually add a hodge-podge of different
> ifdef tests to the UAPI headers in order to prevent mutliple
> definitions.
>
> W
On Sun, 2017-03-12 at 23:00 +0100, Hauke Mehrtens wrote:
> __USE_MISC is glibc specific and not available in musl libc. Only do
> this check when glibc is used. This fixes a problem with musl libc.
> ...
> -/* Coordinate with glibc net/if.h header. */
> -#if defined(_NET_IF_H) && defined(__USE_MISC
On Fri, 2016-11-11 at 21:05 +, Russell King - ARM Linux wrote:
>
> 18:59:38.782818 IP (tos 0x0, ttl 52, id 35619, offset 0, flags [DF], proto
> TCP (6), length 60)
> 84.xx.xxx.196.61236 > 195.92.253.2.http: Flags [S], cksum 0x88db
> (correct), seq 158975430, win 29200, options [mss 1452,
On Wed, 2015-09-23 at 10:58 -0700, David Miller wrote:
> From: David Woodhouse
> Date: Wed, 23 Sep 2015 09:14:09 +0100
>
> > But sure, for now I'll drop this from the series and I can try to
> > convince you separately.
>
> Yes, let's discuss this independ
On Mon, 2015-10-05 at 16:39 -0700, Tom Herbert wrote:
> This patch defines a helper function that drivers can call to check
> if it is able to offload the checksum for a particular packet.
It occurs to me that by itself, this doesn't actually fix the problem.
We'd then need to go over all drivers
On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote:
> it in ACPI circles
> unless we had wider agreement among OSs to use it. AFAIK PRP1 has not
> actually been approved yet in the specification forum, and that it in
> itself is more of a concern for me,as the code has been pushed up
NETIF_F_xx_CSUM? Could we
consider just ditching that check and always using CHECKSUM_PARTIAL, in
the knowledge that we check it before it hits a non-capable driver
anyway? Or do we benefit from doing the software checksum early, due to
improved cache locality when we've probably just cop
, if you can push an implementation
which is grubbing around in the packet then at least *I* don't have to
feel dirty for it... :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
drivers calling skb_checksum_help() for
themselves; we want the pre-filter. Mainly because we *definitely*
don't want drivers calling gso_skb_segment() for themselves in the same
situation — see the comment I posted on Friday about the r8169 instance
of that. ('Re:
> Support the IPv6 hw checksum for RTL8111C and later chips. Note
> that the hw has the limitation for the transport offset. The
> checksum must be calculated by sw, when the transport offset is
> out of the range which the hw accepts.
It would be better to implement this check in a .ndo_feature
Pv6 packets to a NETIF_F_IPV6_CSUM
device, regardless of whether they're *actually* TCP or UDP packets.
That's the problem I'm trying to solve. And then we *can* make full use
of the generic checksum offload (I had it working for ICMPv6 at one
point: http://lists.openwall.net/netd
On Mon, 2015-09-28 at 12:37 -0700, Tom Herbert wrote:
> I think it's easier to just call skb_checksum_help from the driver
> when the packet is actually sent to the device (should be no cost for
> late binding).
That's true for checksum. Not for things like TSO though, and I wonder
if it's worth k
or it.
I do suspect we'll want a bit which says it's *actually* TCP or UDP,
not just 'seeded with a pseudo-header'. That's the important
distinction for NETIF_F_IP_CSUM vs. NETIF_F_HW_CSUM.
--
David WoodhouseOpen Source Technology Centre
d
or UDP checksum. That would be set by our UDP and
TCP sockets, cleared by encapsulation, also set if appropriate by
skb_partial_csum_set().
And then the check in can_checksum_protocol() is trivial and clearly
correct.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
s with ->protocol == ETH_P_IP instead of only
TCP and UDP.
I originally couldn't see how to deal with this except by looking at
the contents of the packet, which sucked. But I think I've found a
somewhat more acceptable approach now:
http://lists.openwall.net/netdev/2015/09/25/85
On Fri, 2015-09-25 at 16:28 +0100, Catalin Marinas wrote:
>
> This only works as long as they target an existing driver with prior DT
> support (usually with reviewed bindings). If they have a new driver and
> only ACPI in mind, I'm pretty sure we'll end up with new insane things.
> That's why we
packets. And the
check in can_checksum_protocol() would just check for that bit.
Signed-off-by: David Woodhouse
---
Since can_checksum_protocol is inline, the compiler ought to know that
it doesn't even need to dereference skb->sk in the case where the
device has the NETIF_F_GEN_CSU
On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
> With "PRP0001", they can skip the _DSD properties review process (not
> that they bother much currently) as long as the existing DT support
> covers their needs.
So no change there then. I take it the smsc911x bindings didn't go
through
On Thu, 2015-09-24 at 15:01 +0100, Lorenzo Pieralisi wrote:
> On Thu, Sep 24, 2015 at 12:52:38PM +0100, David Woodhouse wrote:
>
> [...]
>
> > And think about it... we *really* don't want a given peripheral device
> > to have *different* bindings depending on wheth
On Thu, 2015-09-24 at 05:05 -0700, Eric Dumazet wrote:
>
> Right, netif_skb_features() only has the following checks :
>
> if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
> features &= ~NETIF_F_GSO_MASK;
>
> But now we have .ndo_features_check() we could remove this generic
Hi Catalin,
I understand your concerns, but I'm still not convinced of your
conclusion.
On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote:
> PRP0001 opens the door to any DT-like properties in ACPI and, knowing
> how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if
> we
e.
Then we can stop the masking in cp_start_xmit(), and just WARN if the
maximum is exceeded, which should now never happen.
Finally, Francois Romieu noticed that we didn't even have the right
value for MSSMask anyway; it should be 0x7ff (11 bits) not 0xfff.
Signed-off-by: David Wood
f I'm going to define my own accessors, I'd probably just make them
use (__force __virtio16). But TBH none of the options seemed
particularly pretty to me. I can live with what we have.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.
in the first
place.
Finally, Francois Romieu noticed that we didn't even have the right
value for MSSMask anyway; it should be 0x7ff (11 bits) not 0xfff.
Signed-off-by: David Woodhouse
---
Nice and simple and obvious, right?
So why does it stop TSO from happening at all?
When I call neti
On Wed, 2015-09-23 at 16:56 -0700, Hanjun Guo wrote:
>
> It really depends on the people who writing the ASL code (DSDT),
> I'm not sure if Windows will use _DSD and how to use it, but
> firmware guys may just use the device ID to make the firmware
> to be usable both by Linux and Windows, and tha
On Thu, 2015-09-24 at 00:44 +0200, Francois Romieu wrote:
> David Woodhouse :
> [...]
> > But sure, for now I'll drop this from the series and I can try to
> > convince you separately.
>
> You may as well change the IRQ storm avoidance logic so that it does not
>
On Thu, 2015-09-24 at 00:44 +0200, Francois Romieu wrote:
> David Woodhouse :
> [...]
> > I can shuffle things around if you disagree, but assuming Francois
> > concurs I'd suggest merging patches 1-6 (or just pulling from
> > git://git.infradead.org/users/dwmw
the hardware can handle, and never
telling the net stack that that's our maximum, doesn't seem like such a
good idea...
I think I really am going to stop looking now :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
et_gso_max_size() so it shouldn't happen in the first place.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/81
On Wed, 2015-09-23 at 22:51 +0200, Rafael J. Wysocki wrote:
>
> But if the device ID is assigned already, why would it hurt to
> actually use it?
It doesn't hurt at all, as long as we understand that there was no need
to assign it a device ID at all, at least for Linux's benefit. And as
long as
On Wed, 2015-09-23 at 10:58 -0700, David Miller wrote:
> From: David Woodhouse
> Date: Wed, 23 Sep 2015 09:14:09 +0100
>
> > But sure, for now I'll drop this from the series and I can try to
> > convince you separately.
>
> Yes, let's discuss this independ
ro and use that throughout the code instead of the
hard-coded 'false' for little-endian.
This restores the ABI to match 4.1 and earlier kernels, and makes my
test program work again.
Signed-off-by: David Woodhouse
---
On Wed, 2015-09-23 at 11:09 -0700, David Miller wrote:
On Wed, 2015-08-12 at 17:06 -0500, Jeremy Linton wrote:
>
>
> +static const struct acpi_device_id smsc911x_acpi_match[] = {
> + { "ARMH9118", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, smsc911x_acpi_match);
> +
> static struct platform_driver smsc911x_driver = {
> .prob
On Mon, 2015-09-21 at 17:29 +0100, David Woodhouse wrote:
>
> Did we ever resolve this? AFAICT from inspecting the code the
> virtio_net device still advertises hardware csum capabilities to the
> guest. And accepts packets which need checksumming, calling
> skb_partial_csum_set()
ro and use that throughout the code instead of the
hard-coded 'false' for little-endian.
This restores the ABI to match 4.1 and earlier kernels, and makes my
test program work again.
Signed-off-by: David Woodhouse
---
Or perhaps we should just use (__force u16) and (__force __virtio16)
From: David Woodhouse
After a certain amount of staring at the debug output of this driver, I
realised it was lying to me.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net
From: David Woodhouse
We are seeing unexplained TX timeouts under heavy load. Let's try to get
a better idea of what's going on.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
From: David Woodhouse
I fixed TSO. Hardware checksum and scatter/gather also appear to be
working correctly both on real hardware and in QEMU's emulation.
Let's enable them by default and see if anyone screams...
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/81
From: David Woodhouse
The low 16 bits of the 'opts1' field in the TX descriptor are supposed
to still contain the buffer length when the descriptor is handed back to
us. In practice, at least on my hardware, they don't. So stash the
original value of the opts1 field and get the
From: David Woodhouse
If an RX interrupt was already received but NAPI has not yet run when
the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts
already disabled. Blindly re-enabling them will cause an IRQ storm.
(This is made particularly horrid by the fact that cp_interrupt
From: David Woodhouse
We calculate the value of the opts1 descriptor field in three different
places. With two different behaviours when given an invalid packet to
be checksummed — none of them correct. Sort that out.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c
From: David Woodhouse
When sending a TSO frame in multiple buffers, we were neglecting to set
the first descriptor up in TSO mode.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff
On Tue, 2015-09-22 at 16:45 -0700, David Miller wrote:
> And if we are getting Rx* interrupts with napi_schedule_prep()
> returning false, that's a serious problem. It can mean that the TX
> timeout handler's resetting of the chip is either miscoded or is
> racing with either NAPI polling or this
erent behaviours when given an invalid packet to
be checksummed — none of them correct. Sort that out.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 61 ---
1 file changed, 20 insertions(+), 41 deletions(-)
diff --git a/drivers/net/
On Mon, 2015-09-21 at 22:54 +0200, Francois Romieu wrote:
> David Woodhouse :
> [...]
> > I'm actually having second thoughts about this one since realising that
> > QEMU doesn't implement it correctly. The workaround isn't *that* horrid
> > but it'
On Mon, 2015-09-21 at 23:01 +0200, Francois Romieu wrote:
> Can you pile a patch to replace BUG with WARN_ON_ONCE(1) ?
OK. I can probably contrive a userspace program using AF_PACKET and
PACKET_VNET_HDR to trigger it, too¹ :)
--
dwmw2
¹ http://comments.gmane.org/gmane.linux.network/254981
sm
On Mon, 2015-09-21 at 22:25 +0200, Francois Romieu wrote:
> David Woodhouse :
> > From: David Woodhouse
> >
> > The TX timeout handling has been observed to trigger RX IRQ storms. And
> > since cp_interrupt() just keeps saying that it handled the interrupt,
> &g
On Wed, 2013-01-16 at 18:00 -0500, David Miller wrote:
> From: David Woodhouse
> Date: Wed, 16 Jan 2013 22:34:18 +
>
> > On Wed, 2013-01-16 at 15:54 -0500, David Miller wrote:
> >>
> >> My opinion on this is that the injectors of packets are responsible
>
On Mon, 2015-09-21 at 14:59 +0100, David Woodhouse wrote:
> After which, I think we might be able to turn on TX checksumming by
> default and I also have a way to implement early detection of the TX
> stall I've been seeing.
This is a patch I've been playing with to catch the
From: David Woodhouse
This is a minor optimisation, but as a side-effect it means we can know
precisely which descriptors were already in the ring when we last
prodded it to run.
This will give us a better chance to catch the case where we get a
TxEmpty interrupt when it hasn't act
From: David Woodhouse
When sending a TSO frame in multiple buffers, we were neglecting to set
the first descriptor up in TSO mode.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff
From: David Woodhouse
After a certain amount of staring at the debug output of this driver, I
realised it was lying to me.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net
From: David Woodhouse
The low 16 bits of the 'opts1' field in the TX descriptor are supposed
to still contain the buffer length when the descriptor is handed back to
us. In practice, at least on my hardware, they don't. So stash the
original value of the opts1 field and get the
From: David Woodhouse
We are seeing unexplained TX timeouts under heavy load. Let's try to get
a better idea of what's going on.
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
On Sun, 2015-09-20 at 22:24 -0700, David Miller wrote:
> From: David Woodhouse
> Date: Fri, 18 Sep 2015 00:21:54 +0100
>
> > Unless we reset the RX config, on real hardware I don't seem to
> receive
> > any packets after a TX timeout.
> >
> > Sig
From: David Woodhouse
The TX timeout handling has been observed to trigger RX IRQ storms. And
since cp_interrupt() just keeps saying that it handled the interrupt,
the machine then dies. Fix the return value from cp_interrupt(), and
the offending IRQ gets disabled and the machine survives
From: David Woodhouse
If an RX interrupt was already received but NAPI has not yet run when
the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts
already disabled. Blindly re-enabling them will cause an IRQ storm.
This is somewhat less painful than it was a few minutes ago
On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote:
> The TxDmaOkLowDesc register may tell if the Tx dma part is still
> making any progress. I have added a TxPoll request. See below.
It isn't making any progress. And TxPoll doesn't help. The only thing
I've found that restarts it is to cle
value from cp_interrupt(), but still suboptimal.
Unconditionally leave RX interrupts disabled after the reset, and
schedule NAPI to check the receive ring and re-enable them.
Signed-off-by: David Woodhouse
---
It might seem a little odd to deliberately schedule NAPI when we know
there's goi
te *cp)
netdev_completed_queue(cp->dev, pkts_compl, bytes_compl);
if (TX_BUFFS_AVAIL(cp) > (MAX_SKB_FRAGS + 1))
netif_wake_queue(cp->dev);
+
+ return handled;
}
static inline u32 cp_tx_vlan_tag(struct sk_buff *skb)
--
2.4.3
--
David Woodhouse
On Fri, 2015-09-18 at 02:04 +0100, David Woodhouse wrote:
> On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote:
> > The TxDmaOkLowDesc register may tell if the Tx dma part is still
> > making any progress. I have added a TxPoll request. See below.
>
> I've just ad
On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote:
> The TxDmaOkLowDesc register may tell if the Tx dma part is still
> making any progress. I have added a TxPoll request. See below.
I've just added that into the original TX timeout handler, since that
doesn't seem to be crashing the box f
Unless we reset the RX config, on real hardware I don't seem to receive
any packets after a TX timeout.
Signed-off-by: David Woodhouse
---
Now it does actually recover from the TX timeout, lots of the time.
Sometimes it still hits that IRQ storm, which probably explains the
apparent lockup
This can be called from cp_tx_timeout() with interrupts disabled.
Spotted by Francois Romieu
Signed-off-by: David Woodhouse
---
drivers/net/ethernet/realtek/8139cp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net
1 - 100 of 194 matches
Mail list logo
