From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 17:18:54 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23081887 for ; Tue, 27 Aug 2013 17:18:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D677125FC for ; Tue, 27 Aug 2013 17:18:53 +0000 (UTC) Received: by mail-yh0-f43.google.com with SMTP id z20so1293870yhz.2 for ; Tue, 27 Aug 2013 10:18:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3A+R/xX2V0FkyqAfBBBcPj2CDmknCwnlUJxjyOoVuQ4=; b=fK9kLPqu2XfDWsqkyGWXOagKXZreOzapdhaQPXrCFOfSwmXibTzQxMq5IOa6ongY5J lNfVTVzEVDIKnTalBCCvWzhHGgco5HbX0WOfIUNY0NuQnYlITYINgxkOpYJ+XvFpAxSQ dVr0j2fgT88b0kMfZBo4JbUM9fcTJSGRJNEuLVywLdqWAhmOdme0cdEaRJ1K/dRrs70L 6nrBMrsNQXb+cNXxO520bBRs86LaLaleOW0k7GcwqrQ9XpOnhc0OqsePemuH5iVarkhm o3WyoBd4tB0Edsm+TqdPnRWxKAzyUgNo5CF0l+BeWINAxUDdyhwwMtnXDRYjAvadY4yp katA== X-Gm-Message-State: ALoCoQmEg5lB2da9y7K8oLdvO7tGxOGpB8n0Dl5rkxMIktaBOZbqseg5Dl7qQ8LITlb0a5pJj+Dy X-Received: by 10.236.50.135 with SMTP id z7mr1267172yhb.110.1377622175756; Tue, 27 Aug 2013 09:49:35 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id i28sm25400155yhl.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 09:49:33 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org> Date: Tue, 27 Aug 2013 10:49:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E1F1106-654B-4AEC-B915-F97D95C24E75@bsdimp.com> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> <20130827164055.4a757a13@bender> <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Andre Oppermann 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 17:18:54 -0000 On Aug 27, 2013, at 9:59 AM, Michael Tuexen wrote: > On Aug 27, 2013, at 5:56 PM, Warner Losh wrote: >=20 >>=20 >> On Aug 27, 2013, at 9:40 AM, Andrew Turner wrote: >>=20 >>> On Tue, 27 Aug 2013 07:26:03 -0600 >>> Warner Losh wrote: >>>=20 >>>>=20 >>>> On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote: >>>>=20 >>>>> 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. >>>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> Isn't that a bug with our arm compiler then? >>>=20 >>> No, on ARM EABI the definition of the size of a struct is to be the >>> smallest multiple of its alignment. As we are increasing the = alignment >>> to 8-byte and the struct without this alignment is not a multiple of >>> 8-bytes adding this alignment will pad to struct to use the unused 4 >>> bytes between this and the next struct. >>=20 >> Wrong bug :) >>=20 >> Is it not a bug that __ILP32__ is undefined? > Is it used anywhere? I only found __LP64__ being used... _ILP32 is used in code we got from Solaris. Otherwise, you're right: we = don't use it in the tree. Lots of places use __LP64__ though. Warner=