[stgt] help tgt segfault

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Tue Feb 3 12:25:12 CET 2009


On Tue, 03 Feb 2009 12:12:55 +0100
Tomasz Chmielewski <mangoo at wpkg.org> wrote:

> FUJITA Tomonori schrieb:
> > On Tue, 03 Feb 2009 11:56:11 +0100
> > Tomasz Chmielewski <mangoo at wpkg.org> wrote:
> > 
> >> FUJITA Tomonori schrieb:
> >>
> >>>> Did you see any message _before_ the segfault?
> >>> BTW, this is the output of 0.9.3.
> >>>
> >>> So please tell me any message _before_ the segfault (and the
> >>> configuration) if you have.
> >> # tgtd -h                                                                   
> >> Usage: tgtd [OPTION]                                                                            
> >> Target framework daemon, version 0.9.3                                                          
> >> (...)                                       
> >> # tgtadm -h
> >> Usage: tgtadm [OPTION]
> >> Linux SCSI Target Framework Administration Utility, version 0.9.3
> >> (...)
> > 
> > Definitely, the following output is not 0.9.3. You run wrong binaries
> > or something wrong.
> > 
> > With 0.9.3, you see:
> > 
> > conn_close(128) Forcing release of tx task
> > 
> > Check again the 0.9.3 output:
> > 
> > http://lists.wpkg.org/pipermail/stgt/2009-February/002587.html
> > 
> > 
> > With 0.9.2 (or older), you see:
> > 
> > conn_close(115) Forcing release of tx task 
> 
> Could it be that up to the first segfault it was an older version?
> 
> After that, it segfaulted and started again several times, it _must_ be 
> 0.9.3 here, tgtd and tgtadm were installed on 13-Jan and these binaries 
> were started here:
> 
> http://lists.wpkg.org/pipermail/stgt/2009-February/002599.html
> 
> Maybe just the _first_ segfault on the above link was an old binary 
> running (it's also a different system from the one I was pasting the 
> logs earlier - two, three weeks ago).

Yeah, looks like it's the mixed log of the old and new versions.

Can you try this patch with 0.9.3 and send the log of 0.9.3? Please
test it with one target and one initiator with a slow link.

I'll try to reproduce the problem with the same configuration.


diff --git a/usr/iscsi/iscsid.c b/usr/iscsi/iscsid.c
index c22a6f6..e8501fa 100644
--- a/usr/iscsi/iscsid.c
+++ b/usr/iscsi/iscsid.c
@@ -1268,6 +1268,8 @@ static int iscsi_tm_execute(struct iscsi_task *task)
 	struct iscsi_tm *req = (struct iscsi_tm *) &task->req;
 	int fn = 0, err = 0;
 
+	eprintf("%p %p %x\n", conn, task, req->flags & ISCSI_FLAG_TM_FUNC_MASK);
+
 	switch (req->flags & ISCSI_FLAG_TM_FUNC_MASK) {
 	case ISCSI_TM_FUNC_ABORT_TASK:
 		fn = ABORT_TASK;
diff --git a/usr/tgtd.c b/usr/tgtd.c
index 8569d41..e93a256 100644
--- a/usr/tgtd.c
+++ b/usr/tgtd.c
@@ -388,6 +388,8 @@ int main(int argc, char **argv)
 		}
 	}
 
+	eprintf("the main daemon (%s) started\n", TGT_VERSION);
+
 	event_loop();
 
 	lld_exit();
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the stgt mailing list