[00:19:07] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-drkbvpllizrrkcrn) [00:42:57] *** Joins: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [01:41:55] *** Joins: alekseymmm (050811aa@gateway/web/freenode/ip.5.8.17.170) [01:51:38] *** Joins: pwodkowx (pwodkowx@nat/intel/x-ydnqpneexghkxlxf) [03:04:59] *** Joins: pniedzwx_ (86bfdc49@gateway/web/freenode/ip.134.191.220.73) [03:05:20] *** Parts: pniedzwx_ (86bfdc49@gateway/web/freenode/ip.134.191.220.73) () [03:09:02] *** Joins: pniedzwx (pniedzwx@nat/intel/x-sqfikvukvajnnzma) [04:18:54] *** Quits: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) (Ping timeout: 252 seconds) [04:21:50] *** Joins: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [06:27:27] *** Quits: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) (Ping timeout: 240 seconds) [06:29:53] *** Joins: gila (~gila@45.56.157.17) [06:34:07] *** Quits: gila (~gila@45.56.157.17) (Ping timeout: 240 seconds) [06:37:56] *** Joins: gila (~gila@45.62.37.39) [06:41:25] *** Quits: gila (~gila@45.62.37.39) (Client Quit) [08:21:27] lhodev: about libspdk.so and +x mode - check this https://review.gerrithub.io/#/c/spdk/spdk/+/431169/ [08:22:57] I think, that we are doing something unusual. We try to tell that libspdk.so is library but it is a linker script. We could switch to pkgcofnig tool... [08:23:12] to avoid need to libspdk.so [09:56:55] pwodkowx: I think of pkgconfig tool as a helper utility on which I would prefer we don't use as a crutch. Grouping multiple shared libs together into one "implicit linker script" as we do in libspdk.so actually isn't altogether that unusual. (glibc) libc.so even uses it. [09:58:50] I'm more mystified why my rpmbuild breaks when I remove execute on the "real" individual shared libs. I think that's really odd. However, that might "explain" why I see other shared libs on my Oracle Linux system that also have +x perms. [09:58:58] + sethhowe [12:26:19] *** Quits: tomzawadzki (uid327004@gateway/web/irccloud.com/x-drkbvpllizrrkcrn) (Quit: Connection closed for inactivity) [12:55:12] Why do some test summaries have a zero-length build.log (or even not one at all)? [13:38:31] lhodev: I think there is a race condition in the build pool test code. I am assuming you only see this on the chandler test pool right? [13:39:52] Now that you mention it, yes, it may just be on Chandler. [13:41:13] Do I remember that jimharris mentioning there's a way anyone -- not just maintainers -- can toggle something through Gerrit UI to re-run ? [13:43:02] lhodev: In the chandler pool, you should be able to just remove the chandler pool -1 from your patch by clicking in the corner. [13:43:47] lhodev: To rerun on the Jenkins pool, you can post a comment that starts with Retrigger [13:44:35] lhodev: Is there a specific build that you are looking at that doesn't have a build log? I'd like to look at it to see if I can root cause the reason the build logs aren't being copied properly. [13:45:52] https://ci.spdk.io/spdk/builds/review/5bd829fc797206dff66fa26ee60b5191ecdeb4f3.1540837010/ [13:46:09] Looks like it failed on fedora-03 [13:46:20] https://ci.spdk.io/spdk/builds/review/5bd829fc797206dff66fa26ee60b5191ecdeb4f3.1540837010/fedora-03/ [13:48:11] Perfect, thank you! [14:27:05] sethhowe: Have you root-caused the "Chandler race"? Difficult to fix? [14:29:59] lhodev: I can't seem to find it. That file is created at the beginning of the test in the internal output directory (We maintain two copies of the build pool results, the internal and external), and at the end of the test, that directory is copied to the public server. [14:31:45] lhodev: So the file definitely exists when the directory is copied over, and that can be shown since the file actually exists in the internal directory. I am trying to think of other reasons why an existing file wouldn't be copied over with the rest of the directory. [14:34:35] What cmd is being used to do the copy? [14:45:36] *** Joins: alekseymmm_ (050811aa@gateway/web/freenode/ip.5.8.17.170) [14:54:20] There are two copies. one using cp, the second using rsync. [15:01:08] lhodev: Looks like the file makes it through the first copy, and then gets stopped on the rsync over to ci.spdk.io [15:04:23] sethhowe: Maybe enable debug (-vv) for rsync in the script? Would the output of that be captured somewhere that could be viewed if/when this recurs ? [15:08:37] That's a good idea. I could try that. We usually keep a few thousand lines of output from our script. [15:17:32] Hello everyone. I have been working on some custom bdev in spdk. And I got this errors while submitting io [15:17:41] thread.c: 215:spdk_get_thread: *ERROR*: No thread allocated [15:17:52] fio: bdev.c:2953: _spdk_bdev_io_complete: Assertion `spdk_get_thread() == spdk_io_channel_get_thread(bdev_io->internal.ch->channel)' failed. [15:18:11] I run test with fio and it is core dumo [15:18:21] I run test with fio and it is core dump after the io [15:18:47] Any thoughts on what I am doing wrong? [15:19:31] when I run the same test with malloc bdev or null bdev it works well [15:19:48] but when I use real nvme devices it show this messages and coredumo [15:19:55] *dump [15:20:25] the thread that code is executing on is not an "spdk" thread - i.e. you have not called spdk_allocate_thread() on it [15:20:40] sure. I run it with fio_plugin [15:20:47] it is supposed to be fio thread [15:20:56] does your bdev spawn its own threads? [15:21:00] no [15:21:24] I do not so spdk_thread _alloc or similar [15:21:25] do you complete bdev_io on the same thread they were submitted on? [15:27:07] just working out the last changelog patches, then tagging the release [15:27:08] thx, going to check it more carefully [15:30:41] lhodev: found the source of the issue. We set a size limit in the rsync script to avoid copying core files and such to the external server. I can tweak it a little bit to hopefully avoid this issue in the future. [15:31:55] sethhowe: sweet ! [16:09:40] jimharris, can you same some some email reading time :) What's the AZ start time for tomorrow's community meeting? [16:10:32] 9 [16:10:51] !^&*#(EIGBKJ [16:11:13] This is going to be a problem for me... I'll figure it out though. Damn it [16:14:15] any time change in APAC that affects our Wed eve meetings? [16:15:23] no - it's still 8am our time [16:15:34] it moves up to 4pm Poland time [16:15:41] ohh I had it backward, sorry [16:15:45] so it's scheduled in AZ time [16:15:56] it's scheduled for GMT :) [16:16:04] yeah, with no regard for daylight savings [16:16:15] not GDT [16:16:17] Oh, what a relief. I was already rebooking other things [16:18:56] hey what did we end up doing for retrigger, hashtag for comment and its "retrigger" right? [16:19:01] (for the blog post) [16:19:30] just make a comment on the review (not a hashtag) with the word "retrigger" [16:21:01] grcias [16:21:04] grascias [16:21:08] oh I give up [16:21:15] thanks :) [16:25:51] *** Quits: alekseymmm_ (050811aa@gateway/web/freenode/ip.5.8.17.170) (Ping timeout: 256 seconds) [16:47:20] *** Joins: travis-ci (~travis-ci@ec2-54-198-225-48.compute-1.amazonaws.com) [16:47:21] (spdk/master) doc: describe dynamic memory management (Darek Stojaczyk) [16:47:21] Diff URL: https://github.com/spdk/spdk/compare/0491420405bb...3e2297140ca1 [16:47:21] *** Parts: travis-ci (~travis-ci@ec2-54-198-225-48.compute-1.amazonaws.com) () [16:57:00] hmmm , does retrigger take some time? here's the patch https://review.gerrithub.io/#/c/spdk/spdk.github.io/+/431032/ [18:10:08] I just updated the commit msg and this time the post showed as expected, when I submitted with the post filename pre-dated (I submitted Sat and used todays date) it didn't show in the build. Anyway, its there now. Please review, I can make the picture smaller too if anyone things its too large, i can never tell [20:45:04] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-mqpzbqxnkniaxvqn)