arm alignment faults...

[Warner Losh]

On Jun 28, 2014, at 11:40 PM, John-Mark Gurney <jmg at funkthat.com> wrote:

> Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600:
>> 
>> On Jun 28, 2014, at 10:52 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> 
>>> On 28 June 2014 21:01, John-Mark Gurney <jmg at funkthat.com> wrote:
>>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700:
>>>>> On 28 June 2014 20:38, John-Mark Gurney <jmg at funkthat.com> wrote:
>>>>>> So, one of the little projects I'd like to see is the removal of
>>>>>> ETHER_ALIGN from the tree..  This bogosity can (and does) cause the use
>>>>>> of bouncing durning DMA ops on all ethernet frames...
>>>> 
>>>> Now that I think about it, total removal may not be necessary, just
>>>> the requirement to use it...  If the ethernet dma engine can do half
>>>> word aligned dma, then there would be benifit on those to keep
>>>> ETHER_ALIGN...
>>>> 
>>>>> Well, as long as you're not doing it by forcing the various CPUs to
>>>>> handle unaligned accesses.
>>>> 
>>>> Hard to do on armv4 which I don't believe supports unaligned access...
>>>> 
>>>>> The cost of those unaligned accesses on some CPUs that support them is
>>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm back
>>>>> when looking to migrate stuff to ARM and it wasn't very quick.
>>>> 
>>>> I plan on fixing the TCP/IP stack to copy data to an aligned buffer
>>>> (maybe only if the original buffer isn't aligned) on the stack when
>>>> __NO_STRICT_ALIGNMENT is not defined...  I can't see how copying the
>>>> entire packet is cheaper than copying 20 bytes or so...
>>> 
>>> There's lots of other stupid corner cases that screw you.
>>> 
>>> VLAN headers add extra bytes.
>>> 
>>> 802.11 headers can offset things depending upon the 802.11 frame type
>>> (3-addr, 4-addr, vlan, no vlan, etc.)
>>> 
>>> There's no guarantee all ethernet DMA engines can do the alignment as
>>> required. :(
>> 
>> The ate driver for Atmel?s AT91RM9200 is one such beast.
> 
> Are you sure?  The tag for data says alignment 1:
>        if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0,
>            BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES,
>            1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag))
> 
> Or is that a limitation on the parent?

It is a limitation in hardware. You have to DMA to a 4 byte boundary. That might be a bug in the above line though…

Warner

> I did an audit of the arm drivers (not mips), but I didn't see any that
> have the restriction...  The one that I'm thinking of was the Cirrus
> EP9302 in the TS-7200 port that I did years ago..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140629/2143ce27/attachment.sig>