From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 21:11:19 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 03FAB99E for ; Mon, 26 Aug 2013 21:11: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 5293C2109 for ; Mon, 26 Aug 2013 21:11:18 +0000 (UTC) Received: (qmail 9807 invoked from network); 26 Aug 2013 21:53:26 -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 ; 26 Aug 2013 21:53:26 -0000 Message-ID: <521BC472.7040804@freebsd.org> Date: Mon, 26 Aug 2013 23:11:14 +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: Ian Lepore Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> In-Reply-To: <1377550636.1111.156.camel@revolution.hippie.lan> 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: Mon, 26 Aug 2013 21:11:19 -0000 On 26.08.2013 22:57, Ian Lepore wrote: > This new thread pulls together info from several other threads and irc > conversations, to summarize what we know right now for Andre in case the > problem is directly related to the mbuf changes. > > It looks like ARM systems consistantly get address translation faults > related to network operations during boot. Zbyszek Bodek bisected it > down to r254807; revisions before that work, beginning with that one > they don't. A representative dmesg appears below. The abort happens in > in_cksum(), or sbappendaddr_locked(), or soreceive_generic(), depending > on various kernel config options and what network operations happen > first. > > Thomas Skibo reports: > > I've been experiencing this too on the Zedboard and I spent some time > looking into it. > > In my case, arprequest() is overwriting past the end of an mbuf into the > m_next field of the next one. Later, something tries to reference > address 0x6401a8c0 which is actually the machine's IP address in network > order. It looks like MH_ALIGN() used in arprequest() isn't working > properly after the recent mbuf header changes. > > Here's the mbuf just after arprequest() has performed MH_ALIGN(). The > m_data pointer is 0xc2c41de8 and the length is 0x1c. That puts the data > over the edge into the next mbuf. The m_pkthdr appears to have been > placed at 0xc2c41d18 (I think). It looks like the compiler inserted > padding at 1d14 so MHLEN isn't correct. > > XMD% mrd 0xc2c41d00 32 > C2C41D00: 00000000 > C2C41D04: 00000000 > C2C41D08: C2C41DE8 (m_data) > C2C41D0C: 0000001C (m_len) > C2C41D10: 00000201 (m_type,m_flags) > C2C41D14: 00000000 (?) > C2C41D18: 00000000 (pkthdr.rcvif) > C2C41D1C: 00000000 (pkthdr.tags) > C2C41D20: 0000001C (pkthdr.len) > C2C41D24: 00000000 > C2C41D28: 00000000 > C2C41D2C: 00000000 > > Thomas also reports that removing the bitfield definitions, so that > flags and type are two separate integers, works around the problem. > > Could this be something related to how bitfields are handled in EABI? Can you try this patch see check if it makes a difference on the bitfield? -- Andre Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 254936) +++ sys/mbuf.h (working copy) @@ -94,7 +94,7 @@ 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 */ -}; +} __packed; /* * Packet tag structure (see below for details). @@ -169,7 +169,7 @@ (struct mbuf *, void *, void *); void *ext_arg1; /* optional argument pointer */ void *ext_arg2; /* optional argument pointer */ -}; +} __packed; /* * The core of the mbuf object along with some shortcut defines for practical