From owner-freebsd-firewire@FreeBSD.ORG Wed Jan 16 22:46:48 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 658A516A41A for ; Wed, 16 Jan 2008 22:46:48 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 2801313C458 for ; Wed, 16 Jan 2008 22:46:47 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by an-out-0708.google.com with SMTP id c14so108034anc.13 for ; Wed, 16 Jan 2008 14:46:47 -0800 (PST) Received: by 10.100.8.10 with SMTP id 10mr2797908anh.59.1200523607260; Wed, 16 Jan 2008 14:46:47 -0800 (PST) Received: by 10.100.211.16 with HTTP; Wed, 16 Jan 2008 14:46:47 -0800 (PST) Message-ID: <626eb4530801161446g7467c9cew59bd65cea68b8ed6@mail.gmail.com> Date: Thu, 17 Jan 2008 07:46:47 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Sean Bruno" In-Reply-To: <478E2B53.7070107@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <478E2B53.7070107@miralink.com> X-Google-Sender-Auth: 136b45d610942f1b 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: Wed, 16 Jan 2008 22:46:48 -0000 Thanks for digging out the problem. I did not suppose multiple CTIO's for an ATIO so that your guess should be right. I'm sorry that I will be busy until mid of Feb. I'd like to merge your fixes to -current in a few month. I appreciate if you would do the following: - test on -current and make a patch for -current. - split the patch for each fix (a version control system or ports/devel/quilt may be useful) - non-reversed patch Thanks, On Jan 17, 2008 1:05 AM, Sean Bruno wrote: > > 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 > >> > >> > >> > > > > > > > I seem to have been able to resolve the memory leak, multiple CTIO's and > some various lockups with the patch in this PR --> > http://www.freebsd.org/cgi/query-pr.cgi?pr=119575 > > This is against RELENG_6 and should be applied. I noted 3 more issues > that I'd like to resolve in the ticket. > > What do you think? > > Sean > -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG