Date: Thu, 03 Jan 2008 17:07:12 -0800 From: Sean Bruno <sbruno@miralink.com> To: Hidetoshi Shimokawa <simokawa@FreeBSD.ORG> Cc: freebsd-firewire@freebsd.org Subject: Re: sbp_targ memory leak Message-ID: <477D86C0.80509@miralink.com> In-Reply-To: <626eb4530712201727n3fc0d33aq6e6b44603b5d77f2@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <sbruno@miralink.com> 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 <sbruno@miralink.com> 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 <sbruno@miralink.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477D86C0.80509>