Re: sbp_targ memory leak
Sean Bruno <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.firewire |
|---|---|
| Message-ID | <[email protected]> |
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 <[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 >> >> >> > > > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-firewire To unsubscribe, send any mail to "[email protected]"