[01:03:07] *** Joins: tsuyoshi (b42b2067@gateway/web/freenode/ip.180.43.32.103) [01:59:19] *** Quits: changpeng (~changpeng@134.134.139.75) (Remote host closed the connection) [02:29:47] *** Joins: Roman_ (c0c6972b@gateway/web/freenode/ip.192.198.151.43) [04:09:35] *** Quits: tsuyoshi (b42b2067@gateway/web/freenode/ip.180.43.32.103) (Quit: Page closed) [07:50:27] *** Joins: jstern_ (~jstern@134.134.139.82) [08:19:17] *** Quits: sethhowe (~sethhowe@192.55.54.38) (Remote host closed the connection) [08:46:37] drv: we must not understand how uio_pci_generic works - karol says that the nvme hello_world example works if iommu is enabled and we use uio_pci_generic instead of vfio-pci [08:47:12] the iommu is opt-in [08:47:21] so even if it is enabled, you can still decide to not use it [08:47:37] i.e. use uio_pci_generic [08:48:02] it has to be explicitly activated for your process and a PCI device, which only vfio does [08:48:41] there is a vfio-pci no_iommu mode as of kernel 4.6 too [08:48:52] which happens to work even if there is an iommu, it just doesn't use it [08:57:14] is there any reason to test spdk w/ uio_pci_generic when the iommu is enabled? [08:57:51] karol is looking to improve test coverage - that patch that allows you to select the uio v. vfio driver in setup.sh [08:58:49] the only reason I see is if you have your iommu enabled but are using a very old kernel [08:58:51] that doesn't have vfio [08:59:06] but vfio was introduced in like kernel 3.6 [08:59:16] so that is far-fetched [08:59:20] yeah - i'm thinking this isn't a case we need to actively test [08:59:25] it's probably not worth it [09:06:36] drv: did you see ziyeyang's comment on your patch #7772? [09:26:31] not yet, let me take a look [09:34:49] jimharris: we can't actually specify the NQN in the FIO filename because ':' is not allowed [09:35:17] and every valid NQN has a colon in it [09:43:53] make sense - do you want to re-order your patch series so we can get the rest of the fio plugin ones in? [09:52:47] yeah, I put the transport ID one last [09:53:07] I'm just getting started - was intending to look into why we still get occasional random crashes of fio [09:53:13] but this stuff was the low-hanging fruit [09:58:33] *** Quits: peluse_ (~peluse@ip72-201-144-44.ph.ph.cox.net) (Remote host closed the connection) [10:31:58] *** Joins: jstern__ (~jstern@192.55.54.42) [10:31:58] *** Quits: jstern_ (~jstern@134.134.139.82) (Remote host closed the connection) [10:33:09] drv, bwalker: how bad do you hate this for the CC_TYPE matching? [10:33:30] if $CC -v 2>&1 | tail -n 1 | grep gcc > /dev/null; then [10:33:30] CC_TYPE=gcc [10:33:30] fi [10:34:05] my awk/sed/regexp-fu isn't advanced enough for anything more slick than that [10:34:16] you can do grep -q instead of > /dev/null [10:34:52] it's probably fine, until somebody decides to compile with icc or something :) [10:35:05] but should fix the freebsd case [10:35:11] yeah [10:35:12] which i need fixed before i can push my submodule stuff [10:35:43] fine with me [10:36:49] we could also try to extract the word before 'version' or something like that, but that is more complicated [10:38:25] gcc -v 2>&1 | tail -n1 | grep -o -E '\w+ version' | awk '{ print $1 }' [10:38:42] probably too much magic :) [10:39:05] mine is more verbose probably more readable for mere mortals :) [10:39:15] but probably [10:39:18] yeah, just trying to avoid hard-coding "gcc" and "clang" [10:39:29] sure [10:40:00] so the tail -n1 is probably not a good idea [10:40:14] the FreeBSD one has the version string in the first line [10:40:21] ugh [10:40:57] oh - just revert back to grep -w version [10:41:13] gcc -v 2>&1 | grep -o -E '\w+ version' | awk '{ print $1 }' [10:41:16] works on both, I think [10:41:51] yeah, I think that is the best way to go [10:42:14] -o makes it just print the matching part, which is 'clang version' or 'gcc version' [10:43:24] ok - your fix pushed [10:53:52] *** Joins: jstern_ (~jstern@192.55.54.42) [10:53:52] *** Quits: jstern__ (~jstern@192.55.54.42) (Remote host closed the connection) [14:35:16] whats up with the freebsd failures in the test pool? [14:37:39] it is something to do with copying the repo over sshfs rather than fetching it directly from git [14:37:44] not sure exactly what is going on yet [14:43:28] *** Quits: jstern_ (~jstern@192.55.54.42) (Ping timeout: 246 seconds) [15:00:19] *** Joins: jstern_ (~jstern@192.55.54.40) [17:11:35] *** Quits: jstern_ (~jstern@192.55.54.40) (Ping timeout: 240 seconds) [17:50:01] bwalker: i at least found the offending code in rocksdb causing the size mismatch errors [17:50:46] PosixWritableFile::Close() - look at the fallocate call near the end [18:00:57] *** Joins: ziyeyang_ (~ziyeyang@192.55.54.36) [19:03:05] *** Joins: johnmeneghini (~johnmeneg@pool-173-76-8-123.bstnma.fios.verizon.net) [19:05:10] *** Quits: johnm (~johnmeneg@pool-173-76-8-123.bstnma.fios.verizon.net) (Ping timeout: 264 seconds) [22:28:02] *** Joins: jstern_ (~jstern@134.134.139.76) [23:39:35] *** Quits: jstern_ (~jstern@134.134.139.76) (Ping timeout: 240 seconds)