On Thu, 27 Mar 2008 21:56:11 +0100 (CET) "Niels de Carpentier" <[EMAIL PROTECTED]> wrote:
> >> On Wed, 19 Mar 2008 03:53:36 +0100 (CET) > >> "Niels de Carpentier" <[EMAIL PROTECTED]> wrote: > >> > >>> The issue where a connection isn't properly closed because > >>> it_nexus_destroy returns EBUSY. > >>> > >>> This probably isn't very important anymore, as the reconnect should now > >>> close the old connection properly. > >> > >> We hit that issue since tgt doesn't implement session reinstatement > >> properly, I think. > >> > >> You still hit that issue with the patch? > >> > > Yes, that issue is still there. (And it actually happens before the > > session reinstatement). > > > > Some debug information about the close issue: > > tgtd: iscsi_tcp_event_handler(160) connection closed > tgtd: conn_close(88) connection closed > tgtd: conn_close(111) Forcing release of tx task 34 > tgtd: conn_close(111) Forcing release of tx task 2f > tgtd: conn_close(111) Forcing release of tx task 4e > tgtd: conn_close(111) Forcing release of tx task 66 > tgtd: conn_close(111) Forcing release of tx task 39 > tgtd: conn_close(111) Forcing release of tx task 6a > tgtd: conn_close(111) Forcing release of tx task 28 > tgtd: conn_close(111) Forcing release of tx task 40 > tgtd: conn_close(111) Forcing release of tx task 3d > tgtd: conn_close(111) Forcing release of tx task 37 > tgtd: conn_close(111) Forcing release of tx task 2a > tgtd: conn_close(111) Forcing release of tx task 4c > tgtd: conn_close(111) Forcing release of tx task 6c > tgtd: conn_close(111) Forcing release of tx task 4a > tgtd: conn_close(111) Forcing release of tx task 49 > tgtd: conn_close(111) Forcing release of tx task 48 > tgtd: conn_close(111) Forcing release of tx task 41 > tgtd: conn_close(111) Forcing release of tx task 54 > tgtd: conn_close(111) Forcing release of tx task 38 > tgtd: conn_close(111) Forcing release of tx task 4f > tgtd: conn_close(111) Forcing release of tx task 15 > tgtd: conn_close(111) Forcing release of tx task 20 > tgtd: it_nexus_destroy(257) 1 1 > tgtd: it_nexus_destroy(265) cmd_hash_list entry 0 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 1 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 2 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 3 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 7 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 8 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 9 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 11 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 12 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 13 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 14 not empty > tgtd: it_nexus_destroy(265) cmd_hash_list entry 15 not empty > tgtd: iscsi_tcp_event_handler(167) connection closed > > So it looks like the cmd_hash_list is not actually cleared on a connection > close. Thanks, > Is there anything more I can do to troubleshoot this issue? Is there any way to reproduce this easily? _______________________________________________ Stgt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/stgt-devel
