From owner-cvs-src@FreeBSD.ORG Mon Jul 31 02:43:33 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2DD616A4E0 for ; Mon, 31 Jul 2006 02:43:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5118943DA5 for ; Mon, 31 Jul 2006 02:43:27 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so119875nzn for ; Sun, 30 Jul 2006 19:43:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=FSBOc/weoQxAd8bI64UWO/ys6M4FeoAmEkVniygsO2CZmLjqtb3KhnomNqv5DARZbPFA290PW2MbEBwPjog2xbXEGlD86Yh1XwM4lYPRRHT7HgFjYekYv96v7tFMspvgHJY9Yj1Zo8FCXNq8YsnbjF/1DskNHv0tKIEo6p8Jkek= Received: by 10.65.119.14 with SMTP id w14mr2693582qbm; Sun, 30 Jul 2006 19:43:27 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm4318243nzp.2006.07.30.19.43.23; Sun, 30 Jul 2006 19:43:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6V2hu6o036121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jul 2006 11:43:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6V2hsvU036120; Mon, 31 Jul 2006 11:43:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 31 Jul 2006 11:43:54 +0900 From: Pyun YongHyeon To: Yar Tikhiy Message-ID: <20060731024354.GA35573@cdnetworks.co.kr> References: <200607270043.k6R0hY8g088353@repoman.freebsd.org> <20060729205009.GA37970@freefall.freebsd.org> <20060730064807.GA32731@cdnetworks.co.kr> <20060730095054.GA36267@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060730095054.GA36267@comp.chem.msu.su> User-Agent: Mutt/1.4.2.1i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Pyun YongHyeon Subject: Re: cvs commit: src/sys/dev/em if_em.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 02:43:33 -0000 On Sun, Jul 30, 2006 at 01:50:55PM +0400, Yar Tikhiy wrote: > 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 No, prepending a new mbuf with m_prepend(9) is not necessary for DMA to work. > 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. > Sorry, I'm confused. I've misread VLAN fixup code. From my limited testing, it seems that it works as expected. Previously em(4) may have failed VLAN tag insertion if M_PREPEND(9) added a new mbuf into existing mbuf chains. > -- > Yar -- Regards, Pyun YongHyeon