cvs commit: src/sys/dev/em if_em.c

[Yar Tikhiy]

On Sun, Jul 30, 2006 at 03:48:07PM +0900, Pyun YongHyeon wrote:
> On Sat, Jul 29, 2006 at 08:50:09PM +0000, Yar Tikhiy wrote:
>  > On Thu, Jul 27, 2006 at 12:43:34AM +0000, Pyun YongHyeon wrote:
>  > > yongari     2006-07-27 00:43:34 UTC
>  > > 
>  > >   FreeBSD src repository
>  > > 
>  > >   Modified files:
>  > >     sys/dev/em           if_em.c 
>  > >   Log:
>  > >   Prepending an mbuf after loading a DMA map results in unexpected
>  > >   result. So, modify mbuf chains before loading a DMA map.
>  > >   
>  > >   Revision  Changes    Path
>  > >   1.122     +28 -31    src/sys/dev/em/if_em.c
>  > 
>  > Thanks a lot!  Do you think this can fix kern/72933?
>  > 
> 
> I can't sure it helps as the submitter reported the same issue
> on bge(4).

Sorry, my question wasn't accurate.  I believe that the original
PR in fact described a different issue with similar symptoms; it
was fixed quite a while ago.  Then Lev Shamardin posted a follow-up
that he was still seeing the symptoms with em(4), which we (Gleb
Smirnoff and yours truly) couldn't fully understand because we were
missing the peculiarities of the interaction between DMA and mbufs
you're so well aware of.

> Btw, I think the VLAN fixup code should use m_prepend(9)
> insatead of M_PREEND(9) because we don't know whether a new mbuf
> is allocated or not after M_PREPEND(9) call.

If a new mbuf should be allocated to satisfy DMA, m_prepend(9) is
the function to use.  M_PREPEND(9) can use the free space at the
beginning of the mbuf's data area if there is enough of it.  I'm
unsure though whether we really need a new mbuf there.  em_encap()
gets just a mbuf chain, which can be tweaked a little before starting
the DMA magic on it.

-- 
Yar