[00:45:06] *** Joins: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) [00:45:07] (spdk/master) lib/thread: Fix wrong posix thread name by SPDK thread scheduler (Shuhei Matsumoto) [00:45:07] Diff URL: https://github.com/spdk/spdk/compare/7a7cf7ba9474...38527b0786fa [00:45:07] *** Parts: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) () [02:26:53] *** Joins: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) [02:26:53] (spdk/master) rdma: set the srq param in the initiator. (Seth Howell) [02:26:53] Diff URL: https://github.com/spdk/spdk/compare/38527b0786fa...89d2efe07e6a [02:26:53] *** Parts: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) () [03:13:42] *** Joins: felipef (~felipef@62.254.189.133) [08:12:23] *** Joins: travis-ci (~travis-ci@ec2-54-196-186-158.compute-1.amazonaws.com) [08:12:24] (spdk/master) bdev/compress: return error to reducelib if comp/decomp fails (paul luse) [08:12:24] Diff URL: https://github.com/spdk/spdk/compare/bbc49ab42f1f...a50100900d04 [08:12:24] *** Parts: travis-ci (~travis-ci@ec2-54-196-186-158.compute-1.amazonaws.com) () [08:13:20] *** Joins: travis-ci (~travis-ci@ec2-54-80-54-116.compute-1.amazonaws.com) [08:13:20] (spdk/master) lib/thread: free cpumask on spdk_thread_create() failure (Tomasz Zawadzki) [08:13:20] Diff URL: https://github.com/spdk/spdk/compare/89d2efe07e6a...bbc49ab42f1f [08:13:20] *** Parts: travis-ci (~travis-ci@ec2-54-80-54-116.compute-1.amazonaws.com) () [08:57:01] last night's nightly failed because of nvme_autotest timeout at 15 min. I'll start looking at the changes to the nvme driver lately but I'm wondering does anyone know of anything in the last few weeks that would add test time? Maybe 15 min is simply too short for this test now [08:57:20] (a few of the nightly failures in the last week have had nvme_autotest imteouts as well) [08:59:45] anyone have an issue with me bumping the nvme_autotest job timeout to 25 min from 15 to see how it goes over the next few days, we can always take it down to 20 if wee see the average times hovering close to 15 but maybe going over here and there? [09:00:04] klateck, ^ [09:00:17] where is it hanging? [09:01:00] its not hanging, the job has a 15 min limit and then stops it [09:01:51] jimharris, darsto I had to make a small change to a critical issue fix at https://review.gerrithub.io/c/spdk/spdk/+/451788 that you both had +2, its up there now. Once its parent passes CI we'll know if its good [09:02:02] can you post the URL - i'm having trouble finding it in my inbox [09:02:07] child I mean [09:02:13] one sec [09:04:06] jimharris, I assume you are asking me about the nightly timeout failure? I posted the unrelated crypto patch patch up above. Here's the nightly timeout: https://review.gerrithub.io/c/spdk/spdk/+/451788 [09:05:14] that looks like the crypto patch again [09:06:47] peluse: we've been getting random timeouts during compilation for the last few weeks [09:07:28] it might be the same thing with those nvme tests now [09:07:39] let me look at the timing svg [09:08:50] darsto, OK, I was looking too. Want me to stop? Either way I think it makes sense to bump it now, it won't hurt anything and will give us some data on average test times 25 min or less [09:09:40] peluse: can you send the nightly timeout URL? [09:09:53] jimharris, grrr, yes it was. My copy didn't work so I pasted form before. here's the timeout log: https://dqtibwqq6s6ux.cloudfront.net/results/autotest-nightly/builds/474/archive/nvme_autotest/build.log [09:10:32] yup, it's stuck on compilation [09:10:48] it's the same NFS soft lookup issue I filed an issue on yesterday [09:10:50] check dmesg.log [09:11:08] darsto, you think its hanging there or that just happens to be where it was when the jenkins time expired? I had assumed the latter [09:11:11] https://dqtibwqq6s6ux.cloudfront.net/results/autotest-nightly/builds/474/archive/nvme_autotest/dmesg.log [09:11:24] increasing timeout isn't going to help [09:11:57] yup [09:12:43] maybe we need to check pkg versions on the VMs? [09:13:15] peluse: about that crypto patch [09:13:23] yes? [09:13:25] do we need to call vdev_uninit multiple times? [09:13:58] it deinitializes a single AESNI_MB device from what i understand [09:14:10] the first patch did, the 2nd didn't. It will only be called once per instance of an esni_mb driver now. That wasn't the problem though, the problem was that it was being called before the aesni driver was stopped becuase of its position on the list [09:14:11] so why do we call it in a loop? [09:14:32] the loop covers all crpyto devices that we init'd aes and QAT both [09:15:06] the aesni will only show up once as coded today so will only get uninit'd once. If we wanted to support multiple isntances, there's no nebefit as of now, this code would handle it as well [09:15:31] make sense? [09:16:29] *** Joins: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) [09:16:29] (spdk/master) iscsi: allocate sessions array using regular calloc (Darek Stojaczyk) [09:16:29] Diff URL: https://github.com/spdk/spdk/compare/a50100900d04...5bf0a3838c8f [09:16:29] *** Parts: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) () [09:18:06] darsto, I could just pull it out of the loop I guess, I don't see us ever adding a second instance [09:18:25] ok, i see [09:19:31] yeah it works but i find it unintuitive - we always call vdev_init() just once on module init and then call vdev_uninit() in a loop [09:20:18] would only save 1 LOC though and is clearly conditional. I see what you mean though, want me to change it? [09:20:46] its not a problem to do so.... :) [09:20:53] jim will give you a -1 I think :) [09:21:30] LOL, I'm changing it now :) [09:22:23] still passes, will push in a sec and rebase the ipsec lib patch [09:22:25] thanks! [09:23:22] jimharris, see how we proactively saved you some typing and a few mouse clicks? [09:23:37] sethhowe: the new srq_overwhelm.sh test randomly fails - https://dqtibwqq6s6ux.cloudfront.net/results/autotest-per-patch/builds/29188/archive/nvmf_phy_autotest/build.log [09:27:11] darsto: Thanks! Will look into it. I thought I had it consistently passing by lowering the number of qpairs. [09:41:17] sethhowe: can you take a look at https://review.gerrithub.io/c/spdk/spdk/+/443762 [09:50:47] *** Joins: travis-ci (~travis-ci@ec2-52-90-221-117.compute-1.amazonaws.com) [09:50:47] (spdk/master) vhost/scsi: don't send events when eventq is unset (Darek Stojaczyk) [09:50:47] Diff URL: https://github.com/spdk/spdk/compare/5bf0a3838c8f...47cf47e48222 [09:50:47] *** Parts: travis-ci (~travis-ci@ec2-52-90-221-117.compute-1.amazonaws.com) () [09:57:58] jimharris: can we just disable iscsi qos tests for 19.04? those tests themselves are broken [09:58:40] they aren't 100% broken but I know they cause some intermittent failures [09:59:07] are you referring to the qos patch marked with 19.04 hashtag? [09:59:27] jimharris: done [09:59:45] i don't think so [10:00:02] *** Joins: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) [10:00:03] (spdk/master) CHANGELOG: Support APIs for metadata and DIF in bdev layer (Shuhei Matsumoto) [10:00:03] Diff URL: https://github.com/spdk/spdk/compare/47cf47e48222...f74643ef0f36 [10:00:03] *** Parts: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) () [10:02:01] oh, the bdevperf w/ qos patch [10:23:13] *** Quits: tomzawadzki (uid327004@gateway/web/irccloud.com/x-cbrftcfjbvyzsxtu) (Quit: Connection closed for inactivity) [11:30:19] sethhowe: can you describe how we are using NFS in the test pool? [11:30:59] this delegation stuff (which is the cause of all of these soft lockups) is NFSv4 specific - I'm wondering if we can just revert to NFSv3 instead [11:31:15] i'm still looking at how to disable delegations - that could be another option [11:54:55] *** Quits: felipef (~felipef@62.254.189.133) (Remote host closed the connection) [13:14:12] jimharris: I've update patch with triple sync with xattr (great name for change ;D) [15:01:46] *** Joins: travis-ci (~travis-ci@ec2-54-160-195-154.compute-1.amazonaws.com) [15:01:46] (spdk/master) lib/ftl: allow parent/child relations between IOs (Konrad Sztyber) [15:01:46] Diff URL: https://github.com/spdk/spdk/compare/3f4426878a37...ef5ede4b5171 [15:01:46] *** Parts: travis-ci (~travis-ci@ec2-54-160-195-154.compute-1.amazonaws.com) () [15:05:28] *** Joins: travis-ci (~travis-ci@ec2-52-90-221-117.compute-1.amazonaws.com) [15:05:29] (spdk/master) test/nvme: Test case 1 and 2 of NVME performance tests (Pawel Niedzwiecki) [15:05:29] Diff URL: https://github.com/spdk/spdk/compare/ef5ede4b5171...b1d3b47bfb30 [15:05:29] *** Parts: travis-ci (~travis-ci@ec2-52-90-221-117.compute-1.amazonaws.com) () [15:31:00] *** Joins: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) [15:31:00] (spdk/master) bdev/null : Clean up module resources that failed to initialize. (yangtianyu 00383654) [15:31:00] Diff URL: https://github.com/spdk/spdk/compare/b1d3b47bfb30...1dd07870e38f [15:31:00] *** Parts: travis-ci (~travis-ci@ec2-54-173-53-111.compute-1.amazonaws.com) () [15:45:10] *** Joins: travis-ci (~travis-ci@ec2-54-80-54-116.compute-1.amazonaws.com) [15:45:10] (spdk/master) Opal: add take ownership cmd options (Chunyang Hui) [15:45:10] Diff URL: https://github.com/spdk/spdk/compare/1dd07870e38f...7250ec64dbd6 [15:45:10] *** Parts: travis-ci (~travis-ci@ec2-54-80-54-116.compute-1.amazonaws.com) () [15:48:38] *** Joins: travis-ci (~travis-ci@ec2-54-198-67-21.compute-1.amazonaws.com) [15:48:39] (spdk/master) blobstore: block simultaneous operations on blobs (Maciej Szwed) [15:48:39] Diff URL: https://github.com/spdk/spdk/compare/7250ec64dbd6...e6100af425a7 [15:48:39] *** Parts: travis-ci (~travis-ci@ec2-54-198-67-21.compute-1.amazonaws.com) () [15:54:30] *** Joins: travis-ci (~travis-ci@ec2-18-215-229-189.compute-1.amazonaws.com) [15:54:30] (spdk/master) ipsec: move to version 0.52 (paul luse) [15:54:30] Diff URL: https://github.com/spdk/spdk/compare/e6100af425a7...6483aa3d156f [15:54:30] *** Parts: travis-ci (~travis-ci@ec2-18-215-229-189.compute-1.amazonaws.com) () [16:25:06] *** Quits: gila (~gila@94-212-217-121.cable.dynamic.v4.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [16:48:33] sethhowe: can you look at http://10.102.17.206/private_build/autotest-per-patch_29286.html [16:48:45] failure on the new srq overwhelm test [17:05:58] http://10.102.17.206/private_build/autotest-per-patch_29287.html [17:06:08] next patch also failed on this test [17:09:55] i've pushed a patch to revert for now [17:09:55] https://review.gerrithub.io/c/spdk/spdk/+/451997 [20:39:01] *** Joins: travis-ci (~travis-ci@ec2-54-90-132-45.compute-1.amazonaws.com) [20:39:02] (spdk/master) blobstore: change _spdk_bs_blob_list_remove() type to void (Maciej Szwed) [20:39:02] Diff URL: https://github.com/spdk/spdk/compare/58c4dac9d9a0...4b1012d5bf79 [20:39:02] *** Parts: travis-ci (~travis-ci@ec2-54-90-132-45.compute-1.amazonaws.com) () [20:39:51] *** Joins: travis-ci (~travis-ci@ec2-52-90-221-117.compute-1.amazonaws.com) [20:39:51] (spdk/master) test/notify: notifications functional test (Tomasz Kulasek) [20:39:51] Diff URL: https://github.com/spdk/spdk/compare/4b1012d5bf79...e8f4ae0969e4 [20:39:51] *** Parts: travis-ci (~travis-ci@ec2-52-90-221-117.compute-1.amazonaws.com) () [22:23:00] Project autotest-nightly build #475: STILL FAILING in 22 min. See https://dqtibwqq6s6ux.cloudfront.net for results. [22:29:40] Project autotest-nightly-failing build #339: STILL FAILING in 29 min. See https://dqtibwqq6s6ux.cloudfront.net for results. [22:40:43] *** Joins: travis-ci (~travis-ci@ec2-23-22-252-77.compute-1.amazonaws.com) [22:40:44] (spdk/master) test/crypto: always test aesni, even if qat is available (Jim Harris) [22:40:44] Diff URL: https://github.com/spdk/spdk/compare/e8f4ae0969e4...629c10928204 [22:40:44] *** Parts: travis-ci (~travis-ci@ec2-23-22-252-77.compute-1.amazonaws.com) () [22:45:31] *** Joins: travis-ci (~travis-ci@ec2-3-91-8-56.compute-1.amazonaws.com) [22:45:32] (spdk/master) test/vhost: add number of iterations for fio to run in benchmark (Karol Latecki) [22:45:32] Diff URL: https://github.com/spdk/spdk/compare/629c10928204...5a484d4ab82f [22:45:32] *** Parts: travis-ci (~travis-ci@ec2-3-91-8-56.compute-1.amazonaws.com) () [23:52:52] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-wlijpopehsshiskg)