Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Aug 2013 10:49:29 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Michael Tuexen <tuexen@freebsd.org>
Cc:        freebsd-arm <freebsd-arm@FreeBSD.org>, Andre Oppermann <andre@freebsd.org>
Subject:   Re: ARM network trouble after recent mbuf changes
Message-ID:  <7E1F1106-654B-4AEC-B915-F97D95C24E75@bsdimp.com>
In-Reply-To: <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org>
References:  <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> <DD3D1045-535F-4593-A3B4-E33CFECF0818@bsdimp.com> <20130827164055.4a757a13@bender> <CC710D69-1903-4405-B4B5-55DD9D171D25@bsdimp.com> <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Aug 27, 2013, at 9:59 AM, Michael Tuexen wrote:

> On Aug 27, 2013, at 5:56 PM, Warner Losh <imp@bsdimp.com> wrote:
>=20
>>=20
>> On Aug 27, 2013, at 9:40 AM, Andrew Turner wrote:
>>=20
>>> On Tue, 27 Aug 2013 07:26:03 -0600
>>> Warner Losh <imp@bsdimp.com> wrote:
>>>=20
>>>>=20
>>>> On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote:
>>>>=20
>>>>> On Tue, 27 Aug 2013 08:53:13 +0200
>>>>> Andre Oppermann <andre@freebsd.org> wrote:
>>>>>> Please try the patch below to confirm.  If it fixes your problem
>>>>>> for now I'm going to commit as an immediate fix while searching
>>>>>> for a better long term stable solution.
>>>>>>=20
>>>>>=20
>>>>> I tried this with a CTASSERT to check if struct m_hdr is the =
correct
>>>>> length. In this test the size is incorrect. It appears __ILP32__ =
is
>>>>> not defined on ARM.
>>>>>=20
>>>>> I have tested a fix suggested by Hans Petter Selasky where we mark
>>>>> m_hdr with __aligned(8). With this change I can netboot a
>>>>> PandaBoard.
>>>>=20
>>>> Isn't that a bug with our arm compiler then?
>>>=20
>>> No, on ARM EABI the definition of the size of a struct is to be the
>>> smallest multiple of its alignment. As we are increasing the =
alignment
>>> to 8-byte and the struct without this alignment is not a multiple of
>>> 8-bytes adding this alignment will pad to struct to use the unused 4
>>> bytes between this and the next struct.
>>=20
>> Wrong bug :)
>>=20
>> Is it not a bug that __ILP32__ is undefined?
> Is it used anywhere? I only found __LP64__ being used...

_ILP32 is used in code we got from Solaris. Otherwise, you're right: we =
don't use it in the tree. Lots of places use __LP64__ though.

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7E1F1106-654B-4AEC-B915-F97D95C24E75>