From owner-freebsd-stable@FreeBSD.ORG Mon Sep 19 12:51:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B791065670 for ; Mon, 19 Sep 2011 12:51:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 648EF8FC13 for ; Mon, 19 Sep 2011 12:51:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 002CB46B59; Mon, 19 Sep 2011 08:51:21 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 90BAA8A03E; Mon, 19 Sep 2011 08:51:21 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 19 Sep 2011 08:51:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E64933E.8030908@incore.de> <201109061104.43409.jhb@freebsd.org> <4E771757.7010900@incore.de> In-Reply-To: <4E771757.7010900@incore.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201109190851.20863.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 19 Sep 2011 08:51:21 -0400 (EDT) Cc: Andreas Longwitz , egrosbein@rdtc.ru Subject: Re: busdma MFC broke ipfw fwd for RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 12:51:22 -0000 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 Tested by: Arne H Juul -- John Baldwin