busdma MFC broke ipfw fwd for RELENG_6

[John Baldwin]

On Monday, September 19, 2011 6:20:07 am Andreas Longwitz wrote:
> Eugene Grosbein wrote:
> 
> > Well, given that before busdma commit that hardware worked just fine
> > with stock driver, it could be less overhead for me to rollback that
> > one busdma small chunk :-)
> > Who knows, which drivers got broken then in 2010 in 6.4-STABLE with
> > busdma change besides re(4)...
> 
> Another example is de(4) as mentioned in kern/151941.

Hmm, that PR isn't really about de(4).  For de(4) I think you probably want 
this change:

r197465 | yongari | 2009-09-24 13:53:00 -0400 (Thu, 24 Sep 2009) | 18 lines

Align Tx/Rx descriptors on 32 bytes boundary instead of PAGE_SIZE.
Also align setup descriptor on 32 bytes boundary. Tx buffer have no
alignment limitation so create dmamap without alignment
restriction[1]. Rx buffer still seems to require 4 bytes alignment
limitation but we can simply use MCLBYTES for size to map the
buffer instead of TULIP_DATA_PER_DESC as the buffer is allocated
with m_getcl(9).
de(4) supports up to TULIP_MAX_TXSEG segments for Tx buffers,
increase maximum dma segment size to TULIP_MAX_TXSEG * MCLBYTES.
While I'm here remove TULIP_DATA_PER_DESC as it is not used anymore.

This should fix de(4) breakage introduced after r176206.

Submitted by:   jhb [1]
Reported by:    WATANABE Kazuhiro < CQG00620 <> nifty dot ne dot jp >
Tested by:      WATANABE Kazuhiro < CQG00620 <> nifty dot ne dot jp >,
                Takahashi Yoshihiro < nyan <> jp dot freebsd dot org >

And probably these as well:

------------------------------------------------------------------------
r197464 | yongari | 2009-09-24 13:11:41 -0400 (Thu, 24 Sep 2009) | 2 lines

Destroy dmamap in dma cleanup.

------------------------------------------------------------------------
r197463 | yongari | 2009-09-24 13:07:04 -0400 (Thu, 24 Sep 2009) | 2 lines

Consistently use bus_addr_t.

------------------------------------------------------------------------
r197461 | yongari | 2009-09-24 12:57:35 -0400 (Thu, 24 Sep 2009) | 4 lines

Use __NO_STRICT_ALIGNMENT to determine whether de(4) have to apply
alignment fixup code for received frames on strict alignment
architectures.

------------------------------------------------------------------------
r177937 | jhb | 2008-04-05 13:24:44 -0400 (Sat, 05 Apr 2008) | 9 lines

During attach on some de(4) adapters the driver sends out a test packet as
part of detecting the media.  Explicitly ensure that we don't send it to
bpf(4) as bpf(4) isn't setup yet.  This worked by accident before the bpf
interface stuff was reworked to avoid other races (bpf_peers_present, etc.)
but now it needs an explicit check to avoid a panic.

MFC after:      3 days
PR:             kern/120915

------------------------------------------------------------------------
r170389 | yongari | 2007-06-06 20:28:47 -0400 (Wed, 06 Jun 2007) | 9 lines

The maxsegsz of a dma tag created in de(4) is TULIP_DATA_PER_DESC bytes.
In Rx path it allocates a new mbuf with m_getcl(9) so the length of
the mbuf is MCLBYTES which is greater than a segment size specified by
the dma tag. This segment size mismatch caused a voluntary panic.
Fix the panic by settting the mbuf length to TULIP_DATA_PER_DESC.

Reported by:    Arne H Juul <arnej AT yahoo-inc DOT com>
Tested by:      Arne H Juul <arnej AT yahoo-inc DOT com>



-- 
John Baldwin