ARM network trouble after recent mbuf changes

[Andre Oppermann]

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