Switch to DuckDuckGo Search
   July 11, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >

Toggle Join/Part | bottom
[00:14:36] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Quit: Leaving.)
[00:24:01] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[00:29:40] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has quit IRC (Ping timeout: 246 seconds)
[00:32:42] *** merzo <merzo!~merzo@141-63-132-95.pool.ukrtel.net> has joined #illumos
[00:52:34] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has quit IRC (Quit: Leaving.)
[01:03:35] *** Qatz <Qatz!~DB@2601:187:8400:5::83c> has joined #illumos
[01:06:44] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[01:16:26] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has joined #illumos
[01:17:50] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[01:21:09] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[01:25:03] *** merzo <merzo!~merzo@141-63-132-95.pool.ukrtel.net> has quit IRC (Ping timeout: 245 seconds)
[01:30:13] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has joined #illumos
[01:30:34] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has quit IRC (Ping timeout: 246 seconds)
[01:39:09] *** merzo <merzo!~merzo@36-51-132-95.pool.ukrtel.net> has joined #illumos
[01:44:38] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[02:32:05] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[02:33:07] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[02:37:38] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Ping timeout: 272 seconds)
[02:49:04] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has quit IRC (Quit: aszeszo)
[03:03:50] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has joined #illumos
[03:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[03:20:08] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[03:41:31] *** xzilla <xzilla!~robert@pool-71-166-61-131.bltmmd.fios.verizon.net> has joined #illumos
[03:46:15] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[03:46:25] *** xzilla <xzilla!~robert@pool-71-166-61-131.bltmmd.fios.verizon.net> has quit IRC (Ping timeout: 258 seconds)
[03:46:29] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[03:54:16] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has quit IRC (Ping timeout: 272 seconds)
[03:57:36] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has joined #illumos
[04:18:48] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[04:38:36] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has quit IRC (Ping timeout: 272 seconds)
[05:30:02] *** sanjay <sanjay!~Adium@97-118-92-228.hlrn.qwest.net> has joined #illumos
[05:41:57] *** xzilla <xzilla!~robert@pool-71-166-61-131.bltmmd.fios.verizon.net> has joined #illumos
[05:58:27] *** sanjay <sanjay!~Adium@97-118-92-228.hlrn.qwest.net> has quit IRC (Quit: Leaving.)
[07:15:35] *** IDoNotKn1w <IDoNotKn1w!epost@kudu.in-berlin.de> has quit IRC (Remote host closed the connection)
[07:16:15] *** IDoNotKnow <IDoNotKnow!epost@kudu.in-berlin.de> has joined #illumos
[07:16:58] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.103> has joined #illumos
[08:04:47] *** mnowak_ <mnowak_!mnowak_@nat/suse/x-hkkyozpwdsmsubuq> has quit IRC (Ping timeout: 258 seconds)
[08:05:07] *** mnowak_ <mnowak_!mnowak_@nat/suse/x-fkrnhnzkwcerqshu> has joined #illumos
[08:08:38] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has quit IRC (Quit: amrfrsh)
[08:17:20] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: tsoome)
[08:20:32] *** eki <eki!~eki@dsl-hkibng41-567327-143.dhcp.inet.fi> has quit IRC (Quit: leaving)
[08:30:37] *** eki <eki!~eki@dsl-hkibng41-567327-143.dhcp.inet.fi> has joined #illumos
[08:34:01] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[08:40:44] *** alanc <alanc!~alanc@129.157.69.51> has quit IRC (Remote host closed the connection)
[08:41:13] *** alanc <alanc!~alanc@129.157.69.51> has joined #illumos
[08:54:45] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[09:05:40] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[09:06:34] *** MarcelT <MarcelT!~marcel@tortuga.telka.sk> has joined #illumos
[09:09:59] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[09:12:33] *** wiedi <wiedi!~wiedi@91.64.150.166> has quit IRC (Quit: ^C)
[09:36:07] <gitomat> [illumos-gate] 11379 Local changes to nvme.conf should persist across updates -- Andy Fiddaman <omnios at citrus-it dot co.uk>
[09:57:22] *** andy_js <andy_js!~andy@94.12.186.242> has joined #illumos
[10:02:15] *** rzezeski <rzezeski!uid151901@gateway/web/irccloud.com/x-nvsdrnuovaichybq> has quit IRC (Quit: Connection closed for inactivity)
[10:34:31] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[10:47:18] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[11:22:34] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has joined #illumos
[11:23:10] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has quit IRC (Client Quit)
[11:31:48] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has joined #illumos
[11:48:33] *** BH23 <BH23!~BH23@194.75.135.30> has joined #illumos
[11:57:21] *** merzo <merzo!~merzo@36-51-132-95.pool.ukrtel.net> has quit IRC (Ping timeout: 248 seconds)
[12:13:31] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[12:14:19] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[12:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[12:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[12:20:12] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[12:25:54] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[12:28:17] *** psarria <psarria!~psarria@50.red-81-39-73.dynamicip.rima-tde.net> has quit IRC (Ping timeout: 248 seconds)
[12:28:49] *** BH23 <BH23!~BH23@194.75.135.30> has quit IRC (Ping timeout: 248 seconds)
[12:40:59] *** elegast <elegast!~elegast@83-161-160-28.mobile.xs4all.nl> has joined #illumos
[12:42:39] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[12:42:59] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[12:56:01] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[12:56:29] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[12:58:17] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[12:59:00] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[12:59:27] <jlevon> so much new smatch
[13:03:47] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Ping timeout: 245 seconds)
[13:08:20] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.103> has quit IRC (Quit: Leaving)
[13:09:08] <andyf> Oh :(
[13:09:08] <jlevon> why the heck does $< not work in dmake without %
[13:09:22] <jlevon> andyf: we were so close, hah.
[13:09:44] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Ping timeout: 268 seconds)
[13:10:52] <andyf> I couldn't believe that the hyperv stuff we took into OmniOS was smatch clean, but it apparently was
[13:12:22] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[13:12:25] <andyf> Where has it come from? I knew about the few smb things
[13:13:39] <jlevon> bit of zfs, other bits
[13:14:59] <jlevon> weird ficl-related error
[13:15:22] <jlevon> /export/home/gk/src/illumos-gate/usr/src/common/ficl/ficl.h:168:23: error: ficllocal.h: No such file or directory
[13:16:13] <jlevon> ../../../../../lib/libzpool/common/sys/zfs_context.h:98:10: error: unable to open 'zfs.h'
[13:16:14] <jlevon> too
[13:16:15] <jlevon> whut.
[13:32:36] <jlevon> looks like the smbsrv build is racy too
[13:41:31] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[13:47:37] <andyf> Is there an issue open yet for the problems with incremental builds with the new ctf tools?
[13:49:49] <jlevon> vague memory of one getting filed
[13:50:02] <andyf> I'm searching for the wrong thing then
[13:50:56] <jlevon> hmm
[13:52:38] <jlevon> I've sort of forgotten what goes wrong.
[13:52:45] <jlevon> we get a bad parent label right
[13:52:59] <andyf> ctfmerge: failed to merge types: Merged labels conflict
[13:53:26] <jlevon> oh, it's if we moved to a new HEAD
[13:53:27] <jlevon> right?
[13:53:46] <andyf> It could be, that would make sense
[13:54:00] <jlevon> so ctf ain't wrong really.
[13:54:04] <andyf> I was trying to rebuild the nvme driver in a tree that was already built
[13:54:15] <andyf> (with a patch, so I'd probably added a commit)
[13:57:27] <jlevon> I don't really know what to do there.
[13:57:39] <andyf> Oh, I see, it uses $VERSION for the label
[13:57:43] <jlevon> yeah
[13:58:47] <andyf> I suppose if I'm just working on a patch for a single driver, I can just override the environment then
[14:00:05] <andyf> heh - it actually depends on the HEAD when you enter the bldenv I suppose
[14:01:19] <jlevon> yeah :/
[14:04:30] *** jvl <jvl!~jvl@mei.hadret.com> has left #illumos
[14:06:32] <andyf> Perhaps I'll make bldenv override VERSION if it finds a built genunix
[14:07:14] <andyf> It might only apply to OmniOS where the label ends up being something like omnios-master-0281f54eb3
[14:10:08] <jlevon> or maybe we should be laxer about a build inside bldenv. dunno
[14:11:15] *** jellydonut <jellydonut!~quassel@s91904425.blix.com> has quit IRC (Ping timeout: 258 seconds)
[14:14:23] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.103> has joined #illumos
[14:33:13] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:33:31] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:34:36] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:34:50] *** freakazoid0223 <freakazoid0223!~matt@pool-96-227-98-169.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)
[14:35:01] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:36:08] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:36:31] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:36:53] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:37:31] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:37:57] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:38:30] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:39:00] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:39:27] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:39:57] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:40:38] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:42:24] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:42:43] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:43:40] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:44:23] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:47:36] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:48:11] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:49:54] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:50:45] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:56:53] *** BH23 <BH23!~BH23@194.75.135.30> has joined #illumos
[14:57:16] *** merzo <merzo!~merzo@193.111.51.133> has joined #illumos
[15:02:33] *** merzo <merzo!~merzo@193.111.51.133> has quit IRC (Ping timeout: 245 seconds)
[15:12:33] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (Ping timeout: 248 seconds)
[15:29:38] *** BH23 <BH23!~BH23@194.75.135.30> has quit IRC (Ping timeout: 245 seconds)
[15:39:22] *** merzo <merzo!~merzo@31.128.69.41> has joined #illumos
[15:55:05] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[16:00:02] *** jellydonut <jellydonut!~quassel@ti0577q162-0475.bb.online.no> has joined #illumos
[16:03:50] <LeftWing> andyf: You could put the VERSION you're using in a file and remove and regenerate the file under some conditions, like a full nightly
[16:04:17] <andyf> I think I'm going to try https://github.com/omniosorg/illumos-omnios/pull/511/files for a while
[16:04:29] <jlevon> I'm wondering if we should do that generally. incremental == no new VERSION
[16:04:57] <jlevon> or, actually, no new CTF label
[16:05:07] <jlevon> the rest of VERSION-related things could still change.
[16:07:07] <jlevon> andyf: or, how about a version of that, but only for ctf label, and only for uts/
[16:07:07] <LeftWing> Where does the string for uname come from? unix?
[16:07:21] <andyf> platform/unix I think
[16:07:52] <LeftWing> So you'd need to rebuild that, at least, to get a new string
[16:08:00] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has joined #illumos
[16:08:28] <jlevon> LeftWing: that comes from the ctf label?
[16:08:30] <andyf> Yes, and SUNWcs delivers etc/motd which has the string in it too
[16:08:49] <andyf> but, I only ever do a full nightly, or incremental stuff by hand in a bldenv
[16:08:51] <LeftWing> jlevon: I thought we used VERSION for both
[16:08:57] <jlevon> andyf: I think you could do something like: when we build genunix, we write out something to uts/version or whatever
[16:09:04] <jlevon> LeftWing: yeah, I'm saying we need to separate them out
[16:09:12] <LeftWing> Have you considered a constant VERSION and just including the git status information in the kernel like we do in SmartOS?
[16:09:21] <jlevon> andyf: then make all of uts/ pick that up via -l instead of -L or whatever.
[16:09:25] <LeftWing> (during development)
[16:09:41] <jlevon> LeftWing: does this mean you'll let me upstream that module now :P
[16:09:47] <LeftWing> Ha!
[16:11:15] <LeftWing> If we can figure out how to do it in a generic enough way, that seems fine?
[16:11:50] <jlevon> let me take a look then.
[16:12:02] <andyf> jlevon, at the module, or uts/version?
[16:12:10] <andyf> That seems like a good approach
[16:12:16] <jlevon> the module thing. then maybe we can just use a fixed label
[16:12:24] <LeftWing> Maybe we provide a default implementation but allow you to override the program used to generate the string if you want
[16:12:32] <andyf> I'm sure that some distributions do use a fixed label
[16:12:35] <andyf> and some won't
[16:12:46] <jlevon> LeftWing: yeah, or have a nightly option that points to a file. I'll experiment a little.
[16:13:04] <LeftWing> I think you want a fixed label when you're taking on the responsibility of making sure that's correct
[16:13:15] <LeftWing> And a git based one at other times
[16:13:16] <rmustacc> If version is changing, you kind of want the MCS comment/CTF label to match, imho.
[16:13:47] <jlevon> but it already doesn't in the kind of thing we're talking about.
[16:14:04] <rmustacc> Which I think is a mistake.
[16:14:17] <jlevon> so what, we rebuild the world every time we have a new HEAD?
[16:14:18] <rmustacc> If version changes, you want to rebuild all binaries.
[16:14:19] <andyf> In general, this works fine as I do full builds, but if I'm just working on a driver, incremental builds are hard without manually setting VERSION
[16:14:28] <jlevon> gets tedious VERY quickly
[16:14:38] <rmustacc> jlevon: Not trying to say the default version is the right one.
[16:14:47] <rmustacc> But that the policy in CTF isn't wrong, imho.
[16:15:00] <jlevon> it's not CTF itself that's the issue, I agree, if that's what you meant.
[16:15:07] <jlevon> it's how we're setting the label names.
[16:15:13] <rmustacc> Right.
[16:15:32] <rmustacc> If you do change the version, you should rebuild everything. We shouldn't change the version every time we change head probably.
[16:15:39] <rmustacc> Was just trying to separate out the two.
[16:15:49] <jlevon> makes sense.
[16:15:59] <andyf> So an early uts/version target which just puts $VERSION in there would mean that incremental builds would keep using the same version
[16:16:02] <jlevon> let's not fix the first before the second :)
[16:16:04] <andyf> as long as it was removed by clobber...
[16:16:45] <andyf> Off to watch the cricket, bbl
[16:16:52] <rmustacc> Enjoy the tricket.
[16:16:55] <rmustacc> Erm, cricket
[16:17:07] <rmustacc> jlevon: Wasn't trying to suggest we should automate the first per se.
[16:17:16] <jlevon> oh, right.
[16:17:22] <rmustacc> Just trying to point out the oddities from my perspective.
[16:17:48] <rmustacc> An incremental build where version changes is a weird thing because we haven't actually gone and fixed version everywhere.
[16:18:24] <rmustacc> Not actually disagreeing with any of the things everyone's proposing.
[16:18:51] <rmustacc> Just wanted to just share my view on VERSION, the ctf label, and the mcs comment (since most folks don't know it's in there)
[16:19:29] <jlevon> yeah, think I agree with your points then.
[16:22:19] *** Lirion <Lirion!~m00se@wikimedia-commons/Lirion> has joined #illumos
[16:22:21] *** rzezeski <rzezeski!uid151901@gateway/web/irccloud.com/x-ecbqgombpdnbrvnk> has joined #illumos
[16:28:33] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[16:28:49] *** baojg <baojg!~baojg@162.243.44.213> has quit IRC (Remote host closed the connection)
[16:30:36] <tsoome> jlevon: going to switch it on permanently?:)
[16:30:56] <jlevon> smatch? soon hopefully
[16:32:34] <tsoome> cool
[16:34:16] *** merzo <merzo!~merzo@31.128.69.41> has quit IRC (Ping timeout: 246 seconds)
[16:36:56] *** freakazoid0223 <freakazoid0223!~matt@pool-96-227-98-169.phlapa.fios.verizon.net> has joined #illumos
[16:39:52] <tsoome> I am getting closer to be abble to push https://illumos.org/rb/r/1897/ too:)
[16:40:43] <rmustacc> tsoome: Can we at least push the kernel version if it's ready?
[16:41:13] <rmustacc> Also, we should probably ask jperkin to do a bulk build of the userland version of it at some point.
[16:41:13] <jlevon> cool
[16:41:26] <tsoome> I still havent had time to check over https://illumos.org/rb/r/1687/
[16:41:39] <rmustacc> Because we're going to ask about that when an RTI comes in.
[16:42:05] <tsoome> it should be last one from kernel, or maybe something related to SMB too..
[16:42:35] <rmustacc> As while it's good to get ourselves clean, worth the sanity check that we don't have a lot of fall out from building all the 3rd party software. (Which I don't expect, but would feel a lot better knowing)
[16:42:53] <tsoome> yes, hm, actually, if we can build pkgsrc sruff without illumos bits, we can start already
[16:43:13] <khng300> i am going to send this again: it seems that illumos is directly overwriting the content of Vector Control register in MSI-X table entry without preserving the fields except mask bit which may not be in compliance with PCI 3.0 (2004)? https://reviews.freebsd.org/rS349845 http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/pci_intr_lib.c#530
[16:44:08] <rmustacc> Thanks, khng300. We'll take a look at that. In practice since no other bits have been defined, hard to say that there are going to be a lot of problems, but agree we should probably take a look at it.
[16:45:25] <igork> question: illumos.org = IP:165.225.149.224
[16:45:33] <tsoome> do we have acess to PCI specification btw?
[16:45:34] <khng300> rmustacc: np. having said that it seems quite uncommon to see cases regarding the issue.
[16:45:34] <igork> how old this ip?
[16:45:49] <igork> it was another one
[16:46:16] <LeftWing> I provisioned a new web frontend a few days ago
[16:46:35] <igork> probably it was on another hoster before and this ip blocked in Russia
[16:46:48] <LeftWing> It was on Joyent before and is still on Joyent now
[16:46:50] <tsoome> ou
[16:46:52] <rmustacc> khng300: It seems the bhyve issues there is more about Samsung drives that don't respect this than what we're doing?
[16:47:08] <denk> could you move illumos.org to another ip? current address is blocked in ru :(
[16:47:22] <igork> LeftWing: ^^^
[16:47:33] <LeftWing> I can look at it. How will I know which IP addresses are safe to use?
[16:47:45] <tsoome> that is good question;)
[16:48:03] <igork> just ask on this channel - guys from provides can reply
[16:48:18] <igork> i'll try to ask
[16:48:18] <LeftWing> No I don't think that's a good idea
[16:48:23] <khng300> rmustacc: oh, it is actually that i observed that the 9th IO queue always missed interrupts on FreeBSD when using SM961. Then I move on to test the samsung ssd on OI and found that it worked perfectly.
[16:48:45] <igork> LeftWing: blocked ip not available in public access
[16:49:05] <LeftWing> I'm not going to keep trying random new IPs and asking you if it works now
[16:49:15] <igork> thanks
[16:49:16] <LeftWing> You could provide me a shell account and I can check myself
[16:49:33] <rmustacc> khng300: Oh. I misunderstood. I thought the change was actually working around something we did.
[16:49:34] <igork> we can provide vm
[16:49:48] <khng300> 9th IO queue -> 8th IO queue *
[16:52:24] <rmustacc> Yeah, that does violate the spec. But if hardware also doesn't support reads. Ugh.
[16:57:03] <ptribble> LeftWing: there are checkers like https://www.comparitech.com/privacy-security-tools/blockedinrussia/ or https://isitblockedinrussia.com/
[16:58:26] *** nia <nia!znc@netbsd/developer/niaa> has quit IRC (Quit: ZNC 1.7.3 - https://znc.in)
[17:01:10] <gitomat> [illumos-gate] 11333 exstr: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:01:40] <denk> https://isitblockedinrussia.com/?host=illumos.org - blocked
[17:06:09] <jperkin> looks like my new server is blocked too, fun
[17:06:32] <gitomat> [illumos-gate] 11334 file: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:08:50] <gitomat> [illumos-gate] 11335 mailx: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:10:42] <gitomat> [illumos-gate] 11336 find: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:12:49] <gitomat> [illumos-gate] 11337 geniconvtbl: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:16:43] <LeftWing> Oh, Russia. :/
[17:17:13] <Smithx10> rofl
[17:18:36] <gitomat> [illumos-gate] 11338 format: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:20:21] <igork> LeftWing: the same/similar what NSA do.. but no politics ...
[17:22:36] <LeftWing> The NSA has not, to my knowledge, ever blocked our bug tracker.
[17:22:37] *** nia <nia!znc@netbsd/developer/niaa> has joined #illumos
[17:25:36] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 258 seconds)
[17:29:58] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[17:33:26] <gitomat> [illumos-gate] 11339 getent: NULL pointer errors -- Toomas Soome <tsoome at me dot com>
[17:41:48] *** merzo <merzo!~merzo@31.128.69.41> has joined #illumos
[17:49:46] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Quit: Leaving.)
[17:49:48] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[17:54:13] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 245 seconds)
[17:59:33] *** merzo <merzo!~merzo@31.128.69.41> has quit IRC (Remote host closed the connection)
[18:23:37] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Quit: Leaving.)
[18:23:39] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[18:25:14] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[18:25:37] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[18:35:52] <LeftWing> igork, denk: Give the site a try now?
[18:38:40] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[18:40:10] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[18:43:55] <igork> LeftWing: it is working to me
[18:44:02] <igork> will try to ask others
[18:45:54] <denk> LeftWing: it works, thanks!
[18:50:51] *** hemi770 <hemi770!~hemi666@unaffiliated/hemi770> has quit IRC (Remote host closed the connection)
[18:51:35] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[18:54:56] <LeftWing> Great! You're welcome.
[19:27:22] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: No route to host)
[19:28:01] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[19:28:19] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[19:29:42] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[19:32:09] *** sarvet <sarvet!~sarvet@dslb-092-073-080-206.092.073.pools.vodafone-ip.de> has joined #illumos
[19:40:43] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: Connection reset by peer)
[19:43:02] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[19:46:28] <gitomat> [illumos-gate] 11227 smb code needs smatch fixes -- John Levon <john.levon at joyent dot com>
[19:52:48] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Ping timeout: 258 seconds)
[19:55:05] <sjorge> ^ - wount that make the few remaining PR's for gwr harder?
[19:58:07] <rmustacc> sjorge: No. We talked through it with gwr.
[19:59:37] <sjorge> Ah nice!
[20:02:06] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[20:02:06] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[20:02:58] *** amrmesh <amrmesh!~Thunderbi@2001:638:502:5001::109f> has joined #illumos
[20:04:15] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[20:04:45] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has quit IRC (Ping timeout: 268 seconds)
[20:04:45] *** amrmesh is now known as amrfrsh
[20:07:22] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[20:09:44] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[20:11:42] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[20:13:57] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[20:14:17] *** andy_js <andy_js!~andy@94.12.186.242> has quit IRC (Read error: Connection reset by peer)
[20:14:52] *** andy_js <andy_js!~andy@94.12.186.242> has joined #illumos
[20:16:21] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[20:16:53] *** leoric_ <leoric_!~leoric@2a00:1fa1:43a9:fccf:85b4:6dbb:52be:a155> has joined #illumos
[20:18:35] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has joined #illumos
[20:18:35] *** sanjay <sanjay!~Adium@96-66-65-68-static.hfc.comcastbusiness.net> has quit IRC (Client Quit)
[20:19:30] *** papertigers <papertigers!~papertige@pool-108-55-27-43.bflony.fios.verizon.net> has joined #illumos
[20:20:20] *** s-mutin <s-mutin!~s-mutin@85.234.114.134> has quit IRC (Remote host closed the connection)
[20:21:43] *** elegast <elegast!~elegast@83-161-160-28.mobile.xs4all.nl> has quit IRC (Ping timeout: 245 seconds)
[20:21:46] *** s-mutin <s-mutin!~s-mutin@85.234.114.134> has joined #illumos
[20:29:35] <gitomat> [illumos-gate] 11327 scalb should not be exposed in XPG7 -- Garrett D'Amore <garrett at damore dot org>
[20:32:20] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[20:41:14] <leoric_> LeftWing: if you are really interested, there is https://github.com/zapret-info/z-i/ (or official source - https://eais.rkn.gov.ru/en/)
[20:45:21] *** jubal_ <jubal_!~jubal@226-5-237-24.gci.net> has quit IRC (Ping timeout: 248 seconds)
[20:45:28] *** leoric_ <leoric_!~leoric@2a00:1fa1:43a9:fccf:85b4:6dbb:52be:a155> has quit IRC (Quit: Konversation terminated!)
[20:46:11] <LeftWing> leoric: According to that site, the problem IP 165.225.149.224 says: "The requested address is not blacklisted"
[20:46:48] <LeftWing> Which certainly meets my Kafka-esque expectations for this entire rubbish fire.
[20:47:04] <denk> that site lies most of the time
[20:53:23] <denk> one day they blocked google and youtube, nobody understood why
[20:53:45] <denk> in some time they unblocked them
[21:03:18] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[21:09:25] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.103> has quit IRC (Quit: Leaving)
[21:09:53] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[21:10:02] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: No route to host)
[21:10:32] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[21:14:57] *** vaxsquid <vaxsquid!~vaxsquid@208.73.20.91> has quit IRC (Quit: Coffee is for closers!)
[21:21:53] *** vaxsquid <vaxsquid!~vaxsquid@2604:4100:0:1d:b72::1> has joined #illumos
[21:25:50] <andyf> I think I've asked this before, but my notes are not reachable from here, so apologies in advance, but how could I see the softstate for a HBA driver?
[21:26:10] <andyf> I can't work out how to dump the devinfo_t struct
[21:26:23] <richlowe> from where?
[21:27:55] <andyf> well starting from ::devnames, but I always get
[21:27:56] <andyf> >
[21:28:00] <andyf> mdb: failed to look up type devinfo_t: no symbol corresponds to address
[21:28:08] <richlowe> that's 'cos the type is dev_info_t
[21:28:36] <andyf> I have a vague memory that there's a private type that needs to be used for some reason
[21:28:38] <andyf> oh, well that gets me to
[21:28:39] <andyf> fffffe16d92ed008 dev_info_t 0xfffffe16d92ed800
[21:29:42] <LeftWing> andyf: ::print struct dev_info devi_driver_data ?
[21:29:49] <LeftWing> Which HBA driver, though?
[21:29:53] <andyf> nvme
[21:29:55] <LeftWing> Ah
[21:30:13] <LeftWing> It uses soft states
[21:30:33] <LeftWing> So you could *nvme_state::softstate 0 | ::print nvme_t
[21:30:34] <richlowe> ::softstate then?
[21:30:39] <LeftWing> (0 is the instance number there)
[21:30:44] <richlowe> y'all typing faster than I'm thinking today
[21:31:02] <richlowe> It would be nice if mdb was less literal about opaque types.
[21:31:29] <LeftWing> I think it's a bit hard for it not to be when we try (at the C level) to be that opaque
[21:31:48] <LeftWing> I have often though it would be nice to be able to specify some additional annotations that the CTF could then pull in
[21:31:49] <richlowe> LeftWing: it could at least note in it's output it hit a forward ref to an undefined type
[21:32:02] <LeftWing> I could stop abusing enums if we could figure out some other way to get the names in for bitfield rendering
[21:32:36] <andyf> Ah right, I need to remember to use 'struct devinfo'
[21:32:51] <andyf> but I'll try softstate (well, I'll ask @hadfl to)
[21:32:56] <richlowe> andy would have an easier time remembering that if dev_info_t gave a clue!
[21:32:59] <andyf> and if he's here, we can cut out the middle man
[21:33:14] <richlowe> ffffff06cdf5a010 dev_info_t 0xffffff06cde6eaa0 is a poor clue
[21:33:19] <LeftWing> That is true.
[21:34:03] <LeftWing> I should eat lunch.
[21:35:55] <andyf> Perfect, thanks both, ::softstate worked
[21:36:22] <LeftWing> Great!
[21:50:36] *** jubal <jubal!~jubal@24.237.158.16> has joined #illumos
[21:54:46] *** jubal <jubal!~jubal@24.237.158.16> has quit IRC (Read error: Connection reset by peer)
[21:57:02] *** jubal <jubal!~jubal@24.237.158.16> has joined #illumos
[22:02:25] *** andy_js <andy_js!~andy@94.12.186.242> has quit IRC (Read error: Connection reset by peer)
[22:02:45] *** andy_js <andy_js!~andy@94.12.186.242> has joined #illumos
[22:18:18] *** andy_js <andy_js!~andy@94.12.186.242> has quit IRC (Read error: Connection reset by peer)
[22:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[22:20:06] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[22:20:38] *** andy_js <andy_js!~andy@94.12.186.242> has joined #illumos
[22:28:29] <andyf> We've got an interesting problem with an nvme drive. I'm hoping somebody might have some pointers
[22:29:11] <andyf> for an OS read of 512 bytes from the start of the device, bd_check_uio in blkdev returns EINVAL as the read is not a multiple of the block size (shift=12)
[22:30:01] <andyf> should there be read inflation happening somewhere in between the read() syscall and blkdev?
[22:31:55] <danmcd> How does a 512n device handle a read of 32 bytes, I wonder?
[22:34:08] <danmcd> Can you downstack-dtrace the read to see where it fails? e.g use http://kebe.com/dtrace/downstack.d
[22:38:53] <danmcd> Okay, I see why it failed, but I wonder what happens for non-BD devices?
[22:39:14] <andyf> I've asked him (hadfl) - here's some of what we have gathered so far
[22:39:14] <andyf> https://paste.ec/paste/Da6let-Q#dBk+f8I5wHXnvyhRJ29NjCf0VwIG4kj1xAOQryJoyya
[22:39:45] <andyf> in userland, it's just effectively read(open("/dev/..."), buf, 512)
[22:40:26] <andyf> receiving a ZFS send stream onto the device worked fine, but the pool is ashift 12 (although compressed, so..)
[22:42:03] <andyf> We use blkdev all the time for vioblk, so I have no idea what's going on yet
[22:42:26] <andyf> Also - # dd if=omniosce-bloody-20190703.iso of=/dev/rdsk/c3t1d0p0 bs=512
[22:42:26] <andyf> write: Invalid argument
[22:43:20] <danmcd> sdread seems to enforce this as well:
[22:43:21] <danmcd> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/scsi/targets/sd.c#11056
[22:43:57] <danmcd> I wonder if you did bs=256 to a normal HD if you'd ge the same error.
[22:44:45] <andyf> Indeed you do
[22:44:46] <andyf> reaper# dd if=/dev/zero of=/dev/rdsk/c0t8d1p0 bs=256 count=2
[22:44:47] <andyf> write: Invalid argument
[22:45:13] <andyf> That's an old 1TB Seagate
[22:47:05] <danmcd> Noice.
[22:47:21] <danmcd> So then the question becomes, how best to determine blocksize for a raw(ish) device like this?
[22:47:42] <rmustacc> The DKIO ioctls are defined for this.
[22:47:45] <andyf> My question is, do we expect a short read from userspace to fail with EINVAL just because the native block size is larger?
[22:48:17] <andyf> (and if so, I guess nobody is booting from 4kn disks yet!)
[22:48:43] * danmcd checks his ssds...
[22:48:46] *** sarvet <sarvet!~sarvet@dslb-092-073-080-206.092.073.pools.vodafone-ip.de> has quit IRC (Read error: Connection reset by peer)
[22:49:05] <danmcd> Yeah, ashift=9 (but maybe that's 4kn/512e ?!?).
[22:49:15] *** sarvet <sarvet!~sarvet@dslb-092-073-080-206.092.073.pools.vodafone-ip.de> has joined #illumos
[22:49:28] <Woodstock> sd has some provisions to do read-modify-write, but it prints a warning whenever that happens
[22:49:31] <andyf> It's the blkdev shift that matters
[22:50:20] <andyf> Woodstock - the problem that started this is that we can't install the bootblocks on an nvme drive.. installboot tries to read the first 512 bytes from the disk
[22:50:20] <Woodstock> blkdev just doesn't support that, and i'm not sure we should add it
[22:50:40] <Woodstock> i'd say thats a bug in installboot, then
[22:51:12] <Woodstock> it should get the logical blocksize from the device and use that
[22:51:25] <andyf> Sounds right
[22:51:42] <danmcd> Didn't rmustacc just saysomething about DKIO? :)
[22:51:54] <Woodstock> yes, thats the way to do that
[22:51:55] <rmustacc> That's an ioctl to get the sector size related bits.
[22:52:03] <rmustacc> I swear we already did something in this area.
[22:52:04] <Woodstock> i'm surprised that installboot doesn't do it already
[22:52:07] <rmustacc> Maybe itw as format.
[22:53:15] <andyf> installboot (and grub and lots of other boot stuff) has `#define SECTOR_SIZE (512)`
[22:53:30] <Woodstock> awesome
[22:53:37] <danmcd> Break out the rototiller.
[22:53:50] <andyf> hadfl will have to wait a bit longer to switch to UEFI boot from his nvme device
[22:54:00] <danmcd> I wonder if tsoome is aware of this issue?
[22:54:11] <rmustacc> It's not tsoome's problem.
[22:54:22] <rmustacc> (Though obviously if tsoome wants to work on it, that's great)
[22:54:26] <andyf> No, but he might already have a patch, or be aware
[22:54:36] <andyf> as I know he is looking at installboot in terms of automatically managing the ESP
[22:55:17] *** elegast <elegast!~elegast@83-161-160-28.mobile.xs4all.nl> has joined #illumos
[22:56:07] <danmcd> When I saw "grub and lots of other boot stuff" I thought of tsoome.
[22:56:16] <danmcd> (because "other boot stuff").
[22:56:36] <andyf> https://paste.ec/paste/xMJVD-kM#YRIqBpvU19cqPEn-74F7DKAesk2yszsbjj4Ne+U/QtA
[22:58:43] <danmcd> Impressive.
[23:01:07] *** elegast <elegast!~elegast@83-161-160-28.mobile.xs4all.nl> has quit IRC (Ping timeout: 268 seconds)
[23:02:59] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-04.gwi.net> has joined #illumos
[23:06:00] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 244 seconds)
[23:07:54] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-04.gwi.net> has quit IRC (Ping timeout: 268 seconds)
[23:22:30] <andyf> installboot already looks complicated enough in terms of where it puts the different bits on the disk, and patches some of them in order that they can find the others
[23:23:05] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[23:25:37] *** basvdlei <basvdlei!~basvdlei@2001:980:a4c3:1:80f2:2bd8:393d:9cf5> has joined #illumos
[23:47:16] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has joined #illumos
top

   July 11, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >