From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 09:49:36 2013 Return-Path: Delivered-To: freebsd-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 ESMTP id 1A426A5F for ; Tue, 27 Aug 2013 09:49:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F9D62B05 for ; Tue, 27 Aug 2013 09:49:35 +0000 (UTC) Received: (qmail 12878 invoked from network); 27 Aug 2013 10:31:37 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 10:31:37 -0000 Message-ID: <521C762A.2080109@freebsd.org> Date: Tue, 27 Aug 2013 11:49:30 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Turner Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> In-Reply-To: <20130827102810.37e2dfc7@bender> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:49:36 -0000 On 27.08.2013 11:28, Andrew Turner wrote: > On Tue, 27 Aug 2013 08:53:13 +0200 > Andre Oppermann wrote: >> Please try the patch below to confirm. If it fixes your problem for >> now I'm going to commit as an immediate fix while searching for a >> better long term stable solution. >> > > I tried this with a CTASSERT to check if struct m_hdr is the correct > length. In this test the size is incorrect. It appears __ILP32__ is not > defined on ARM. > > I have tested a fix suggested by Hans Petter Selasky where we mark > m_hdr with __aligned(8). With this change I can netboot a PandaBoard. There is no guarantee with __aligned(8) that the padding is included in sizeof(struct m_hdr). It only guarantees that the start of m_hdr is aligned on a 8 byte multiple. In your case it appears that the padding is included. I'm not certain that we can rely on it with both gcc and clang (or some other compiler). -- Andre