From owner-freebsd-firewire@FreeBSD.ORG Fri Jan 4 01:07:14 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 848CA16A417; Fri, 4 Jan 2008 01:07:14 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 51C8D13C45A; Fri, 4 Jan 2008 01:07:14 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id DB36B1C802D; Thu, 3 Jan 2008 17:07:13 -0800 (PST) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25333-04; Thu, 3 Jan 2008 17:07:12 -0800 (PST) Received: from iago.office.miralink.com (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 851CF1C800D; Thu, 3 Jan 2008 17:07:12 -0800 (PST) Message-ID: <477D86C0.80509@miralink.com> Date: Thu, 03 Jan 2008 17:07:12 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Hidetoshi Shimokawa References: <476610E5.2060108@miralink.com> <626eb4530712162258s4dfe1448o1102f20a623d3f95@mail.gmail.com> <476696C4.60408@miralink.com> <626eb4530712182320q237c344crd309893a82fe8ef8@mail.gmail.com> <476B13F4.5050409@miralink.com> <626eb4530712201727n3fc0d33aq6e6b44603b5d77f2@mail.gmail.com> In-Reply-To: <626eb4530712201727n3fc0d33aq6e6b44603b5d77f2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jan 3 17:07:13 2008 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 477d86c190381592213743 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Cc: freebsd-firewire@freebsd.org Subject: Re: sbp_targ memory leak X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:07:14 -0000 Hidetoshi Shimokawa wrote: > Thanks for the test. > I'll look into the page_table problem this weekend. > Sorry for late response. > > On 12/21/07, Sean Bruno wrote: > >> Hidetoshi Shimokawa wrote: >> >>> I think you are right and page table is not freed when CAM_SEND_STATUS >>> is not set. >>> Maybe we should always free page tables if refcont == 0 rather than >>> free in sbp_targ_send_status(). >>> >>> You patch is not just adding debug printfs, right? >>> What is the mtx locks for? >>> >>> On 12/18/07, Sean Bruno wrote: >>> >>> >>>> Hidetoshi Shimokawa wrote: >>>> >>>> >>>>> Thanks for the tracking of the problem. >>>>> Could you resend the patch in unified or context diff? >>>>> >>>>> Thanks, >>>>> >>>>> On 12/17/07, Sean Bruno wrote: >>>>> >>>>> >>>>> >>>>>> In trying to understand and make sbp_targ functional, I've noted that >>>>>> the code seems to lose track of how many page tables it allocates for >>>>>> any give orbi. I had to add a lot of debugging code around the >>>>>> malloc/free's to find out what was going on, and I'm not sure what the >>>>>> code is supposed to do in this case. >>>>>> >>>>>> Please review the patch diff at --> http://consultcsg.com/RELENG_6.diff >>>>>> >>>>>> And the log at -->http://consultcsg.com/malloc_failure.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> Diff updated at http://consultcsg.com/RELENG_6.diff >>>> >>>> Sean >>>> >>>> >>>> >> I moved the free around as you suggested and the memory leak does indeed >> go away and there are no further crashes. >> Here is my current diff --> http://consultcsg.com/RELENG_6.diff . >> >> It does look like the data is not being written or read to the backend >> correctly however. I.e. the page_table is not being >> setup correctly when more than one read or write is required to service >> an ORB. Any ideas on how to look into that? >> >> Sean >> >> >> > > > Updated diff at --> http://consultcsg.com/RELENG_6.diff It looks like the memory leak was actually being caused by the target's inability to process multiple CTIO's for a single ATIO correctly. I've made some adjustments so that it works as advertised. I can now read/write cleanly with no data errors and no memory leaks. I am currently investigating initialization errors on startup. It looks like sbp_targ attempts to process ORB's even though it doesn't have a backend device yet. This happens on startup after the initiator has logged into the target and the target has rebooted out from underneath the intiator. Sean