From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:53:19 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 4BA1C28D for ; Tue, 27 Aug 2013 06:53:19 +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 B21E52FAA for ; Tue, 27 Aug 2013 06:53:18 +0000 (UTC) Received: (qmail 11749 invoked from network); 27 Aug 2013 07:35:21 -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 07:35:21 -0000 Message-ID: <521C4CD9.4050308@freebsd.org> Date: Tue, 27 Aug 2013 08:53:13 +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: Thomas Skibo 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> In-Reply-To: <521BD531.4090104@sbcglobal.net> 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 06:53:19 -0000 On 27.08.2013 00:22, Thomas Skibo wrote: > On 8/26/13 2:11 PM, Andre Oppermann wrote: >> >> Can you try this patch see check if it makes a difference on the bitfield? > > 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. 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. On LP64 all is fine. On i386 it turns out to be fine too because doesn't care. 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. 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. -- Andre Index: sys/mbuf.h =================================================================== --- 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 }; /*