From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 15:12:31 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 739E5A6D; Tue, 27 Aug 2013 15:12:31 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0696E2E57; Tue, 27 Aug 2013 15:12:31 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 34F611C0C0695; Tue, 27 Aug 2013 17:12:29 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521CB66B.9020806@freebsd.org> Date: Tue, 27 Aug 2013 17:12:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85F67DE2-701E-464B-8A9D-6A47C3B6C461@freebsd.org> 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> <521CB66B.9020806@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1508) 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 15:12:31 -0000 On Aug 27, 2013, at 4:23 PM, Andre Oppermann wrote: > On 27.08.2013 15:29, Michael Tuexen wrote: >> On Aug 27, 2013, at 1:05 PM, Andre Oppermann = wrote: >>> Thanks. I've changed the test accordingly. >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >>>=20 >>> Please test. > > >> Done. r254954 with your patch applied runs fine on a RPi. >=20 > Does the CTASSERT trigger if the padding in m_hdr is not there? Yepp: /usr/home/tuexen/head/sys/kern/uipc_mbuf.c:91:1: error: static_assert = failed "compile-time assertion failed" CTASSERT(sizeof(struct mbuf) =3D=3D MSIZE); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/home/tuexen/head/sys/sys/systm.h:100:21: note: expanded from macro = 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion = failed") ^ ~ 1 error generated. Best regards Michael >=20 > --=20 > Andre >=20 >=20