Date: Thu, 29 Oct 2020 22:39:39 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: "John-Mark Gurney" <jmg@funkthat.com> Cc: "Carsten =?utf-8?q?B=C3=A4cker?=" <carbaecker@gmx.de>, freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> In-Reply-To: <20201029213622.GM31099@funkthat.com> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <D8CE4762-4D94-47C7-A8D1-6C537766813B@FreeBSD.org> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> <20201029213622.GM31099@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Oct 2020, at 22:36, John-Mark Gurney wrote:
> Kristof Provost wrote this message on Thu, Oct 29, 2020 at 21:30
> +0100:
>> On 29 Oct 2020, at 16:30, Carsten Bäcker wrote:
>>> Sure, i am willing to help.
>>>
>>> Device is a Raspberry Pi 3B (not +), using the onboard-ethernet.
>>> I attached a bunch of information.
>>>
>>> Configuration is stripped down to the minimum required to reproduce
>>> the
>>> problem.
>>>
>> Okay, so that???s an SMC2 LAN9514_ETH device.
>> That???s the dev/usb/net/if_smsc.c driver.
>>
>> However, before we dig into that driver we should make sure that
>> we???re
>> really looking at a checksum problem.
>> It???s entirely normal for TX checksums to be incorrect when logged
>> on
>> the sending host itself (if the hardware does checksum offloading the
>> checksum in the packet sent to the MAC is incorrect, and left to the
>> hardware to fix).
>>
>> So, can you confirm that the `"[bad udp cksum 0xe58a -> 0x482d!]` you
>> reported was on an inbound packet? And let???s be safe: try to
>> capture
>> packets on a different machine. That???ll give us the true packet,
>> after
>> the hardware has done checksum calculations.
>
> One interesting point is that the smsc driver claims to not do TX
> offload,
> and a brief check shows that it doesn't allow a user to set the
> TXCSUM.
>
It does seem to do RX offload, and the comments in the driver suggest
some .. ahem, creative hardware behaviour:
/* The checksum appears to be simplistically calculated
* over the udp/tcp header and data up to the end of the
* eth frame. Which means if the eth frame is padded
* the csum calculation is incorrectly performed over
* the padding bytes as well. Therefore to be safe we
* ignore the H/W csum on frames less than or equal to
* 64 bytes.
*
* Ignore H/W csum for non-IPv4 packets.
*/
It’s not impossible that there’s some more issues like that in the
hardware, or even that there are different chip revisions out there.
That also matches up with `ifconfig ue0 -rxcsum` fixing things.
Best regards,
Kristof
From owner-freebsd-arm@freebsd.org Fri Oct 30 20:21:11 2020
Return-Path: <owner-freebsd-arm@freebsd.org>
Delivered-To: freebsd-arm@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id B343545A4E5;
Fri, 30 Oct 2020 20:21:11 +0000 (UTC) (envelope-from dsl@mcusim.org)
Received: from trac.mcusim.org (trac.mcusim.org [176.58.93.53])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4CNDGZ0H4Mz4Rbn;
Fri, 30 Oct 2020 20:21:09 +0000 (UTC) (envelope-from dsl@mcusim.org)
Received: from x230.ds (unknown [83.26.214.190])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by trac.mcusim.org (Postfix) with ESMTPSA id 9EBB651006;
Fri, 30 Oct 2020 21:21:01 +0100 (CET)
Date: Fri, 30 Oct 2020 21:21:00 +0100
From: Dmitry Salychev <dsl@mcusim.org>
To: freebsd-hackers@freebsd.org
Cc: freebsd-arm@freebsd.org
Subject: Kernel debugging using Remote GDB on ARM
Message-ID: <20201030202100.GA87402@x230.ds>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Rspamd-Queue-Id: 4CNDGZ0H4Mz4Rbn
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.84 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[];
ARC_NA(0.00)[];
RECEIVED_SPAMHAUS_PBL(0.00)[83.26.214.190:received];
FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[];
R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain];
TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.004];
NEURAL_HAM_MEDIUM(-0.98)[-0.978];
NEURAL_HAM_SHORT(-0.06)[-0.058]; RCPT_COUNT_TWO(0.00)[2];
DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject];
FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[];
MIME_TRACE(0.00)[0:+];
ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US];
RCVD_TLS_ALL(0.00)[];
MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers];
RCVD_COUNT_TWO(0.00)[2]
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.33
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>;
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2020 20:21:11 -0000
Hi,
Is it possible to debug kernel with remote GDB on an ARM target? I'm talking
about BeagleBone Black. I've tried to compile with:
options KDB
options DDB
options GDB
but there's only DDB available:
# sysctl debug.kdb.available
debug.kdb.available: ddb
I've also tried to follow [1], but never seen
"Next trap will enter GDB remote protocol mode". Am I missing something?
Regards,
Dmitry
[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55713894-A896-4F12-ABB9-93DFEB2F16B9>