From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 14:23:45 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 8EB1222F for ; Tue, 27 Aug 2013 14:23:45 +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 F3B6B2B1F for ; Tue, 27 Aug 2013 14:23:44 +0000 (UTC) Received: (qmail 13884 invoked from network); 27 Aug 2013 15:05:44 -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 15:05:44 -0000 Message-ID: <521CB66B.9020806@freebsd.org> Date: Tue, 27 Aug 2013 16:23:39 +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: Michael Tuexen 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: 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 14:23:45 -0000 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. >> >> 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. > > Done. r254954 with your patch applied runs fine on a RPi. Does the CTASSERT trigger if the padding in m_hdr is not there? -- Andre