lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 13 May 2022 07:11:25 +0200 From: Paul Menzel <pmenzel@...gen.mpg.de> To: Joel Stanley <joel@....id.au> Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Dylan Hung <dylan_hung@...eedtech.com>, David Wilder <dwilder@...ibm.com>, netdev@...r.kernel.org, openbmc@...ts.ozlabs.org, David Wilder <wilder@...ibm.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH net v2] net: ftgmac100: Disable hardware checksum on AST2600 Dear Joel, Am 13.05.22 um 01:19 schrieb Joel Stanley: > The AST2600 when using the i210 NIC over NC-SI has been observed to > produce incorrect checksum results with specific MTU values. This was > first observed when sending data across a long distance set of networks. > > On a local network, the following test was performed using a 1MB file of > random data. > > On the receiver run this script: > > #!/bin/bash > while [ 1 ]; do > # Zero the stats > nstat -r > /dev/null > nc -l 9899 > test-file > # Check for checksum errors > TcpInCsumErrors=$(nstat | grep TcpInCsumErrors) > if [ -z "$TcpInCsumErrors" ]; then > echo No TcpInCsumErrors > else > echo TcpInCsumErrors = $TcpInCsumErrors > fi > done > > On an AST2600 system: > > # nc <IP of receiver host> 9899 < test-file > > The test was repeated with various MTU values: > > # ip link set mtu 1410 dev eth0 > > The observed results: > > 1500 - good > 1434 - bad > 1400 - good > 1410 - bad > 1420 - good Sort the values? As some MTUs are good, should a allow list for these values be added? > The test was repeated after disabling tx checksumming: > > # ethtool -K eth0 tx-checksumming off > > And all MTU values tested resulted in transfers without error. > > An issue with the driver cannot be ruled out, however there has been no > bug discovered so far. > > David has done the work to take the original bug report of slow data > transfer between long distance connections and triaged it down to this > test case. > > The vendor suspects this this is a hardware issue when using NC-SI. The fixes line refers > to the patch that introduced AST2600 support. Please wrap the line after 75 characters. Can the problem be reproduced with QEMU? > Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property") > Reported-by: David Wilder <wilder@...ibm.com> > Signed-off-by: Joel Stanley <joel@....id.au> Should the intel-wired-lan folks be put in Cc? > --- > v2 updates the commit message with confirmation form the vendor that from > this is a hardware issue, and clarifes why the commit used in the fixes clarifies > tag was chosen. > > drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c > index caf48023f8ea..5231818943c6 100644 > --- a/drivers/net/ethernet/faraday/ftgmac100.c > +++ b/drivers/net/ethernet/faraday/ftgmac100.c > @@ -1928,6 +1928,11 @@ static int ftgmac100_probe(struct platform_device *pdev) > /* AST2400 doesn't have working HW checksum generation */ > if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac"))) > netdev->hw_features &= ~NETIF_F_HW_CSUM; > + > + /* AST2600 tx checksum with NC-SI is broken */ Does ASPEED have an internal bug for this, so should there be new revisions of the AST2600, the bug can be fixed? > + if (priv->use_ncsi && of_device_is_compatible(np, "aspeed,ast2600-mac")) > + netdev->hw_features &= ~NETIF_F_HW_CSUM; > + I would fancy a note or even warning about this hardware issue. > if (np && of_get_property(np, "no-hw-checksum", NULL)) > netdev->hw_features &= ~(NETIF_F_HW_CSUM | NETIF_F_RXCSUM); > netdev->features |= netdev->hw_features; Kind regards, Paul
Powered by blists - more mailing lists