From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 11:49:05 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 2CF92165 for ; Tue, 27 Aug 2013 11:49:05 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB3DD2164 for ; Tue, 27 Aug 2013 11:49:04 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id my10so1640858bkb.1 for ; Tue, 27 Aug 2013 04:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dg1voK0bg7hxAeVGRZvD8ubuqvaxIk3uDfEvrcUxeFk=; b=BI2ogSab1GXaXycG2wezLJZQIHbEKJN+0bWaX351Vd1WFRIJpGlX8On0hTEU4xYQJJ 89GBPtc96zjeGbD3SmmdwiFHkIjTmrZmxl9F/1orH7TKQp+jRaqzgp2GvIBwyePJI+ff AIYN++UEU9lmf7vgY4lKHiyfbjeXLotq/pS4P9nYN5D7WUpbPnmnvjXE6oUZ5uE8CWvi bvsx1URHBGrFoKvvtlMrPoMswE8bpU7ome2f2LK9NgbyVJZqcAzzcZvpCm+72Erp8FGw LECpM669uWl2ZogCGtOmRojZ6vugvbg4f+e4J87rYQvTO7qg0TMaKr4N1K38SIQgeOUC 8VUA== X-Gm-Message-State: ALoCoQnjjIeXJOY1UYcMHR8fUHL+AfdsL9Qw25MVV9gXCYwGWqNpSEPyXFx47QytnpIbF35YM0gC X-Received: by 10.204.234.5 with SMTP id ka5mr3540059bkb.5.1377604142260; Tue, 27 Aug 2013 04:49:02 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id pk7sm4292702bkb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 04:49:01 -0700 (PDT) Message-ID: <521C922B.6010200@semihalf.com> Date: Tue, 27 Aug 2013 13:48:59 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann 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> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> In-Reply-To: <521C87FF.8010100@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 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 11:49:05 -0000 On 27.08.2013 13:05, Andre Oppermann wrote: > On 27.08.2013 11:38, Michael Tuexen wrote: >> On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: >> >>> 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 >>> }; >> >> OK. It doesn't work. The reason is, that __ILP32__ is not defined... At >> lease I don't see it anywhere in the BSD stack. So I'm currently >> rebuilding >> with #if !defined(__LP64__) instead. I'll let you know... > > Thanks. I've changed the test accordingly. > > While doing the CTASSERTs to prevent such an incident in the future I > stumbled > across a bit of evil name space pollution in mbuf.h. It is impossible > to take > sizeof(struct m_ext) because "m_ext" is redefined to point into struct > mbuf. > > In addition to the alignment fix I've solved the namespace issues with > m_ext > and the stupidly named struct pkthdr as well and properly prefixed > them. The > fallout from LINT was zero (as it should be). > > http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff > > Please test. > Hello Andre. Works for me. Best regards Zbyszek Bodek