@jbk don't forget there's not-yet-upstreamed mlxcx work from @arekinath !

aaaaaaahhh I'm being summoned

have't tried any cx-7 hardware yet, but I would like to find one at some point. only got cx-6s currently

and a cx-6 era PRM

but it doesn't _sound_ like they've changed a whole lot?

mlxcx does cheerfully try to attach to newer versions of the hardware as long as they're still using the same subsystem ids

the last few times something has changed it's been things like not detecting the speed of the link properly because they've added new bits for the link speed and type

but usually it still passes packets ok

I have a newer one I think...

and I have improved link-detection somewhere? been a while.

it looks like we have several cx-6 options, and 1 cx-7 (the rest are broadcom NICs)

I have a cx-7 and some docs if it's useful.

so it was more to know if the cx-7 was also an option at the moment..

I haven't had a chance to put it in a system and test it, behind on other stuff, but can maybe next week.

i think i have a little bit of a reprieve on the pci segment stuff -- for now it looks like only a single socket system is needed (it looks like the second segment was tied to the second socket)

at least for now...

jbk its loading kernel, yes.

what about the boot archive?

boot archive is loaded as file (loadfile_raw() I believe, in common/module.c)

what's the current recommendation for SSD-based zpools Re: autotrim? I presume we should be setting it to 'on' still?

oh jeez.. yet _another_ pci cfgspace access mechanism

do you mean mechanisms _mechanisms_ or do you mean APIs we have?

APIs

so there's the pci_cfgacc_xxx, there's the pci_{put,get}{bwl}_func, there's the pci_config_xx DDI interfaces, and the cmi_pci_{get,put}{b,w,l} interfaces

Yes, mostly they call eachother

(which kinda use the others, except if they can't get a ddi_acc_handle_t, in which case they seem to plow on

pci_*_func is important because those are the ones prior to us having a device node

yeah, though they seem to imply/assume IO space access

everything else you can simplify in terms of cfgacc if you wanted to

jbk: if you want ecam there, I think the oxide stlouis branch has the changes from Keith for it

and maybe I do in arm64-gate too, since I think I took them

I know I got the suspicious 64bit access sizes from _someone_

but I'd totally recommend reading the short document I put together in arm64-gate, and the cfgspace bits

I have faith it's not as awful as it could be!

oooh nice!

jbk: re: retiring dimms, I'm not sure. We have page relocation and page migration (migration uses relocation), and claims x86 doesn't support relocation

but it _has in the past_ supported memory DR!

and does currently support retirement

that could be at least somewhat useful for VMs where the hypervisor supports it (I believe there are some for X86.. along with adding/removing CPUs via ACPI)

if the usefulness is worth the required support, I don't know..

I don't know about memory dr, someone turned it off

side note: would it be worth a ticket to get rid of the mechanism 2 pci access bits? IIUC, these were last seen on pentium systems (so shouldn't be anything we can boot on that'd use them)

I think so. It would be meem compliant at least. Would it make still-in-use code easier to read? Would it rip out things that might be still load-bearing? I'd like to see such a ticket take stabs at those two questions in its analysis.

the risk would be virtualization doing weird shit

assuming that it is in fact correct that no post-pentium system uses mechanism 2 access (all of the sources I can find basically say 'it's so old, we're not going to even bother discussing other than to note it used to be a thing'

it should just be eliminating dead code

I think for the weirdest mechanism, that's unlikely

but I don't remember the mechanisms. I just remember a really weird one, and a less weird one

as well as regular and ecam

I need to come back for more x86 dead code, though, thanks for reminding me dan

and RTI the parameters one

wiki.osdev.org/PCI claims 486 and early pentium models

there are some other workarounds that i'm unsure of (so would leave them be without more info)

unless someone specifically knows what 'orion' and 'neptune' were at sun and if they're something we can actually boot on still..

or intel

well, neptune was the 10G on the T2?

so either they re-used the name, or they aren't sun names

neptune might an Intel name

sounds like it also might be of the same vintage

and orion seems to be a java enterprise application something something something

and a suncluster thing

tangentially related, does anyone know of the fakebop properties (do_bsys_getprop(), etc) get copied over to a device node (rootnex?) at some point

not off the top of my head, but the traditional way is not a copy, it's an explicit search of "prom" properties

oh ok (i see something using something trying to access one of those properties via ddi_prop_lookup_xxx and just wasn't sure if that should work (sounds like it should)

look for `DDI_PROP_FOUND_1275` references

and `impl_ddi_bus_prop_op`

I hear neptune and think, "nxge" per @richlowe. Orion... eeesh, I'd have to dig through my archives.

so neptune is maybe the intel 430NX from 1994

No

Neptune is nxge.

(seems to fit)

"Sun Java Enterprise System (formerly known as Project Orion)"

Orion was ^^^

and orion is maybe intel 450gx/nx for pentium pros

Damn you for making me dig through my emails.

at least in this context

:)

it took some searching

i'll put in a ticket, and maybe someone with more specific background knowledge can confirm/deny (worst case we reject it)

ok.. issue created..

the system handbook code names list also has:

Neptune (obsolete) SPARCengine EC

(special for Kodak)

Neptune ASIC that enables SPARC to support 10Gb Ethernet

Orion 17-inch LCD Color Flat Panel monitor

only one of which sounds vaguely relevant

Atlas PCI Express Gigabit Ethernet cards utilizing Neptune ASIC

Sputnik Orion CP2080 and Advantest

500MHz cPCI CPU mezzanine memory (SME)