Date: Mon, 26 Aug 2013 23:11:14 +0200 From: Andre Oppermann <andre@freebsd.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM network trouble after recent mbuf changes Message-ID: <521BC472.7040804@freebsd.org> In-Reply-To: <1377550636.1111.156.camel@revolution.hippie.lan> References: <1377550636.1111.156.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521BC472.7040804>