From owner-freebsd-net@FreeBSD.ORG Fri May 1 22:22:03 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B1DC751 for ; Fri, 1 May 2015 22:22:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F13221519 for ; Fri, 1 May 2015 22:22:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t41MM2ZP016976 for ; Fri, 1 May 2015 22:22:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Fri, 01 May 2015 22:22:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: david.keller@litchis.fr X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:22:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #10 from david.keller@litchis.fr --- Intel device Errata 17 (http://www.intel.fr/content/dam/www/public/us/en/documents/specification-updates/82574-gbe-controller-spec-update.pdf) says: > When using TSO, a situation can occur where a PCIe MRd request is repeated with > the same address, resulting in data corruption. At the end of the TCP packet, > the Tx DMA hangs because the length doesn't match. This can only occur when > the following are true: > * The first buffer of the packet is larger than [3 * (max_read_request - 4)]. > * There is a 4 KB boundary within 64 bytes following the end of the header bytes in > the buffer On my device, PCIe max_read_request is 512. Hence first buffer has to be <= 1524. Interface mtu is 9000. Hence it seems to me that the first buffer can be greater than the 1524 if the FreeBSD stack doesn't split header into a dedicated mbuf The dma alignement requirement is not met on bus_dma_tag_create() where alignement argument is 1. (https://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?view=markup#l3260). Maybe bus_dma_tag_create() should use an alignement of 128 bytes as explained in errata: > The alignment of the buffer containing the headers should be such that there is no > 4 KB boundary within 64 bytes following the end of the header bytes. Assuming > standard > Ethernet/IP/TCP headers of 54 bytes, this means that the buffer should > not start 54-118 bytes before a 4 KB boundary. For example, 128-byte alignment > for this buffer could be used to fulfill this condition -- You are receiving this mail because: You are the assignee for the bug.