Re: sbp_targ memory leak

Thanks for the test.
I'll look into the page_table problem this weekend.
Sorry for late response.

On 12/21/07, Sean Bruno <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>
>


-- 
/\ Hidetoshi Shimokawa
\/  [email protected]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "[email protected]"