Am Montag, 20. Juli 2015, 14:14:59 schrieb Herbert Xu:
> On Fri, Jul 17, 2015 at 05:38:30PM +0200, Wolfgang Walter wrote:
> > eth1 stops sending with the patch after some time
> > disabling gro on eth0 helps
> > disabling tso or gso on eth0 and/or eth1 or both does not help
> >
> > eth0 and eth1 are both intel I350.
>
> What does ethtool -k eth1 say?
With TSO enabled:
# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
hw-switch-offload: off [fixed]
>
> Can you confirm that disabling tso on eth1 does not help?
Disabling TSO on eth1 does not help.
>
> Because the most plausible explanation is that we're feeding
> some bogus TSO packet to the hardware causing a tx lockup.
I run the unpatched 4.1.2 again since saturday without look. With your patch
the network card hangs within 10 minutes or so.
On the other hand I run the the patched kernel on serveral other routers (same
hardware, by the way) without problems.
So maybe the problem is that the former one routes GRE-tunnel-packets which
contains ISATAP packets. I don't know how deep GRO/GSO inspects a packet.
>
> But in any case if it is a hardware lockup then it's no longer
> just a pure software bug. No matter what we do in the stack
> the hardware should not lock up (unless of course we're feeding
> it something that's completely bogus).
>
> If we can't figure this out then the safest solution would be
> to disable tunnel GRO completely because it's broken as it stands.
>
> Cheers,
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
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
