02:08:06 The Circonus folks certainly used to use illumos. Might be worth examining their fork if you need rocksdb: https://github.com/circonus-labs/rocksdb 02:08:42 3 years stale though. 02:12:34 Yeah, nevermind. 02:12:37 https://docs.circonus.com/irondb/release-notes/#changes-in-011 02:12:52 > Dropped support for OmniOS (RIP) 02:13:20 Probably from before OmniOSce picked up the torch, but I see no sign that they ever added back support. 02:59:48 matrix quit working for me 02:59:56 server off line? 03:08:26 What server? 03:09:38 rmustacc: Matrix home server 03:09:49 There are multiple. 03:10:18 It's a federated thing so it all depends on what you're on. 03:22:30 rmustacc: any pointers on decoding the values from a ereport.io.pci.fabric event? 03:23:50 gwr: what server are you with? 03:24:12 not sure 03:26:29 vector.im? 03:29:25 no, matrix.org 03:51:27 Can't connect to homeserver - please check your connectivity, ensure your homeserver's SSL certificate is trusted, and that a browser extension is not blocking requests. 03:51:28 Your Element is misconfigured 03:51:28 Ask your Element admin to check your config for incorrect or duplicate entries. 03:51:29 (homesever: matrix.org) 03:51:53 I signed out, now it says: ... (paste didn't work like I expected here) 03:52:45 It would seem that they're having trouble at https://matrix.org/ 03:53:13 is there a better homeserver? 03:53:32 I assume it's just an outage, I would probably just wait for it to get resolved 04:01:42 jbk: The verbose version should have all the registers expanded. 13:23:20 was it every answered if setting an enum via /etc/system was allowed? ref: 15271 15:07:28 rmustacc: so the names in the output should match names in the PCI spec? (which I'll need to find) 15:08:27 The constants should all be in our headers and what they are roughly. 15:08:42 If you share it I can give a quick summary. 15:08:43 ok 15:10:24 The main thing I look at are the ce and ue status. 15:10:58 With also the caveat of https://www.illumos.org/issues/15239. 15:10:59 → BUG 15239: sharing pcieb HP/LBW interrupts with AER results in spurious ereports (New) 15:50:31 interesting that gcc 12 introduces support for -gctf, but names the section header .ctf instead of .SUNW_ctf so ctfdump can't read it, wonder what the point of that was 16:01:18 They have introduced their own newer version of CTF via Oracle. 16:01:48 It changes the data format to extend certain things, but not others we'll want for C23 I expect. 16:02:03 So I don't know what to do yet, other than be a little sad about continuing fracturing. 16:10:17 oh, that's disappointing 16:11:05 I believe FreeBSD adopted it, so at some point we'll make a call about what to do and if it makes life easier or harder or how much control we still want to have over our own destiny here. 16:12:14 I know we'll never have a shared libctf or other tools due to licensing, but not sure what the right longer-term call will be. 20:34:20 Do we have a good way to find if we support a Storage card vendor by id other than knowledge 20:34:49 by looking into sources, according to pci id maybe? 20:36:59 Yeah, we have pretty good ways of determining that depending on what info you have. 20:38:44 I have... (full message at ) 20:39:05 but was wondering how I could do that since some users are asking sometimes via channels 20:41:58 So the question is given some prtconf / scanpci / pcieadm IDs for a PCI device how do you know if it's supported? 20:43:48 Yep 20:47:00 OK, so the answer is ultimately it varies a bit here. 20:47:29 When I look at this (and I don't use scanpci so I'm not usre how to get the things you want), you basically need to look at the class code, vendor, device, and subdevice ids. 20:47:56 Each driver manifest provides a list of what is supported through aliases. That's how the online hcl is driven. 20:48:12 Some devices use class codes while most just use the vendor or device ID. 20:48:45 So the simplest thing I do is just cd into usr/src/pkg/manifests and grep for the vendor ID and see what shows up if I don't know more. 20:51:55 Yep that gives a result but only for the device id 285 and the same Producer (Adaptec) but we have none for 28f 20:52:13 I am almost certain jclulow generated an HCL from the packaging in that manner you described. 20:52:23 oh, you said that. 20:52:47 https://illumos.org/hcl/ 20:52:53 Well, we probably don't support it then. 20:52:55 it sounds like what you want more than that is something that reproduces the device matching but online, so we can feed it a prtconf -v stanza, and have it reproduce the match and see what wins? 20:53:11 rather than having to do it all in your head? 20:53:20 that wouldn't be complicated code, for a random person who wanted to write it 20:53:41 I wasn't precisely aware what to check and thought the HCL was manual 20:54:00 It's generated from a terrible awk script I wrote. 20:54:00 But the suggestion would be nice for something akin to ddu 20:54:03 But is incomplete. 20:54:29 The script needs a tweak anyway - "invalid pci id, not valid number: 1442,p" 20:55:34 It'd be nice to have something that actually, you know, really parsed the manifests. 20:55:45 Instead of my terrible awk script. 20:55:46 We do! 20:56:34 pkgmogrify should be able to output them in some kind of decent fashion 20:57:03 https://github.com/OpenFlowLabs/ips/blob/master/libips/src/actions/manifest.pest 20:57:06 I made at least one parser in rust and one in golang 20:57:25 Between that and the fact that the pcilookup/db stuff is much better in-gate, you can rewrite most of https://github.com/illumos/illumos-hcl and do something better. 22:02:25 hm. illumos.org sites seem to crawl... 22:05:38 tsoome: redmine was a bit tubby, I restarted it 22:05:48 (just now) 22:07:46 yes, much better, thanks 22:55:31 oh so it was not my end