From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:24:18 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 4E442BE3 for ; Tue, 27 Aug 2013 13:24:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B9212748 for ; Tue, 27 Aug 2013 13:24:17 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id 17so7585280iea.29 for ; Tue, 27 Aug 2013 06:24:17 -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=1CJ92Z8C3uJUA56ZtWCRRe4lnkPP9fKxjRfSwJFgSqI=; b=dWYtvAMVQj+AiOm+sHTaFHc18hixW0w/YUfcAvBGUOv3rNL2R6YvSOTNiD5NEBsIQT iG+vZnrzJL1WgjEGMFRh3adntUGK6ytoYlx2UA7er7Q48huKmXa0VjR14LVP2Sl9a1/z Z5ZoXd9w2coReeLBXnM1h5Oal8A8eNAAqm5AIlyK82x/VTomAz/6N38TiYmhp+JoRfPY LA25zRURTgOMnLhDdbHUg2tUuBw3M+5OHWcaaBbYJBmV9jhsBeEKrFoVlfhRnvmDzKtB HVkyy+4HsMtyRf0yoGeU0v4eh9NF/Zi0itOAwbtMAAuV+hUdTcsKzZTjYAIcQYkD3Y6K RZWQ== X-Gm-Message-State: ALoCoQnjQAY/s4hy25Zku7d1/j3gv8LGfX6tZ1SDSGhesFxesKacHHwlbWIwpl8xe7IXYCRVDdr5 X-Received: by 10.50.26.36 with SMTP id i4mr10041250igg.33.1377609856349; Tue, 27 Aug 2013 06:24:16 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id w4sm24365505igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 06:24:15 -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: <521C4CD9.4050308@freebsd.org> Date: Tue, 27 Aug 2013 07:24:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <40769440-B167-4817-9855-1CAB09081AF8@bsdimp.com> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1085) 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 13:24:18 -0000 On Aug 27, 2013, at 12:53 AM, Andre Oppermann wrote: > On 27.08.2013 00:22, Thomas Skibo wrote: >> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>=20 >>> Can you try this patch see check if it makes a difference on the = bitfield? >>=20 >> Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a >> struct pkthdr not being 64-bit aligned. There are several 64-bit = fields in there. >=20 > The problem is the disconnect between the definition of MLEN and MHLEN = and > the effective size/padding of struct mbuf. That's the true bug. >=20 > On LP64 all is fine. On i386 it turns out to be fine too because = doesn't > care. >=20 > MLEN and MHLEN are incorrectly derived. In fact they should be = derived from > stuct mbuf where this padding would be taking into account. However = the way > it is structured right now it that would create a circular dependency. >=20 > 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 > Andre >=20 > Index: sys/mbuf.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/mbuf.h (revision 254953) > +++ sys/mbuf.h (working copy) > @@ -94,6 +94,9 @@ > int32_t mh_len; /* amount of data in this mbuf = */ > uint32_t mh_type:8, /* type of data in this mbuf */ > mh_flags:24; /* flags; see below */ > +#if defined(__ILP32__) > + uint32_t mh_pad; /* pad to 64 bit alignment */ > +#endif > }; >=20 > /* There should be a CTASSERT() here to make sure there's no mismatch... Warner=