13:33:23 <tsoome_> .oO Nov  1 10:18:37 beastie pcie: [ID 324549 kern.warning] WARNING: pci_pci-1: encountered PCIe device without PCIe capability
13:33:39 <yuripv> -1?
13:38:33 <tsoome_> seems -1 yes
13:49:33 <andyf> Another one? Seems they are not as uncommon as suspected.
13:50:38 <andyf> That's issue 15056 (fenix)
13:50:39 <fenix> BUG 15056: Missing pcie cap leads to panic in pcie_fabric_feature_scan() (Closed)
13:50:40 <fenix> ↳ https://www.illumos.org/issues/15056 | https://code.illumos.org/c/illumos-gate/+/2450
18:08:03 <gitomat> [illumos-gate] 14568 bhyve should support pause/resume -- Patrick Mooney <pmooney⊙pc>
19:10:55 <copec> There seems to be a history of (at least an attempt) at high quality C for illumos, have there been interesting bugs that have made it past lint?
19:12:04 <copec> I've been actually learning Rust, even though I went through the Rust Book years ago
19:17:23 <tsoome_> I'm sure we have lot of bugs still in hidden
19:17:45 <tsoome_> clang is exposing them atm...
19:21:05 <copec> Is illumos building with llvm?
19:21:33 <tsoome_> not yet
19:22:16 <tsoome_> I have cleaned handful of libraries and few other bits from build system
19:35:37 <richlowe> _lots_ of bugs make it past lint
19:51:46 <copec> How many bugs are higher level than the programming language constraints? Do you think they would manifest if written in Rust?
19:52:11 <richlowe> rust or similar would have saved me personally from lots of annoyance
19:52:17 <richlowe> except for having to write all the rust-y stuff in support
19:53:32 <richlowe> not much use using rust if all your access to system facilities is directly via unsafe and C
19:53:44 <richlowe> someone needs to step up and write the good rusty abstractions for ... everything
19:54:40 <jclulow> I think there's still a lot of value in new code being safe even if most of the things it initially depends upon are not safe
19:55:03 <richlowe> I think I just said what I meant poorly
19:55:44 <richlowe> if the new code you write is, indeed, not largely `unsafe' in the rust-y sense, then yeah
19:56:50 <richlowe> I would look very favourably on anyone who knew how making the effort, definitely
19:59:45 <copec> I don't know how, but I've convinced myself I can figure anything out as long as it doesn't make me motion sick.
20:02:05 <copec> ^tongue in cheek 
20:02:37 <richlowe> I have forgotten what availdevs(1? 8?) does, but if someone (jbk? yurip?) wanted to rewrite it to not, for reasons I can't even begin to fathom, use the JNI libzfs directly from C, rather than libzfs, I'd be grateful .
20:02:59 <richlowe> yuripv: I know you like deleting things, think of it is letting you maybe delete libzfs_jni one day :)
20:05:09 <jclulow> whaaaaaaat
20:05:28 <jclulow> what fresh hell is this
20:08:18 <jclulow> who even uses this
20:08:48 <andyf> just usr/src/tools/quick/make-zfs as far as I can see
20:08:56 <andyf> it core dumps on my system too (availdevs)
20:08:59 <jclulow> ha
20:09:03 <richlowe> my guess is maybe it was tsol?
20:09:14 <richlowe> or something
20:09:39 <jclulow> oh good lord tools/quick
20:09:53 <richlowe> that's gordon wanting to gordon
20:11:57 <jclulow> good grief why are the getopts characters in the header
20:12:43 <jclulow> https://gist.github.com/jclulow/84e075658d4a88437a3ee6f7f580f935
20:13:06 <yuripv> :)
20:14:57 <jclulow> I cannot find anything in GitHub or a cursory glance at Google that runs /usr/lib/zfs/availdevs
20:15:23 <jclulow> It's not in PATH, and it sucks: I think we should delete it
20:15:26 <richlowe> neither could I, it came it with ZFS
20:15:40 <jclulow> I assume it is either for an installer (but not caiman?) or the ZFS appliance
20:15:51 <jclulow> But probably the appliance did something else anyway
20:16:23 * jclulow files
20:18:45 <jclulow> https://www.illumos.org/issues/15147
20:18:46 <fenix> → BUG 15147: remove /usr/lib/zfs/availdevs (New)
20:19:46 <danmcd> Hey @jbk ==> you're on the short list for code-reviewers for https://www.illumos.org/issues/15146
20:19:47 <fenix> → BUG 15146: sadb_unlinkassoc() isn't idempotent (New)
20:58:32 <jbk> ok i looked
21:26:04 <gwr> For the record, I'm not the _only_ person who has found the $SRC/tools/quick scripts useful.
21:26:24 <gwr> Under a minute or so edit/compile/debug cycle.
21:27:11 <gwr> I thought with them in the gate more people would use them.  If you find them offensive, just delete them and those of us who use them can just keep them somewhere else.
21:27:29 <richlowe> I was just explaining their provinence!
21:28:25 <richlowe> the only thing I want to set on fire right now is availdevs
21:30:07 <gwr> It's in the ZFS packaging, and the quick build tried to build everything in that package...  (though that was probably not necessary)
21:30:28 <richlowe> the packaging is... less good than even I thought it was
21:30:36 <richlowe> though I think ZFS is less bad about it 
21:31:22 <gwr> The other problem with the quick stuff is that the tools builds (particularly building make) takes 5X as long as the rest of the "quick" build, unless you use "bldenv +t" or something.
21:32:23 <gwr> I'm not sure why the tools rebuild so often.  The intent of that stuff is that a rebuild should build _only_ what you need to deliver.
21:32:40 <gwr> (and do it quickly)
21:33:20 <richlowe> I think under nightly it might be because we have to build them separately and swap them out, and that screws up with KEEP_STATE
21:34:58 <richlowe> a plain clean build in usr/src/tools rebuilds nothing (for me), and re-installs minimal stuff (cw)
21:35:10 <richlowe> oh, cw and install.bin not just cw
21:35:28 <richlowe> so I don't know if it's the nightly thing, or something at racktop
21:46:04 <richlowe> wow, just found a comment string for gosling emacs
21:47:41 <richlowe> all over lp, and of course, one in ksh93
22:23:45 <pmooney> does anyone have a broadwell-era intel machine running illumos?
22:28:24 <richlowe> can you give that in model or family or something? I'm bad at names
22:28:50 <richlowe> (it would be a nice feature for psrinfo to print them.)
22:53:08 <pmooney> it'd be a v4 suffix for the xeon models
22:53:24 <pmooney> v2 = ivy bridge, v3 = haswell, v4 = broadwell
22:53:34 <pmooney> IIUC
22:54:58 <pmooney> (I'm trying to figure out when intel added hardware access/dirty page tracking to EPT)
22:55:07 <pmooney> my ivy bridge machine lacks it
22:59:02 <jclulow> gwr: It's fine, I just have no idea how we're testing them to ensure they actually work
23:05:23 <richlowe> I did!
23:26:05 <rzezeski> > wow, just found a comment string for gosling emacs
23:26:16 <rzezeski> like...James Gosling?
23:43:08 <richlowe> yeah, the emacs clone he wrote in the early 80s
23:43:43 <richlowe> has anyone looked at libressl making a bunch of openssl internals we use (eugh) actually private and invisible?
23:44:19 <richlowe> I had no idea we did such apparently nasty things to openssl
23:45:24 <richlowe> I'm going through the list of stuff I don't build right now, and that's among the scarier ones, maintenance-wise
23:47:29 <rzezeski> TIL