02:01:44 <richlowe> jbk: do you know why the libmlsvc dmod isn't packaged?
02:20:58 <jbk> no
17:03:01 <rmustacc> jbk: So I'd start with looking at the bridge config space and seeing what's in the slot capabilities register. That's one way that the LED can be advertised.
17:03:17 <rmustacc> Another way is to see if they have the Native PCIe Enclosure Management Extended Capability.
17:04:15 <rmustacc> At least those are the "standard" PCIe based ways to do it. But otherwise, I'd probably go through what all they expose in IPMI and/or redfish.
19:00:52 <alanc> Just in case the old-timers weren't feeling old enough... https://techhub.social/@SolarisDiaspora/114683151979332159
19:14:27 <richlowe> well ahead of you
21:44:41 <jbk> rmustacc: also.. on this box are a few interesting devices that seem to report '-1' for # of lanes (e.g. '60/5/0  PCIe Gen 1x4294967295 pcieb9  Unknown device: 0x352c') -- any suggestions on digging into that? presumably we probably want to handle that better
21:47:45 <jbk> lest someone thing they have a really, really, really high speed link :)
22:13:37 <richlowe> you're probably getting PCI_INVAL* from a cfgspace read
22:14:02 <richlowe> I don't remember which functions on x86 are at the bottom of config space reads though
22:44:43 <rmustacc> jbk: Could you run pcieadm save-cfgspace -a, zip that up, and send it to me along with a prtconf -v output?
22:45:09 <rmustacc> It's unlikely an invalid read in this case given my memory.
22:45:36 <rmustacc> Maybe also an smbios dump just so I know what I'm looking at.
22:51:37 <richlowe> I could swear it was a symptom when I'd broken that stuff
22:53:02 <richlowe> ... nothing to say I didn't break more than that stuff