The Circonus folks certainly used to use illumos. Might be worth examining their fork if you need rocksdb: github.com/circonus-labs/rocksdb

3 years stale though.

Yeah, nevermind.

> Dropped support for OmniOS (RIP)

Probably from before OmniOSce picked up the torch, but I see no sign that they ever added back support.

matrix quit working for me

server off line?

What server?

rmustacc: Matrix home server

There are multiple.

It's a federated thing so it all depends on what you're on.

rmustacc: any pointers on decoding the values from a ereport.io.pci.fabric event?

gwr: what server are you with?

not sure

vector.im?

no, matrix.org

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.

Your Element is misconfigured

Ask your Element admin to check your config for incorrect or duplicate entries.

(homesever: matrix.org)

I signed out, now it says: ... (paste didn't work like I expected here)

It would seem that they're having trouble at matrix.org

is there a better homeserver?

I assume it's just an outage, I would probably just wait for it to get resolved

jbk: The verbose version should have all the registers expanded.

was it every answered if setting an enum via /etc/system was allowed? ref: 15271

rmustacc: so the names in the output should match names in the PCI spec? (which I'll need to find)

The constants should all be in our headers and what they are roughly.

If you share it I can give a quick summary.

ok

The main thing I look at are the ce and ue status.

With also the caveat of illumos.org/issues/15239.

→ BUG 15239: sharing pcieb HP/LBW interrupts with AER results in spurious ereports (New)

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

They have introduced their own newer version of CTF via Oracle.

It changes the data format to extend certain things, but not others we'll want for C23 I expect.

So I don't know what to do yet, other than be a little sad about continuing fracturing.

oh, that's disappointing

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.

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.

Do we have a good way to find if we support a Storage card vendor by id other than knowledge

by looking into sources, according to pci id maybe?

Yeah, we have pretty good ways of determining that depending on what info you have.

I have... (full message at <libera.ems.host/_matrix/media/v3/do…83bd329f7132b3df1e611e193d5ec364f3f>)

but was wondering how I could do that since some users are asking sometimes via channels

So the question is given some prtconf / scanpci / pcieadm IDs for a PCI device how do you know if it's supported?

Yep

OK, so the answer is ultimately it varies a bit here.

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.

Each driver manifest provides a list of what is supported through aliases. That's how the online hcl is driven.

Some devices use class codes while most just use the vendor or device ID.

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.

Yep that gives a result but only for the device id 285 and the same Producer (Adaptec) but we have none for 28f

I am almost certain jclulow generated an HCL from the packaging in that manner you described.

oh, you said that.

Well, we probably don't support it then.

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?

rather than having to do it all in your head?

that wouldn't be complicated code, for a random person who wanted to write it

I wasn't precisely aware what to check and thought the HCL was manual

It's generated from a terrible awk script I wrote.

But the suggestion would be nice for something akin to ddu

But is incomplete.

The script needs a tweak anyway - "invalid pci id, not valid number: 1442,p"

It'd be nice to have something that actually, you know, really parsed the manifests.

Instead of my terrible awk script.

We do!

pkgmogrify should be able to output them in some kind of decent fashion

I made at least one parser in rust and one in golang

Between that and the fact that the pcilookup/db stuff is much better in-gate, you can rewrite most of github.com/illumos/illumos-hcl and do something better.

hm. illumos.org sites seem to crawl...

tsoome: redmine was a bit tubby, I restarted it

(just now)

yes, much better, thanks

oh so it was not my end