On Tue, 21 Oct 2008 17:49:00 +0200 Tomasz Chmielewski <mangoo@xxxxxxxx> wrote: > FUJITA Tomonori schrieb: > > On Tue, 21 Oct 2008 17:29:19 +0200 > > Tomasz Chmielewski <mangoo@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
