From owner-freebsd-arm@FreeBSD.ORG Mon Jun 30 17:41:24 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23493BC1 for ; Mon, 30 Jun 2014 17:41:24 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D97A02115 for ; Mon, 30 Jun 2014 17:41:23 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id at1so7316593iec.28 for ; Mon, 30 Jun 2014 10:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8zk5+Rx9Huu17VehQnoc5nMKpEME7kCaRt14oSEiaOk=; b=NVMu30pweezYf1+dirtnjj6OoRxw8NSCyRnoJljTwzHDcpsSLxBhRdlBcqX7uGqhH6 NxC9mIObYU0dI7Y9oTw0fMwvmDxaiCOupWtcpC/SPefn8we64Of2lJX093oZUGeH3Q80 EzoW+oUMMSvsIWU80zWGVw/oSuE/njnCsEGtnMuoJHYeVYq3g6jSD898RWwH7RR7Gb9d 6bDtxmpY8QP7LjKtn8/rzwbjJCYlw1LlDnoUKVgsuR0V4DlMQKNG/rMWySnYyw1U+2Gw wksTdojYbttliecXxJVqEhpc/52Mff0YSfB+13B3QtZC898nOAwN95F006z8F+A0yOMy o4nA== X-Gm-Message-State: ALoCoQmOTSThy6aP5sEq42Z2RjwfDtOxyxJhXZ2pjtoFJgDFi7wnVzEPPlKfqMOvJ6J8/SgneYoV X-Received: by 10.42.203.202 with SMTP id fj10mr3960339icb.86.1404150077769; Mon, 30 Jun 2014 10:41:17 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o2sm26585704igp.12.2014.06.30.10.41.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 10:41:17 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: arm alignment faults... From: Warner Losh In-Reply-To: <20140630131126.GB55631@cicely7.cicely.de> Date: Mon, 30 Jun 2014 11:41:25 -0600 Message-Id: <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> <20140629054039.GP1560@funkthat.com> <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> <20140630131126.GB55631@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:41:24 -0000 --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 30, 2014, at 7:11 AM, Bernd Walter = wrote: > On Sun, Jun 29, 2014 at 10:33:59AM -0600, Warner Losh wrote: >>=20 >> On Jun 28, 2014, at 11:40 PM, John-Mark Gurney = wrote: >>=20 >>> Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: >>>>=20 >>>> On Jun 28, 2014, at 10:52 PM, Adrian Chadd = wrote: >>>>=20 >>>>> On 28 June 2014 21:01, John-Mark Gurney wrote: >>>>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 = -0700: >>>>>>> On 28 June 2014 20:38, John-Mark Gurney = wrote: >>>>>>>> So, one of the little projects I'd like to see is the removal = of >>>>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause = the use >>>>>>>> of bouncing durning DMA ops on all ethernet frames... >>>>>>=20 >>>>>> Now that I think about it, total removal may not be necessary, = just >>>>>> the requirement to use it... If the ethernet dma engine can do = half >>>>>> word aligned dma, then there would be benifit on those to keep >>>>>> ETHER_ALIGN... >>>>>>=20 >>>>>>> Well, as long as you're not doing it by forcing the various CPUs = to >>>>>>> handle unaligned accesses. >>>>>>=20 >>>>>> Hard to do on armv4 which I don't believe supports unaligned = access... >>>>>>=20 >>>>>>> The cost of those unaligned accesses on some CPUs that support = them is >>>>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm = back >>>>>>> when looking to migrate stuff to ARM and it wasn't very quick. >>>>>>=20 >>>>>> I plan on fixing the TCP/IP stack to copy data to an aligned = buffer >>>>>> (maybe only if the original buffer isn't aligned) on the stack = when >>>>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying = the >>>>>> entire packet is cheaper than copying 20 bytes or so... >>>>>=20 >>>>> There's lots of other stupid corner cases that screw you. >>>>>=20 >>>>> VLAN headers add extra bytes. >>>>>=20 >>>>> 802.11 headers can offset things depending upon the 802.11 frame = type >>>>> (3-addr, 4-addr, vlan, no vlan, etc.) >>>>>=20 >>>>> There's no guarantee all ethernet DMA engines can do the alignment = as >>>>> required. :( >>>>=20 >>>> The ate driver for Atmel?s AT91RM9200 is one such beast. >>>=20 >>> Are you sure? The tag for data says alignment 1: >>> if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, >>> BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, = MCLBYTES, >>> 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, = &sc->mtag)) >>>=20 >>> Or is that a limitation on the parent? >>=20 >> It is a limitation in hardware. You have to DMA to a 4 byte boundary. = That might be a bug in the above line though? >=20 > It is a limitation of the AT91RM9200. > More recent ate hardware (e.g. AT91SAM9260) don't have this = limitation. Yea, the problem is that the packet has to start on a % 4 =3D=3D = 0boundary, which means the ether header is aligned, but nothing else in = the IP header is aligned, so bad things happen. The lame thing we did in = the ate driver was to copy the whole packet. A smarter thing to do would = be to just do a m_pullup() of the IP header. The even smarter thing to = do is to limit this to the AT91RM9200, or make the ate driver at91rm9200 = only and fix the macb(4) driver which currently doesn=92t work at all = for the boards I have. On the SAM9 SoCs we can do a smart thing and have = the DMA start % 4 =3D=3D 2, which naturally aligns the headers that are = assumed to be naturally aligned, at least in the NFS root boot code = (which IIRC was the only thing I hit where any of this matters). Warner --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTsaFFAAoJEGwc0Sh9sBEAFDIP/2CD46M1/Utd827ZghHHxJRW AeH/MDqx9oDzxgdt0WFfOTa9WK8Got3QHmgPCnLRb3jB/d8XHe1g3ElNK5LkyviK 7UDt38I+pU8ICbJNRGWnE3nyMYY9FB+0WHUBsfJYYJLFfF8ZfDnhWXCxvOGvaQsX Ew8AhJ6FQFrNZR8ifZVZBroJTg89MLKhp9MeLIeNjdHR4yo5uri8cmOt4mkfujsy hw5L+CduCThYUD/wO4mZ0Lj0xKbpwTF+uiX9qK+QDF7COiWXC98qpntjmfh3AXOE S0qZTZ8aq7J4r6Nc4CjhUOAX7PeM2Idy53lDpo8AfPbM5tL2xz/23/nztKM8+1Uk 8clS82NCveUCW/4ijvyXdDS8GAkhIXjZfA1TzL5yTOiaRCMD6neEi/heDi9xxJQA wD6F7uLONguMBK3nQhZiQqdIaly0jQjjo4dndm26E8wK3LKGXyLrGI3QySyI6nU8 pbNsvavq8awboBnU8OLP5JgfeRN6kD50CcRvbXruSFP5D887IBYt+HKcF8bMm578 j4Y6ae1VNjbSbu0zFaqHRvzB9EQSNlcM3XMT2GvnauwNSai7fB+PAo3pfKI1Afsn 86Yq4r6HEf9V4Hxn+WX3c6iO0uvDnGYjs+9cdpjqEtS/PQQcpkOzBMQkI2am8Mmt KYIrPS1y7lEe3gn42hoj =pPNx -----END PGP SIGNATURE----- --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224--