From owner-cvs-src@FreeBSD.ORG Sun Jul 30 09:51:00 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 496FA16A4DA; Sun, 30 Jul 2006 09:51:00 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A540643D68; Sun, 30 Jul 2006 09:50:58 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k6U9otAm036634; Sun, 30 Jul 2006 13:50:55 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k6U9ottF036633; Sun, 30 Jul 2006 13:50:55 +0400 (MSD) (envelope-from yar) Date: Sun, 30 Jul 2006 13:50:55 +0400 From: Yar Tikhiy To: Pyun YongHyeon Message-ID: <20060730095054.GA36267@comp.chem.msu.su> References: <200607270043.k6R0hY8g088353@repoman.freebsd.org> <20060729205009.GA37970@freefall.freebsd.org> <20060730064807.GA32731@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060730064807.GA32731@cdnetworks.co.kr> User-Agent: Mutt/1.5.9i 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 List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 09:51:00 -0000 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