[stgt] segfault when stopping the target

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Wed Oct 22 03:47:26 CEST 2008


On Tue, 21 Oct 2008 17:49:00 +0200
Tomasz Chmielewski <mangoo at wpkg.org> wrote:

> FUJITA Tomonori schrieb:
> > On Tue, 21 Oct 2008 17:29:19 +0200
> > Tomasz Chmielewski <mangoo at wpkg.org> wrote:
> > 
> >> FUJITA Tomonori schrieb:
> >>
> >> (...)
> >>
> >>>>>> Does it say anything?
> >>>>>>
> >>>>>> Oct 21 16:21:04 megathecus tgtd: conn_close_force(197) close 1 0
> >>>>>> Oct 21 16:21:04 megathecus tgtd: conn_close(88) connection closed 0x80700b4 4
> >>>>>> Oct 21 16:21:04 megathecus tgtd: tgt_event_modify(159) Cannot find event 7
> >>>>> Can you try this new patch and send messages in the log?
> >>>>>
> >>>>> I expect error messages like:
> >>>>>
> >>>>> tgtd: mtask_handler(x) hoge
> >>>>> tgtd: mgmt_event_handler(x) hoge
> >>>> This:
> >>>>
> >>>> tgtadm --op update --mode target --tid=1 -n state -v offline
> >>>> tgtadm --op update --mode sys --name State -v offline
> >>>> tgtadm --op unbind --mode target --tid 1 -I ALL
> >>>> tgtadm --op delete --mode conn --tid 1 --sid 3 --cid 0
> >>>> tgtadm --mode target --op delete --tid=1
> >>>>
> >>>>
> >>>> gave this log:
> >>>>
> >>>> Oct 21 17:03:55 megathecus tgtd: conn_close_force(197) close 3 0
> >>>> Oct 21 17:03:55 megathecus tgtd: conn_close(88) connection closed 0x80700b4 2
> >>>> Oct 21 17:03:55 megathecus tgtd: tgt_event_modify(159) Cannot find event 7
> >>>> Oct 21 17:03:55 megathecus tgtd: tgt_target_destroy(1739) target 1 still has it nexus
> >>> Did you get a message earlier like
> >>>
> >>> tgtd: mgmt_event_handler(504) new ipc connection 5
> >>>
> >>> Note that the last number is probably a different value (not 5).
> >> No, this is all there is in the log.
> > 
> > Are you really sure that you don't use the old binary? With the latest
> > patch (http://lists.wpkg.org/pipermail/stgt/2008-October/002414.html),
> > something like the following message should show up every time you use
> > tgtadm:
> > 
> > tgtd: mgmt_event_handler(504) new ipc connection 5
> 
> Yes, I'm pretty sure I use the patched version. Maybe back then I wasn't?
> "mgmt_event_handler" does show up in the log, but not every time I use tgtadm.
> 
> 
> So let's try again.
> 
> Here, I had two connected initiators (from the same IP).
> 
> Only one was removed properly. One wasn't. Does it tell anything?
> 
> Oct 21 17:46:45 megathecus tgtd: mgmt_event_handler(504) new ipc connection 26
> Oct 21 17:46:45 megathecus last message repeated 6 times
> Oct 21 17:46:45 megathecus tgtd: conn_close_force(197) close 1 0
> Oct 21 17:46:45 megathecus tgtd: conn_close(88) connection closed 0x807009c 1
> Oct 21 17:46:45 megathecus tgtd: mgmt_event_handler(504) new ipc connection 7
> Oct 21 17:46:46 megathecus tgtd: mgmt_event_handler(504) new ipc connection 7
> Oct 21 17:46:46 megathecus tgtd: conn_close_force(197) close 2 0
> Oct 21 17:46:46 megathecus tgtd: tgt_event_del(143) Cannot find event 26
> Oct 21 17:46:46 megathecus tgtd: conn_close(88) connection closed 0x8078dfc 4
> Oct 21 17:46:46 megathecus tgtd: mgmt_event_handler(504) new ipc connection 7
> Oct 21 17:46:46 megathecus tgtd: tgt_target_destroy(1739) target 1 still has it nexus
> Oct 21 17:46:46 megathecus tgtd: mgmt_event_handler(504) new ipc connection 7

Thanks. I expected tgtd closes the sockets due to memory allocation
failure but seems it doesn't. I'll try to dig into this issue
later. For now, I'll apply the tgtadm patch.

Thanks again,
--
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