[01:08:48] *** Joins: vmysak (~vmysak@192.55.54.38) [02:14:11] Project autotest-nightly build #462: STILL FAILING in 32 min. See https://dqtibwqq6s6ux.cloudfront.net for results. [02:30:39] Project autotest-nightly-failing build #326: STILL FAILING in 46 min. See https://dqtibwqq6s6ux.cloudfront.net for results. [02:48:55] *** Joins: felipef (~felipef@62.254.189.133) [02:50:08] *** Quits: felipef (~felipef@62.254.189.133) (Remote host closed the connection) [03:16:49] *** Quits: guerby (~guerby@april/board/guerby) (Remote host closed the connection) [03:19:21] *** Joins: guerby (~guerby@april/board/guerby) [06:45:32] *** Joins: pawelkax (pawelkax@nat/intel/x-rszudqsbimvpglzq) [06:47:03] darsto: Could you look at patch 442210 ? [07:08:50] *** Joins: Se-young (~se_young@abbt-ap-auto-165-124-158-58.northwestern.edu) [07:50:29] *** Quits: Leeleo3x (8a337d08@gateway/web/freenode/ip.138.51.125.8) (Quit: Page closed) [07:55:57] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-itoemytsxbxeirpr) [08:19:49] *** Joins: sethhowe (~sethhowe@134.134.139.75) [10:00:12] *** Quits: Se-young (~se_young@abbt-ap-auto-165-124-158-58.northwestern.edu) (Remote host closed the connection) [10:32:10] *** Quits: vmysak (~vmysak@192.55.54.38) (Ping timeout: 252 seconds) [11:11:21] *** Joins: Se-young (~se-young@dhcp-165-124-158-58.nwu.icair.org) [11:17:23] @jimharris [11:17:30] im trying to read the iscsi.c code to understand it [11:17:54] and help f igure out whats wrong [11:17:54] so im gonna probably start asking a lot of questions about it [11:17:57] first one [11:18:24] inside of spdk_iscsi_conn_handle_queued_datain_tasks https://www.irccloud.com/pastebin/F0BWCorF/iscsi.c [11:18:55] why is line 9 here setting the current ofset to task->scsi.length? [11:19:37] my understanding of this snippet is that its queueing a new task and so I would expect it to set it to 0 as the initial offset [11:20:32] or does current_datain_offset indicate where the next task will start [11:20:57] so because we're starting this task we move the offset forward to after the task prior to starting i t [11:21:27] also what does `conn->data_in_cnt` represent [11:26:33] also im not precisely clear on what guaruntees we have about which tasks can enger into this function [11:26:39] enter* [11:27:12] when the next task will start [11:28:03] but it seems to me if the primary task has a scsi.length equal to transfer_len it would continue out of the first loop then immediately hit the assert at the top of the while loop with current_datain_offset == scsi.transfer_len [11:50:52] hi jrlusby - sorry, i'm sitting with tomzawadzki on some unrelated debugging so not being very responsive right now :-( [11:51:06] its okay im being productive stil [11:51:56] im currently tracing the call heirarchy for the two functions where we have asserts on the transfer_len vs offset to understand how they interact and at what point you can switch from one context to the next [11:52:26] well, technically im distracted by tweeking a cli tool i maintain for work but the above is what i was doing before that and will shortly resume [14:21:57] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [14:23:28] *** Quits: Se-young (~se-young@dhcp-165-124-158-58.nwu.icair.org) (Remote host closed the connection) [14:29:34] In the patch https://review.gerrithub.io/#/c/spdk/spdk/+/450737/ you suggested that we can always start the poller. [14:30:18] hi shuhei [14:30:35] Thank you. [14:30:48] I tried to do that first but failed. [14:31:05] The experience in SCSI LUN was reminded me. [14:31:06] oh - ok then, ignore my comment [14:31:16] I haven't investigated the root cause yet, this is my lazy [14:31:44] no problem - it's not important - we have some other places in SPDK where we do similar check to avoid starting the poller, so this is OK what you have [14:32:06] Can we have your suggestion as our next step? [14:32:14] Honestly I'm not confortable. [14:32:16] yes - that's fine, i've changed my review to +2 [14:32:43] And now is good time. so I want to hear your feedback for another patch [14:33:07] https://review.gerrithub.io/#/c/spdk/spdk/+/450607/ [14:34:14] if we return -ebusy for scsi_dev_destruct. delete_target_node fails [14:34:38] when the corresponding LUNs are hot removed before. [14:34:39] ok - i am looking now [14:35:09] Thank you, this is relatively clear and you don't have to need long time [14:35:41] the last removal of LUN starts SCSI device destruction. But iSCSI target still exists. [14:36:10] So delete_target_node should return for this case. [14:37:41] I think scsi_dev_destruct returns -enodev and iscsi_target_destruct can go forward when rc of scsi_dev_destruct is 0 or -enodev. [14:37:56] this is only when application is shutting down? [14:38:12] Please read together with Gerrithub. [14:38:12] No. [14:38:42] Sorry, I noticed that in CI first. [14:39:17] one moment, i am downloading your patches to my system to view them in my IDE [14:39:17] Honestly I haven't tested for many cases yet because already late yesterday. [14:41:14] I see your comment "This case should return success because scsi dev is turned into removed if all luns are hot removed, but iscsi target still exists." [14:41:45] but i do not see how removing all LUNs results in dev->removed getting set [14:44:47] I tried and no return [14:45:32] when I created malloc bdev, create a target node with a malloc bdev, delete the malloc bdev, and finally delete the target node. [14:45:53] The last RPC got timeout [14:46:30] OK please wait shortly [14:50:03] Sorry my eyes might be wrong. Timeout is true but the logic is not clear yet. [14:50:21] So I'll read again. Thank you for your help. [14:52:22] Returning 0 didn't fix timeout. [14:53:54] Oh please give a minute, I was wrong and want to correct me. [15:01:33] I didn't call callback in free_dev [15:02:00] The patch series was long and I missed that when rebasing the patch series. [15:02:12] I will update the comment in Gerrit. [15:08:08] I fixed my bug and the end of the patch series worked. [15:08:15] I added a comment to Gerrit. [15:08:20] excellent :) [15:08:44] By the way, due to VPN, I have used different enviroment at office and at home. [15:09:14] If I update the patch, I have to rebase the patch from the start. So I want to update the last patch at office next monday. [15:10:44] So thank you so much for your help today. [15:10:49] Have a nice weekend! [15:13:55] I will leave today. Bye [15:14:18] thanks Shuhei - look forward to seeing you next week at the summit [15:14:20] safe travels! [15:18:21] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 256 seconds) [15:20:16] *** Joins: Se-young (~se-young@dhcp-165-124-158-58.nwu.icair.org)