Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jan 2008 08:05:39 -0800
From:      Sean Bruno <sbruno@miralink.com>
To:        Hidetoshi Shimokawa <simokawa@FreeBSD.ORG>
Cc:        freebsd@gm.nunu.org, freebsd-firewire@freebsd.org
Subject:   Re: sbp_targ memory leak
Message-ID:  <478E2B53.7070107@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
>>
>>
>>     
>
>
>   
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478E2B53.7070107>